Java REST framework Dropwizard 1.0 released • Hacker News Board

Re: Java REST framework Dropwizard 1.0 released

#81

Post by zo1 » Wed, Jul 27, 2016, 10:37 AM UTC

dozzie wrote: post #74

nu2ycombinator wrote: post #33

Earlier quoted context omitted.

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.

> Any set of best practices are opinionated. "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.

Re: Java REST framework Dropwizard 1.0 released

#82

Post by spapas82 » Wed, Jul 27, 2016, 11:21 AM UTC

StreamBright wrote: post #77

spapas82 wrote: post #19

Earlier quoted context omitted.

I'm aware of that. However, have you tried using them in any non-trivial project? (for example, a project that supports authentication ?)

We are actively using it for things like that. What is your actual problem, could you show some code?

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.

Re: Java REST framework Dropwizard 1.0 released

#83

Post by sorokod » Wed, Jul 27, 2016, 11:38 AM UTC

CHY872 wrote: post #70

spoondan wrote: post #45

Earlier quoted context omitted.

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

That's dynamic linking for you - you need to take the good with the bad

Re: Java REST framework Dropwizard 1.0 released

#84

Post by tootie » Wed, Jul 27, 2016, 12:36 PM UTC

kubek2k wrote: post #65

tootie wrote: post #48

Earlier quoted context omitted.

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?

Yes and so has Spring. Every module is a separate dependency. If you don't need security or DB persistence, don't include them.

Re: Java REST framework Dropwizard 1.0 released

#85

Post by avita1 » Wed, Jul 27, 2016, 2:33 PM 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.

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.

Re: Java REST framework Dropwizard 1.0 released

#86

Post by allengeorge » Wed, Jul 27, 2016, 7:07 PM 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?

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

Re: Java REST framework Dropwizard 1.0 released

#87

Post by darylteo » Fri, Jul 29, 2016, 12:11 AM UTC

premium-concern wrote: post #60

darylteo wrote: post #57

Earlier quoted context omitted.

If you want to venture back to the JVM, Kotlin offers a very good middle ground between Java and Scala.

What's the "middle ground"? Java with a more concise syntax?

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.

Re: Java REST framework Dropwizard 1.0 released

#88

Post by premium-concern » Fri, Jul 29, 2016, 2:24 PM UTC

darylteo wrote: post #87

premium-concern wrote: post #60

Earlier quoted context omitted.

What's the "middle ground"? Java with a more concise syntax?

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.