4 ms·
Here is my problem with all these (pseudo)small request handling frameworks.... They seriously tightly couple your code with a relatively unproven library. Not
by agentgt 11y ago
Here is my problem with all these (pseudo)small request handling frameworks.... They seriously tightly couple your code with a relatively unproven library. Not mention most of them use a fair amount of singletons and static initialization.
Most web applications require an enormous amount of controllers and even micro services typically require a fair amount of routing and request/response handling. Not to mention security, the asynchronous model, future HTTP2 support. I'm not exactly comfortable using something like this for a moderately size project nor even small project.
I have also seen like 6 or so micro frameworks in the last couple of months. Just two of them offhand I remember:
* Rapidoid - seems to be smaller.
* Jooby - not smaller but seems more mature.
Most of them just build off of Netty (at least some project realize they shouldn't be redoing the low level).
I honestly think there should be a slimmed down modern servlet/jaxrs api spec that should be designed in a similar manner to how the reactive-streams api was designed (ie make a github repo, file issues, take pull requests and get the damn interfaces right).
We also have the same problem going on with Singles aka Promises aka Deferreds aka Future with callbacks (dozens and dozens of implementations exist). Right now I'm using rx.Single but just about every framework has its own (reactor, Play, Akka, JDeferred, etc etc).
At least streams aka Flow will be in Java 9.
- pjmlp 11y agoHence, why like the old man at the sea, I see these frameworks come and go, and get to use the best ideas from them when they get eventually added to JEE.