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).
Hence, 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.
Gave this a quick look. I'm much more a fan of Spring Boot (http://projects.spring.io/spring-boot/). Like Pippo, Spring Boot starts with a lot of auto-configured defaults that can get you off the ground quickly. However, the full power of Spring and its related projects are at your fingertips and you can reduce the amount of auto-configuration as your project becomes more complex. Also like Spring's stereotype principles more than extending a base "Controller" (in Spring, you annotate a POJO with @Controller or @RestController).
As mentioned previously, JAX-RS really shines for micro services. The same interfaces can be shared between client and server, making client development a breeze. Spring Boot supports JAX-RS services as well via a Jersey adapter.
Same as any other code--via debug step-through, or logging, centered on the code that processes the annotations. It's actually much saner than heaps of "marker interfaces" and is readily testable.
I am the initiator of this project. It's an honor for Pippo to be mentioned on ycombinator.
I see some debates related to "micro" definition. A while ago a friend of mine posted some comments on reddit justifying why Pippo is "micro". If you are interested to find out the arguments please read https://www.reddit.com/r/java/comments/3x1wsm/why_are_java_w....
When I published the first article about Pippo on Dzone(about one year ago), someone asked me "what are the key differences/advantages of Pippo compared to another Java micro framework Spark?" You can see my answer in the comment section of the article (https://dzone.com/articles/pippo-micro-java-web-framework)
Pippo is small, modular but it's not a simple toy. You have a lot of features that are not available in other (Java) micro frameworks.
If you want more features (security, scheduler, rest doc, event bus, mailer, DI), try Fathom (http://fathom.gitblit.com). Fathom is a Undertow+Guice+Guava+Config+Logback stack over Pippo.
For people that like the super declarative approach (via Java annotations) from Spring Boot, we will try to upstream the fathom-rest module (http://fathom.gitblit.com/rest) in the pippo-controller module.
There are some new features/modules that are not documented yet (for example PippoTest class from pippo-test module, ...) but Pippo demos (https://github.com/decebals/pippo-demo) are great and you can learn incrementally many aspects of Pippo from these.
Neat! It's been a while since I wrote Java code. Java8 lambda syntax looks quite reasonable. I'd recommend the author to make "Getting Started" section a bit more detailed. One of the gripes I've heard is that Java setup and build are non trivial for inexperienced engineers. So maybe some script/screenshot HOWTOs or adding a Dockerfile?
The idea with Pippo is that you can create easy a very custom stack. You can work with your favorite servlet container, template engine, json/xml libraries and this is great (for example I use Undertow as servlet container and Pebble as template engine). To do this is simple to add the right Pippo module in your pom.xml file and it's done (pippo-undertow, pippo-pebble in my case).
I don't want to force you to work with my personal stack.
I don't see big advantages over one of the Jax-RS libraries, though. Those libraries pack in a lot, all of which you're going to need if you build a serious app.
I think this library would be interesting if it could allow for easy swapping of a transport layer. If I could, for example, dump http for something faster with few code changes, that would be very cool.
Bingo. Yuck. I don't want to read the code for (let alone write) a bunch of do-nothing model objects. I want something that turns my result set into JSON ("there is no step 2"), assuming I am running an authenticated query.
Of course, I also want something that runs my Javascript validation code server side, as well, but that's another story.
The Pippo goal is to simplify the web development in Java (as much as possible).
If you want to write a medium, big application in Java you have a lot of options, standard or non standard (Jsf, Wicket, Play, Spring Boot, ...). Pippo is for small and medium applications, maybe for applications where the backend is Java and the frontend is Angular or other javascript framework, for applications micro services oriented. Pippo has a clear niche and do not try to compete with the Jaava web frameworks enumerated above.
What metric is 'micro' based upon? Serious question, if it starts an embedded jetty or tomcat (as it appears to be doing) it's not small in either deployed artifact size, or runtime resource utilizations (not anymore so than any other tomcat or jetty app).
A microframework is a framework whose API has a low surface area. It's not especially feature rich, but is conceptually lightweight and lets you get moving quickly.
A microservice is a small service that performs a well defined job with limited scope, and (generally) which runs as its own OS process - not depending on something like a j2ee application server.
These are pretty standard industry terms these days.
I won't make any definitive claim about what the OP really means. But this does seem to be a microframework for writing microservices.
If only the Java type system were better. Mostly my complaints are around type erasure, and working around that becomes a large PITA and removes many of the niceties of generics in the first place!
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.