Java REST framework Dropwizard 1.0 released • Hacker News Board

Re: Java REST framework Dropwizard 1.0 released

#61

Post by manyxcxi » Wed, Jul 27, 2016, 6:11 AM UTC

kentosi wrote: post #29

manyxcxi wrote: post #18

Earlier quoted context omitted.

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 re…

One issue is if you're using Angular. Your html document needs to be xhtml compatible, meaning that an expression like this: Needs to become: If this doesn't bother you (along with > for <, etc) then go ahead.

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.

Re: Java REST framework Dropwizard 1.0 released

#62

Post by einrealist » Wed, Jul 27, 2016, 6:22 AM UTC

abalone wrote: post #55

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. See https://www.techempower.com/benchmarks/#section=data-r12&hw=...

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.

Re: Java REST framework Dropwizard 1.0 released

#63

Post by alxeder » Wed, Jul 27, 2016, 6:24 AM UTC

orsenthil wrote: post #59

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.

Re: Java REST framework Dropwizard 1.0 released

#64

Post by andrewaylett » Wed, Jul 27, 2016, 6:59 AM UTC

ianai wrote: post #42

allengeorge wrote: post #6

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. Congrats on the 1.0 release!

So you've never had to do byte code manipulation or other weird things like another commentor said?

Appropriate magic.

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.

Re: Java REST framework Dropwizard 1.0 released

#65

Post by kubek2k » Wed, Jul 27, 2016, 7:08 AM UTC

tootie wrote: post #48

spapas82 wrote: post #7

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 su…

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.

have you ever heard of YAGNI?

Re: Java REST framework Dropwizard 1.0 released

#66

Post by foxylion » Wed, Jul 27, 2016, 7:15 AM UTC

ianai wrote: post #42

allengeorge wrote: post #6

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. Congrats on the 1.0 release!

So you've never had to do byte code manipulation or other weird things like another commentor said?

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.

Re: Java REST framework Dropwizard 1.0 released

#67

Post by _pmf_ » Wed, Jul 27, 2016, 7:30 AM UTC

alexbanks wrote: post #22

niftich wrote: post #11

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 J…

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.

[0] http://sparkjava.com/

Re: Java REST framework Dropwizard 1.0 released

#68

Post by kubek2k » Wed, Jul 27, 2016, 7:39 AM UTC

abalone wrote: post #28

necubi wrote: post #3

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…

What JVM microframeworks would you recommend for streaming or async?

there is also vert.x worth to look at

Re: Java REST framework Dropwizard 1.0 released

#69

Post by CHY872 » Wed, Jul 27, 2016, 7:54 AM UTC

_pmf_ wrote: post #67

alexbanks wrote: post #22

Earlier quoted context omitted.

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. [0] http:/…

(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.

Re: Java REST framework Dropwizard 1.0 released

#70

Post by CHY872 » Wed, Jul 27, 2016, 7:57 AM UTC

spoondan wrote: post #45

ianai wrote: post #41

Earlier quoted context omitted.

Interesting because they made it sound pretty horrific.

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.

It was a mess.