5 ms·

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 ove

by mtolan 11y ago

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 http://dropwizard.io) if we assume that I'm not a developer at Spotify?

JustSomeNobody 11y ago
"in vogue" 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.)
- mwexler 11y ago
  Hope does spring eternal.
davnicwil 11y ago
> 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.
- mipsmaster 11y ago
  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.
  - pron 11y ago
    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.
j_jochem 11y ago
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 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.
- ones_and_zeros 11y ago
  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.)
- bjoernw 11y ago
  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).

by mtolan 11y ago

JustSomeNobody 11y ago

"in vogue" 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.)

mwexler 11y ago
Hope does spring eternal.

davnicwil 11y ago

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

mipsmaster 11y ago
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.
- pron 11y ago
  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.

j_jochem 11y ago

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

ones_and_zeros 11y ago
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.)
bjoernw 11y ago
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).