Thanks, I'll have a look.

@cedric Have you take a look into ktor o wasabi?

Just superficially

They are basically routes framework just like Spark but written in kotlin

Wasabi is EOL now.. it's merged with Ktor

I do not know how the code is written but I guess there is not much static stuff

I can (biasedly) vouch that http4k relies on no static state :)

That goes for Hexagon and Ktor also AFAIK.

IMHO Dropwizard is the best of the Java-only bunch - it's got a lot of sensible stuff built in.

Ratpack isn’t bad for this, also…it’s a little more frameworky, and it’s built on netty, rather than jetty.

I greatly prefer Ratpack to Dropwizard, myself

@jkwatson Regardless of what you choose, we've found that one of the most important things is to be able to spin up the entire app without a server and test it offline. And to also beware of framework-y type solutions that don't allow you to decouple your tests from the implementation - so when you decide to switch backends, your tests are still valid.

And make sure your server plays nice with DI (which SparkJava doesn't)

<insert redacted rant about DI containers/>

🙂

Aye, testabilty is very important; luckily most libraries I've tried recently take this seriously, but never the less: if you're choosing a product and there isn't a convincing chapter on testing, run the hell away

There's also Kovert which rides on the vert.x framework. IMHO, any framework you choose sound have plugins for social logins and roles to fit typical use cases nowadays...

That totally depends on your use case. Internal microservices certainly don’t need social login support!

True.. That's only if you need a web site as well. Roles are useful for APIs though.

@kenkyee looks interesting. could you please point me at any example repo containing the testing of Kovert apps? With it being an abstraction layer on top of vert.x, I'm particularly looking for how to test without sparking up an actual server.

It's a fairly old framework... Just Google for examples

I've found that writing an RBAC (Role-Based Access Control)-type system on top of our own account system state was really really easy in Kotlin

one can literally switch from writing pseudo-code to writing high-level logic in Kotlin, and evolved the code from there. felt very natural.

@dave Here's a document about Ratpack testing if you need more examples: https://danhyun.github.io/2016-gr8confus-testing-ratpack-apps/ the gist of it is that they provide a static method you can call with a Chain/Handler (Ratpack's primitives) and a config closure where you set the URL, body etc... and it all just works

From a user's viewpoint it's super simple

That doc is in Groovy but I code in Kotlin and it works just as well

That's for unit tests; for integration testing I spin a server of my own but they do have built in support for that as well I think

Thanks for the examples @gregopet & @kenkyee 🙂 - very useful - although for Kovert I have to admit that I was definitely looking for examples which didn't include vert.x at all - especially since on the README.md Undertow and SparkJava is mentioned as possible alternate backends (although not yet) and I'm keen to know how much effect switching the implementation would have on the test suite. The reason for this is that we've found that frameworks which need to provide loads of testing infrastructure suggest that there is too much coupling to the nuts and bolts of the underlying framework, which obviously shouldn't be the case - if I switch out my backend, I don't want to have to completely rewrite my tests as they should still be valid.

What's probably more important in place of extensive test-documentation is maybe a discussion of what types of tests are needed to provide excellent, decoupled coverage for that framework - eg. unit (no container) vs integration (container) vs contract style (dependency testing). Although I suppose this rather comes down to your testing methodology - eg. London and Classic styles of TDD would result in different test suites.