This seems like a use-case that a whole lot of people are excited about since microservices are presently in vogue. What would make me want to choose Apollo over, say, Dropwizard (http://dropwizard.io) if we assume that I'm not a developer at Spotify?
If you compare the "Getting Started" sections for both frameworks (Dropwizard's is here: http://www.dropwizard.io/0.9.1/docs/getting-started.html), it looks like the initial setup for Apollo is a lot less complex. This may be a significant advantage, because it cuts down project setup time, which is one of the annoying parts of microservices.
However, I can imagine having to pay for this once you need some more advanced features. Dropwizard comes with a lot of stuff for configuration management and integration, which I guess is mostly missing in Apollo.
Really? The dropwizard example looks almost identical except for an extra Config related class (which seems like a more sane design to me) and 2 extra methods to implement. Not sure I'd call it a lot less complex.
I think what is happening is the getting started guide for dropwizard looks significantly more indepth than the Apollo guide, covering some features that are entirely optional (and may not even be supported by Apollo.)
Project setup time with microservices really shouldn't be the issue. Build one template then use for all your services. Don't pick your framework because of setup time (plus I want to argue the differences are minor).
> What would make me want to choose Apollo over, say, Dropwizard
Came here to ask this too, if anyone in the know can provide an answer, because it doesn't seem to address this point in the readme from what I can see.
Looking at the examples on github, the thing I notice immediately is that it seems more DIY in nature, with seemingly all the libraries required for dealing with http, middleware, routing, etc written from scratch, as opposed to Dropwizard's approach of pulling together popular existing libraries to do all these things and providing really only the the glue code to piece them together as a framework.
Unlike Dropwizard, it is really intended for an asynchronous model of development. You don't have to worry about pushing the concurrency limits of an OS by starting thousands of threads if your application has a high ratio of callouts (disk, network IO) to computation (CPU), as is common with a lot of microservices. I guess this approach works best if your app's dependencies are convenient for asynchronous calls as well - HTTP, Cassandra, etc.
There's no need for asynchronous code and new frameworks to achieve that. Comsat makes Dropwizard run simple blocking requests in Quasar fibers (I'm a Quasar/Comsat dev), so you get all the performance of async code while still working with simple blocking code, standard APIs (JAX-RS), and standard servers (Jetty). You can easily run a hundreds-of-thousands if not millions of fibers in a single JVM without getting into trouble.
Interesting phrasing. I really hope people are choosing the best architecture for their application and not heading into microservices land because it's hot or "in vogue".
(Note, mtolan, not assuming anything about you or your choices here.)
Interesting difference in attitude I notice. The java (i suppose) devs commenting have the general attitude of "give me one good reason to use this instead of X". In contrast when a new javascript framework is posted people go "yay, this looks awesome, congratulations! I will try it for my next project!".
I tend to have an attitude similiar to the java side. I wouldn't say the javascript attitude doesn't have benefits though.
I don't see an issue with having more available options, especially in the fast moving JS world.
I think it's more important to consider the support behind a technology vital to your stack so you can expect to regularly integrate improvements, security fixes, etc.
So, in the startup world at least, I always hear JAVA IS DEAD! DOWN WITH JAVA!
But this library, a bunch of Google stuff, most of Netflix's stuff -- it seems like the real, this-makes-money work is still done in Java. Am I wrong? Is Java not dead at all?
It so happens that a lot of companies have bet their stacks on Java. Java is the language of Hadoop. In addition to the companies you mention, there's Amazon, eBay, Facebook, LinkedIn, Twitter. (There are plenty of other great languages that outperform Java in one way or another, but this post is just to make that point that Java is far from dead...)
It's a stable language with a huge ecosystem, that's growing all the time. Our project, http://deeplearning4j.org, gives it deep neural networks that run distributed...
Not sure why they'd write all these libraries from scratch instead of just reusing something like Play or Dropwizard that are more used and thus probably better supported and have more of the kinks worked out. Wish they'd explain that up front.
It's not a matter of a few extra MB, but number of libraries, more libraries equals more bugs equals more problems.
I'm not saying only play has this problem, almost all java frameworks from the time of play have similar properties.
On the other hand, it is slow, embarrassingly slow (try running it on RPi). For me it's really complicated as well. You have routes file (which is redundant). Templating language forces you to write Scala which then uses a Scala compiler to compile which it is really slow (even Martin said it's slow). It's a vicious circle.
It's probably a stretch to say that Amazon's Apollo has a bigger "market share", because it's not on the market. AWS CodeDeploy may be similar--haven't checked it out. Nevertheless, the Amazon Apollo's user base is probably way bigger than ActiveMQ's or Spotify's Apollo :)
Also, it seems the Greeks have stolen the name for one of their gods too.
Spotify has used Greco-Roman Pantheon names in its technology stack. I don't know all of the exact details for Apollo in this context but I assume similarities to existing tech is coincidental.
Spring Boot, Dropwizard, and Apollo all seem to try to do the same thing. They all seem easy to use, more or less opinionated with Spring Boot being the most opinionated. The one thing in Apollo I find quite interesting is the native integration of async-ness. Very nodeJs like but could also be achieved in Spring Boot or Dropwizard with Reactor. I do think Dropwizard would have been THE framework to extend here with some async sugar. But hey, developers love to build their own things.
This looks cool, but looks like they waited too long to release it. I would like to see some benchmarks, but humbly think that it can come no where near Rapidoid (https://news.ycombinator.com/item?id=10729868) which in my opinion is more elegant and complete.
