Java REST framework Dropwizard 1.0 released
dropwizard.io
dropwizard.io
1. request comes in
2. do stuff here
3. response goes out
While this may not sound very exciting, this is exactly what goes on in HTTP APIs. People these days use Node or Go for this kind of stuff, but Dropwizard makes it very pleasant to do it in Java.
This was because that package depends on a different version of jersey-jackson or whatever, which was discovered by classpath scanning, and so because Eclipse doesn't keep a separate test classpath, we'd be discovering a new MessageBodyWriter which Jersey would be using to override the Dropwizard supplied MessageBodyWriter, which would not have the appropriate Jackson modules.
It was a mess.
It is a littlebit sad, that there are no javac warnings enabled by default that at least check known classes for conflicts in the classpath. An IDE should do that by default, too.
Where does bytecode manipulation or code generation happen in Dropwizard? Reflection for sure, but not any more so than any major web framework in a dynamically typed language.
Maybe you're referring to the SQL library they suggest (which I've admittedly never used heavily). But I don't see how you can have a SQL library without generating SQL.
For reference, what types of languages/frameworks do you like to work with?
I've also had good luck with Spring Boot, but it's a little magical for my tastes - I vastly prefer Guice for Java DI - just straightforward and predictable (that's just my subjective take though).
Dropwizard is a good bundling of stacks, but I don't think it'd match my personal preferences.
I will say that doing rest-style service work in modern Java frameworks is actually not too bad these days. Java 8 makes it even nicer.
IntelliJ (Jetbrains are the leaders behind Kotlin) has first class support for the language. Gradle will have support for Kotlin as it's DSL in it's next major iteration.
Despite some very loud people on the internet, it seems to have close to zero adoption, and JetBrains making big promises and then failing to deliver anything is not really helping them.
With Spark[0] (not to be confused with Apache Spark ...), you can get a Sinatra-like routing library on top of Jetty (while you still can deploy the webapp in a more heavyweight container if you need to).
I think Spark is in spirit much like Dropwizard, but a bit more lightweight.
I think that Spark comes at the cost of customisability - 2-way SSL is a chore, you have to parse your own message bodies, you don't get straightforward logging out of the box - there's a base set of features and functionality that I couldn't find in Spark.
The thing that impressed me about Dropwizard is that you can get in perhaps 50 lines of boilerplate a really solid core behind an application - with Spark you can do that in perhaps 20, but you are somewhat limited beyond that.
(For the record, I don't mean to offend anyone, but Spring Boot reminds me of the old truism about Visual Basic: "it makes easy things stupidly easy and the hard things impossible".)
For traditional web development, I recommend spring-boot which is almost as easy as dropwizard, it also doesn't need an application container and fully supports Spring MVC, Spring Security and all other spring related goodies.
I stumbled on it a long time ago because I had the problem of Java devs needing to integrate templates built by front end devs and all the churn that goes along with it.
It uses custom tag attributes like th:href to swap the computed value in on template render so you can have a completely perfect looking HTML/CSS/JS template with the placeholder values without having to convert back and forth. It's just HTML with extra attributes that get ignored when not run through the rendering process.
You can use Spring Expressions, forms, and security with pretty much no configuration, it works awesome.
It supports partials and layouts and all the good stuff you'd want for reuse and it took me about 10 minutes to create a custom dialect for it that lets me use Thymeleaf and Vue.js together very nicely.
I can't recommend Thymeleaf enough.
<div ng-if="this() && that()" ...
<div ng-if="this() && that()" ...
If you want the unescaped output there are lots of things you can do. I did something similar for Vue.js in about twenty minutes and a few lines of code.
- Integrating with spring-security - Integrating spring-security-tags (sec:authorize etc) in the templates - Using a different template engine in general (wanted to use thymeleaf) - Not able to bind forms to objects - Enabling pagination
Please notice that all these are related to my specific needs (server side views) and, when trying dropwizard I had all these already solved with spring-mvc. Maybe if I kept pushing I'd be able to resolve most of these but, because of lack of documentation, and generaly because I understood that dropwizard should be used to create REST APIs, not server-side views I just switched to spring boot.
It's not the fastest or most scalable option on the JVM (that would probably be something netty based) and the API is an awkward fit for anything streaming or asynchronous, but it's the best thing I've found for its niche.
RatPack is a nice async microframework
Congrats on the 1.0 release!
Jackson uses byte-code manipulation to get its work done, but you'll never see it nor have to interact with it -- all you see is a nicely annotated class that automatically converts to and from JSON as it enters and leaves your code. For advanced use-cases you may have to ask for the ObjectMapper and convert strings yourself, but you'll never need to know how it's implemented.
To my mind, appropriate magic is where you define your interface to have a simple-to-use but complete API, hiding the complexity of implementation. For example, Guava's CacheMap implementation has careful internal locking to present a consistent but high-performance thread-safe object, rather than requiring external locking or needing the caller to avoid certain combinations of actions, both of which I've seen when I've come across people who tried to implement their own. Or, in Jackson's case, high-performance data manipulation that could be done using reflection but isn't because that would be too slow.
"The highest-volume service in this area is Gurafu, which provides a set of utilities for working with road map data and improves efficiency and accuracy by providing more sophisticated routing options. Gurafu is fronted by µETA, which adds a business logic layer on top of raw ETAs (things like experiment group segmentation). Both Gurafu and µETA are web services built on the DropWizard framework."
But RPC-over-HTTP (XML-RPC, JSON-RPC, or even Thrift) is a problem solved long ago, so it's not sexy enough, I think.
And no, it doesn't make designing API easier if you preallocate "read", "create", and "delete" operations to separate HTTP methods, and then put all the other operations in POST. "Create" and "delete" in many cases don't even make any sense to guarantee their being specially distinguished.
And you say that RPC can be used under REST. Do you have any example of a REST client library that actually can do that? It's the first time I ever hear about this way. Almost everybody else uses REST like an underspecified RPC protocol, cramming call request into an ad-hoc JSON structure to HTTP POST and mixing error reporting from transport layer and from application.
It's like someone advocating writing all software should be written in Brainfuck, because the cognitive load of remembering eight operators is so much easier than learning all these keywords and syntax and runtime libraries that come in other languages. Except whereas our imagined Brainfuck advocate would be rightly ignored, REST has somehow become the fucking dominating paradigm of our industry.
The idea that reduced complexity in one area might trade off with much greater complexity in another simply does not wash with these people. They have a resource & verb shaped hammer, and they are going to use it to batter each and every API into some kind of nail shape, no matter the effort it takes and the carnage that ensues.
"Best practices" are supposed to work sensibly in most cases. REST only works in a small subset (read/create/delete and nothing more), other cases being stuffed collectively under HTTP POST umbrella, so you need some RPC protocol anyway. This is very far from working sensibly.
We have had great results internally here at Boxfuse with Dropwizard. So good in fact that we decided to add Dropwizard-specific optimizations to our deployment tool for running Dropwizard apps on AWS with a single command.
Everything work great. If you learn real work DW app, see my open source project.
Stack:
1. AngularJS 1.x as frontend
2. DW as REST backend
3. Hibernate as Data Access Layer
4. PostgreSQL as DB
Now maybe those PHBs who think we should use spring-boot because it's passed 1.0 will pipe down. Or not. Anyway, good to see - especially with HTTP2.
See https://www.techempower.com/benchmarks/#section=data-r12&hw=...
To teams that you Dropwizard, what is your front end stack? Do you use Angular and communicate with proxy to dropwizard or do you do something which talks to Dropwizard API directly?