Meteor vs Apollo

muaddib · November 5, 2016, 10:24pm

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?

vjau · November 5, 2016, 11:47pm

DB reactivity i think.

vikr00001 · November 6, 2016, 2:57am

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

muaddib · November 6, 2016, 10:16am

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.

vyky · November 6, 2016, 12:57pm

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

muaddib · November 6, 2016, 1:01pm

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?

diaconutheodor · November 6, 2016, 1:21pm

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

vikr00001 · November 6, 2016, 4:03pm

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

seba · November 6, 2016, 8:30pm

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:

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.
Database reactivity. Apollo has a very initial version of reactivity, but that’s at this moment nowhere near what livequery offers.
Backwards compatiblity. Meteor always took BC serious. Apollo+Webpack 2 is very new, so breaking changes are likely
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:

Better rebuild performance (and hot module swapping etc). Although Meteor 1.4.2 closes that gap a little bit.
Code splitting
More flexiblity in the build tool (chaining of loaders etc.)
More flexibility in the data layer (choose “any” database.)
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.
A data fetching language which might become a widely adopted standard. Emphasize on “might”

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

sacha · November 7, 2016, 6:30am

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

diaconutheodor · November 8, 2016, 9:01am

@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 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!

muaddib · November 8, 2016, 9:14am

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

github.com

apollographql/apollo/blob/master/design/high-level-reactivity.md

# High-level design

This is a high-level overview of the architecture of a reactive GraphQL data loading system, aimed at getting feedback from engineers who have been there and done that. We want to share what we’re working on to see if people find it interesting, and to validate our design against what others have seen in the field.

- If you haven't yet, read our [announcement post](http://info.meteor.com/blog/reactive-graphql) which outlines all of the problems we are aiming to solve.
- You can also read Arunoda's post that summarizes this doc: [Meteor's Reactive GraphQL is Just Awesome](https://voice.kadira.io/meteor-s-reactive-graphql-is-just-awesome-b21074231528#.3h3hmtbm2)

Here's a summary of the design in a diagram, which will be explained in more detail later:

<img src="reactive-with-mutations-diagram.png" title="Reactive GraphQL with mutations" />

## GraphQL

(You can [skip this part](#reactive-graphql) if you are already familiar with GraphQL)

GraphQL is a tree-shaped query language for querying a schema of node types. So, for example, if you have users, todo lists, and tasks, you might query them like this:

```
me {
  username,

This file has been truncated. show original

sacha · November 8, 2016, 9:31am

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

diaconutheodor · November 8, 2016, 9:31am

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

diaconutheodor · November 8, 2016, 9:32am

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!

sacha · November 8, 2016, 9:35am

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.

diaconutheodor · November 8, 2016, 9:40am

@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…

vansonhk · November 15, 2016, 6:16am

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

diaconutheodor · November 15, 2016, 7:09am

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

vansonhk · November 15, 2016, 7:38am

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