Meteor vs Apollo


#1

I’ve been asked for a consultation on a new app, and I proposed Meteor + React, while another consultant proposed Webpack + Apollo + React.

I initially discared Apollo as I don’t think it’s ready for production yet, but I might be wrong. Anyhow this poses a nice question: What does meteor 1.4 offers over Webpack 2+Apollo?

Many originally advantages of Meteor are adopted by many libraries in the javascript ecosystem. What still makes meteor unique?


#2

DB reactivity i think.


#3

Apollo is production-ready, and is in use in production. It now supports reactive data. You can certainly use it with Meteor + React.


#4

apollo + react is reactive, even better it can make sql databases reactive.

@sashko what’s your opinion? you worked on both projects, so you should know better than anyone else.


#5

Assume you and another consultant have on par programing competency, you win on faster development time.

  • Learning? No need
  • Have question? Google is your friend, it will lead you to bunch of amazing SO answer, while with Apollo you may need to create question and waiting someone answer your question.
  • Found issue? Search github, you’ll find how to resolve your issue, while with Apollo you may need to file an issue and waiting someone fixing it
  • Need extension? Visit NPM or Atmosphere, while with Apollo you may need to create yourself

But personally, I’d prefer you to use Apollo


#6

with or without meteor? what’s the sense of meteor if I pick apollo and webpack 2?

yes a bigger startup cost, i.e. filling the configuration files, but after that I would have a solution tailored for the needs of the customer.

I feel like I proposed the wrong solution by picking meteor, because MDG is giving me a better alternative with apollo and a custom stack.

Or maybe I’m missing something?


#7

@muaddib I would go with Meteor. For enterprise apps and a lot of linked data: https://github.com/cult-of-coders/grapher

And I will soon make stable:

Which is going to make Meteor’s reactivity finally scalable and fast as possible.


#8

With Meteor you get robust secure accounts support built-in. That’s going to save a lot of time.


#9

In my experience being on the bleeding edge can cost you a lot of time. If you can live with Mongo, have a tight deadline and/or really need the livequery functionality. Go with Meteor.
If you have some time to play around and don’t really need livequery capabilities, try webpack 2 + apollo.

What Meteor delivers over Webpack+Apollo:

  1. Battle tested. Apollo might have been labeled production ready, it has nowhere near the usage of Meteor, so there will be a lot of rough edges and untested scenarios.
  2. Database reactivity. Apollo has a very initial version of reactivity, but that’s at this moment nowhere near what livequery offers.
  3. Backwards compatiblity. Meteor always took BC serious. Apollo+Webpack 2 is very new, so breaking changes are likely
  4. Framework is quite complete and needs very little configuration. You can start coding in under a minute without having to think a lot about the framework. Of course, there are probably boilerplate projects available for webpack+apollo, but as soon as you want to do anything different, it’ll cost you time.

What Webpack+Apollo delivers over Meteor:

  1. Better rebuild performance (and hot module swapping etc). Although Meteor 1.4.2 closes that gap a little bit.
  2. Code splitting
  3. More flexiblity in the build tool (chaining of loaders etc.)
  4. More flexibility in the data layer (choose “any” database.)
  5. Define queries in the UI. Although to enforce security the current idea is to extract the queries a user may execute with a build tool and store this set of allowed queries. You could basically do the exact same thing with livequery. So I don’t know how big this advantage is in practice.
  6. A data fetching language which might become a widely adopted standard. Emphasize on “might”

Btw, don’t forget Meteor + Apollo + React is also possible.


#10

I just made a video about my thoughts on Meteor + Apollo, maybe it’ll be helpful:


#11

@sacha

Saw your mention on Grapher. Wanted to share my thoughts a bit. First of all thanks for the mention!

Apollo+GraphQL is a data layer, meaning mutations and data fetching are done through the same “system”, while Grapher is a secure data fetcher and relationship manager for MongoDB. I insist on secure, because securing a data graph was one of the biggest challenges I faced, what fields to allow/disallow, how deep can the graph go, and all this logic has been put into it.

So the only thing it has in common with Apollo graphql, is the fetching data as a graph thingie, except Grapher is MongoDB only. And the “query” is not a separate query language, it’s your friendly javascript object, which can be dynamic & manipulated with ease.

It’s tied to Meteor because we wanted reactivity (Something that Apollo does not have and does not plan on supporting officially), it can be untied from Meteor, but it then becomes tied to MongoDB and we can still expose it to NPM. However, for now that’s not in the plan, you want to use this software ? Go Meteor, it’s something exclusive, it’s crafted for it.

Keep in mind, you can have links that communicate with any type of database:

But you need your root to stay in Mongo.

We had to make a hard choice on grapher: “Satisfy all databases” / “Make MongoDB fetching performant as hell”. We chose the latter from our business perspective. Also, we can integrate Grapher into Apollo for it to benefit from the technology we built for highly performant mongodb queries.

How performant ?

Apollo cannot do this, not because they don’t want to :smiley: but because what we built specifically applies to MongoDB and uses its technologies to achieve this.

Grapher was the first step in scaling Meteor, by allowing us to link data with ease and fetch it without hassles, securely and without boilerplate. Next step was Redis Oplog, which today is now released on atmosphere:

https://atmospherejs.com/cultofcoders/redis-oplog

There is a very important principle in programming (and in life):
“I don’t know the key to success, but the key to failure is trying to please everybody”

Apollo, is something that would have Grapher integrated in it. It’s not a replacement for it, for sure!


#12

why you say that? I thought apollo was reactive from the ground up


#13

Apollo is reactive within the client (meaning if something changes in the store, in changes in the UI), but there’s no client-server reactivity like in Meteor out of the box (which is a good thing imo).


#14

@muaddib

https://forums.meteor.com/t/the-meteor-chef-an-introduction-to-apollo/31003/3?source_topic_id=31088

It may be a plan, I also thought the same thing as you, but this is what Sahsko said about it.


#15

Well, true, that’s because redux is playing an important role. But look at my comment above. “Client-server” reactivity was the “wow” factor that made us switch to Meteor. That was it. Reactivity done easily, making mobile applications in the same code-base ? Well heck, that’s the future!


#16

Thanks for the additional details. The reason why I compared Apollo and Grapher is that for me they both solve some of the same problems I’ve had with Meteor’s default pub/sub strategy:

  • Bad performance because of the all-real-time-all-the-time approach.
  • No easy way to handle joins (the graph aspect).
  • Need to specify in advance what data is published instead of letting the client ask for what it needs.

#17

@sacha it was a very good comparison, I thank you and I am honored to have it compared to Apollo don’t get me wrong on this.

This is what we aimed to solve inside Meteor as well. They might solve same problems, but they are so different in so many aspects…


#18

Ouch, I am in a frustration of whether to choose Grapher or Apollo
Dilemma!


#19

So Apollo can use the technology grapher used for linking elements and performance tweaks that apply to MongoDB. So it doesn’t mean that if you choose Apollo you can’t use Grapher, ofcourse you can.

However, they are very separate as concepts, because Grapher is not a data-layer, Grapher is a meteor package, something pluggable, something that is integrated with SimpleSchema and your collections without doing most of the work. + It has a lot of security features, something that’s super hard to do manually for graphed data


#20

I am about to pick Grapher then. I have several Client projects and our in-house product WIP heavily relying on SimpleSchema and AutoForm. Grapher shall be my most reasonable pick for now.

On the other hand, I see Apollo is trying to gain popularity I see many new articles this month tutoring about Apollo + React. I can see we shall need to pick up Apollo next year too, no exception.

#toomuchjavascripttolove