Dropwizard is really just an opinionated bundling of sane Java libraries that don't suck, and is essentially tailor-made for the (quasi-)event-driven processing model of:
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.
Spring boot is the dropwizard competitor for people who don't mind Spring magic. Jhipster is a project that uses spring boot to make the project setup pretty much as easy as in rails. https://jhipster.github.io There IS still cool stuff happening in the Java world
(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".)
My greatest gripe with Java was the amount of crap one had to go through just to build a simple Rest API. When I saw DropWizard I thought it solved that need. Maybe it's time to get back into Java development...
Jetty has been around for a while; a response handler is a one liner (well, a Java one liner, which translates to 7 lines ...).
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.
(opinion: i've spent a year writing Dropwizard based apps, but only two evenings writing Spark based apps).
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.
I've only used Spark in a very local context (small company internal projects), so I'll definitely take into account your experience when doing something bigger.
If you love dealing with magic "comefrom" annotations, codegen that isn't debuggable, and foundational libraries that have to resort to bytecode manip to get stuff done, then go ahead.
Yes. Most of the unnecessary complexity has just been moved from bad APIs with XML configuration to bad APIs with runtime scoped annotations, code generation and byte code manipulation. It's still a huge mess.
Yes you have. Jersey, Jackson and almost every Java database abstraction that's higher than JDBC uses one if not both. Dropwizard is one of the better Java libraries in this regard but it's still there.
There's quite a bit of magic under the hood of DropWizard (or, rather, the components that make it up). My experience has been that a developer using DropWizard will rarely, if ever, encounter this magic: they don't need to be aware of it. But if the veil ever slips, the sheer amount of ugly machinery will shock and horrify.
I can see that. We found that if we added the Spotify Docker Client to our test classpath we couldn't run the application from Eclipse anymore because our Jackson object mapper had the wrong Jersey modules.
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.
Although it is very easy to add dependencies via Maven or Gradle, this does not prevent you from shooting yourself into the foot. You have to manage dependencies, including transitive ones. If the application has too many conflicting dependencies, then use classloader isolation (e.g. OSGi).
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.
Personally ,the worst I've ever run into is some hairy classpath issue, as one the children comments mentions. Although maybe I'm just lucky.
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.
I disagree. Dropwizard itself is really simple. The frameworks like Hibernate or HK2 are more complex, though. But there is definetely no magic involved.
So, is the answer to just bail on Java forever? I haven't written anything legitimate in Java in about two years, but I don't remember it being that bad.
For reference, what types of languages/frameworks do you like to work with?
I'm not the OP, but I've had good luck with the Play2 framework. It works best with Scala, but it's Java support is great too.
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.
Pretty much. Its been very enjoyable to code in so far (and works with practically the whole Java ecosystem of libraries and platforms.
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.
Well, if you think the most important technical improvement to language design discovered since the creation of Java in 1995 is some shorter syntax, go ahead. I guess.
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.
Dropwizard is great for REST APIs (... as the title says). However if you want to use traditional views (MVC, html templates, security, forms etc) then please check something else (I tried it and lost many hours -- in the end I still couldn't do even basic things).
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 agree completely. For a long time I was avoiding Spring because bloat and XML, but then I finally gave in and tried Spring Boot. It is most excellent. Nearly all bloat is opt-in, it does everything, and absolutely zero XML configuration needed. I've tried Dropwizard before, and use it for two applications I have running. It works, but it's not great (because it's not just a rest API, but also has GUI and user management). I'll be porting it to Spring eventually.
Dropwizard is basically a subset of Spring. Spring can do a REST API just as easily, but also does everything else. I've used both, Dropwizard is great but there's no use case I'd select it over Spring.
There's some time since I stopped trying to work with dropwizard on non-REST projects so I've forgotten most of my problems. Some of those that I wasn't able to resolve are:
- 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.
We do our "MVC" stuff with Dropwizard. There are some minor quirks (like validation). But we find it suitable enough for how we build our applications. The upcoming javax.mvc standard will probably find its way into Jersey and Dropwizard. For the views, we use Freemarker (Thymeleaf was too slow and less extensible).
I've been using Thymeleaf with Spring for a while and almost always exclusively use it with Spring Boot because it's pretty much right out of the box ready to go.
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.
It doesn't have to if you write your own dialect for Thymeleaf. You can alter the flow of the output manipulation and validation- it's out of the box that it chokes on the 'weird' stuff being shoved into attribute tags nowadays for JS templates.
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.
thymeleaf (http://www.thymeleaf.org/) - it is supported directly by spring boot (spring-boot-starter-thymeleaf dependecy). Also, using thymeleaf-extras-springsecurity4 you can integrate spring security tags with thymeleaf so that you can conditionally render things depending on the current user/authority into your templates!
Nice to see a 1.0 release. We've been using Dropwizard for various public and internal APIs for a couple of years and have been very happy with it. The components (jersey, jackson, coda hale metrics) are all very pleasant to work with, and generally have low-ceremony APIs that feel as productive as the ruby or python equivalents while providing the performance and operability of the JVM.
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.
I've had an excellent experience with Dropwizard. It combines robust, simple-to-use libraries, has excellent documentation, is easy to poke into, and "just works". It's my go-to framework if I want to create REST apps in Java.
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.
That's really not necessary. I don't know where this comes from, but we maintain a big Java application and never messed with the byte code.
Dropwizard itself is a very mature framework an extremly easy to get started with.
Byte-code manipulation?! No - never. I'm not sure where that comes from. I've had to write my custom ObjectMappers for JSON and some glue mappers for JDBI - but they were pretty lightweight. In fact, I've some examples in github of a custom key-value server written using Dropwizard with examples of those...
Love them or hate them (I am in the latter category), but observe even Uber mentions some of their heavier backend stack for internal usage runs on Dropwizard.
"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."
Funny that everybody rush for REST framework, while most of the time people
cramming REST in their applications need less "read, upload, replace, delete"
operation model and more "normal functions, except called remotely" provided
by RPC.
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.
I don't know, RPC is declaring for no abstraction at all, just raw access to code that can do anything. REST provides strong abstractions, they are just slow, and to make the app fast we have to compromise them. But that's the same for relational databases and ORM; I think really REST isn't the problem, but instead SQL. And RPC is like writing bits with butterflies.
REST is like set of best practices to design API end points like define resource as end point and map standard HTTP methods to certain operations. This makes it easy and leads to a standard in API designing. And underlying technology can be RPC or servlets too. For example define end point "/user" and client knows how to create update or delete user where as before Rest these used to be different end points for each of these operations or have to specify the kind of operation
More like set of worst practices. You have some API exposed in plenty of
endpoints instead of one, and on top of that you embed one of the call
arguments in the URL itself.
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.
You're wasting your breath. REST zealots will never be convinced that anything other than the magic four of GET / PUT / POST / DELETE is necessary.
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.
Well there are no hard and fast rules. Any set of best practices are opinionated. You can have different of opinions if they are not suited for your use case. All the REST frameworks you found are designed around the those ideas. For making your APIs rest you do not need any framework you can design your APIs along those guidelines. Again how far your apis need to be REST complaint again it is upto common sense.
"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.
I agree. A lot of "normal" operations that need to be implemented usually perform actions to different tables/entities. So, the accepted "REST" way of doing things forces you to either move your combination/"atomicity" logic to the frontend, or to call other REST actions from the first rest call itself. Even then, that specific call is not linked to an entity, but stands on its own.
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.
I've used Dropwizard for many years, and have always been a big fan. It made java development fun again for me. Congrats to the team for an awesome new release, and also for doing a great job over the years of balancing features and upgradeability.
Does anyone know why dropwizard ranks so low and slow in the techempower benchmarks? For such an apparently thin microframework I always wondered what the culprit is and whether it could be optimized.
Jax RS has more overhead compared to the Servlet API. Using the Servlet API, Jersey (Jax RS implementation) must route the request to the correct resource class (Controller). Dependencies of that class as well as lifecycle dependencies (filters, interceptors, message body readers and writers) have to be instantiated to finalise the request.
Congratulations on 1.0 release. I love dropwizard too, it makes backend development seem very sane and predictable.
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?
During initial development we are starting out with bundeling our angular app with the api by serving the angular app as dropwizard assets. There we use webpack-dev-server in proxy mode for easier development with livereload.
We don't like the complexity of seperation from the start. If we run into problems (assets need to scale differently than the api) it's pretty easy to extract the static angular app and serve it via a separate webserver.
Ah Dropwizard. Even though Java isn't my favorite, it really wasn't that bad to work with when making a tic-tac-toe game for a coding assignment for a job interview.
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.