The way to go is: MongoDB w/Redis Oplog (for scaling) + Meteor (for tracker/sub/pub & minimongo & meteor.calls & accounts) + Grapher (for schema & joins & selective reactivity) + Vuejs (or Blaze2).
Why do I need Apollo anyhow, when I only want to use MongoDB and want seamless reactivity? In my case why not use Grapher when I want schema and need to do MongoDB joins?
Ok, I need to do some explanations so people can understand the difference between Grapher and GraphQL(Apollo)
Grapher is limited to Meteor + MongoDB (Unless you use resolver links which can be tied to any db). If you want to expose Grapher as HTTP API (The graph requested will be in JSON format, you won’t have to parse it with GraphQL…), simply create a server-side route that accepts query as JSON, transform it to JS object, call the query (grapher query request supports authorization ofcourse), return it as JSON, it’s absolutely basic to do this.
Now if you plan on using MongoDB as your database, let me explain why Apollo is inferior.
In the early phases of Grapher if you had something like:
users: {
posts: {
comments: {text: 1}
}
}
It would do 1 query for users. lengthOf(users) queries for posts, lengthOf(allPosts) for comments. This will kill the database, locally for a relatively small graph it would’ve done ~2000 requests. ~3s . Don’t take in consideration the round-trip if your db is remote. I said to myself this is shit, so I began optimizing and gained 30x performance and resulted into 3 db requests. Crazy? Yes. True? Yes. And this number will exponentially increase if the depth of the graph increases.
The guys here: https://www.youtube.com/watch?v=Y7AdMIuXOgs have solved it for MySQL using JoinMonster. This is what Grapher would be for Apollo but for MongoDB.
Grapher has a built-in module for tackling relationships, even advanced ones like Meta and Many-Meta.
With Apollo you’ll have to manually do this, specify how you link collections, how to manage these links, and very important, how to secure it. Show different fields for different users, etc.
You will have to write the query for every collection you have as an entry point, and then repeat a shit load of code. This is not the case with Grapher. It automatically does that for you, it can stop certain links for certain users. Read the docs, you’ll love what was done there in Exposure. 
In the beginning I admit it. Grapher was using GraphQL, believe it or not. But then I realized why not stick to JS obiects. We will have absolute flexibility in doing the request. Mixins? Just create it as a module, import it and use it. Filtering ? We do it with $filters, and it is MongoDB style filters. Options for sorting, limit, skip ? Built in as you would do it in MongoDB without having to create a query with X parameters.
$filters and $options for related data. Without having to implement additional and security logic. A great deal was invested in securing the graph, and it took us ~6 months to perfect it.
With Grapher you have reactivity switchable on and off (except for resolver links that communicate with other services) your query can be reactive or non-reactive, it will be the same API for requesting it.
With grapher-live package you can test your query, and you can bypass firewalls for logged in user in Meteor. This way you can actually see live who can see what and get instant feedback. GraphiQL can still do that by modifying headers, but it would be a bit hard to do with Meteor, right? I may be wrong.
So, bottom line is, if you want to use MongoDB and Meteor as server-side, Apollo is a small child compared to Grapher in terms of features and performance, it will lead to unsecured and unperformant code, unless you write a lot of boilerplate. If not, Apollo is the way to go for sure, there’s nothing else out there that is better 
(And I trully mean it!)
Sorry for ditching Apollo right now, but I said that once it gets a little bit more mature, if no-one else does it I will apply the technologies in Grapher to Apollo, unless ofcourse someone else does it first!
@diaconutheodor You can have reactivity with Apollo, however, at drawback of a bit more effort compared Meteors out of the box reactivity: http://dev.apollodata.com/react/receiving-updates.html#Subscriptions
I don’t have experience with this yet. It is relatively new.
Here’s the example app I’ve built recently: https://github.com/janikvonrotz/meteor-apollo-accounts-example
Meteor is mostly used as a build system and striped down to a minimum. However, compared to a webpack-babel-and-whatever build system, it is much easier to setup, deploy and maintain.
@aadams Apollo has been built by some guys from the MDG. We will definitely see some kind of integration in the near future. When it comes to the view layer I personally don’t care if its Angular, Vuejs or React. However, React got a lot of fame (see state of JS 2016).
I recently learned about CQRS and it feels like a very reasonable approach. Using MongoDB as a materialized view you might get rid of any (dynamic) joins. Of course it might not be the best approach if you have a lot of very different views. But for me my current plan would be to go with pure Meteor only, no need for any fancy data fetching library (even though I am a big fan of Apollo).
Here is the project I got this idea from: http://slides.com/stefankutko/nodejs-microservices-event-sourcing-cqrs
Another plus of Meteor is the dedicated hosting solution.
I’ve added basic reactivity to my example app: https://github.com/janikvonrotz/meteor-apollo-accounts-example
Checkout the PostList component to see it for the client side.
As you might see it’s a lot of effort to do some simple subscriptions.
@janikvonrotz indeed . a lot of effort.
When I first saw Meteor ~1.3 years back. It made me fell from my chair: “It’s that easy to do reactive apps ?!” without having to write your own protocol for websockets, updating data, etc… you can create mobile and desktop apps from the same code with minor adjustments ? There was no more room for doubt there… we ditched Symfony2 and started focusing on Meteor. The first months were hell, close to zero clients, we barely could afford keeping the company going, but we pushed forward. And after the struggle came the rewards. And now it’s time to give back.
So that’s what conquered me, that “wow” effect it had from a simple To-Do List. Then the adventure began and oh boy, after they introduced React and module-based approach, there were only some few key ingredients missing like “Joining Data” and scaling the reactivity to make it trully Enterprise ready.
Right now what Meteor is missing, is a bit of marketing, and we are going to do just that. We’re gonna market Meteor and target it to:
0. Web designers that want to show-case their work/
@diaconutheodor @janikvonrotz @aadams
If you guys are still around, I’d love to hear your thoughts on the state of all this now. Vulcan.js is looking very promising combining Meteor + Apollo + React. Thoughts?
Hey Matthew. Vulcan.js is a framework for GraphQL and React. It merely uses Meteor as a build tool. Vulan basically delivers the same as Meteor does. An out-of-the-box solution with accounts, deployment, packages and other stuff. As always it depends on your requirements when choosing the right tooling. Is there something in particular you would like to know? Are you currently evaluating an app stack?
Hey guys, I find this discussion very interesting and enlightening. For now there is a lot of changes such as the completion of GraphQL’s subscription and Apollo fully supports it. What is your thoughts for the current situation ? How does reactive in data layer (DDP) compare to Event-based Subscriptions of GraphQL ?
This information should go into the Grapher docs in some sort as it’s the information many people would need today in order to actually understand how Grapher and GraphQL/Apollo are different, and therefore the question is actually not Grapher or GraphQL/Apollo but maybe both, none, or the one based on a particular need only fulfilled by one of them.
I agree with you, I added this task: https://github.com/cult-of-coders/grapher/issues/204 and I will explain.
Hi everyone! I’ve found this discussion while looking for the best stack for the IOT application I have to develop for the company I’m currently working at. I’m practically sold with vue for the frontend and I think Meteor would bring great value to the app with its out of the box reactivity. I’ll be the only dev working on this for a while so it makes sense that I choose a tool I feel confident with as Meteor. Problem is, my boss is worried about Meteor’s and mostly Mongo’s scalability and that reactivity always/everywhere could become a problem… so… that’s how I got here.
The app requirements:
The way I see it my best options are:
Meteor, Grapher, Redis-oplog, vue
or
Meteor, Apollo, vue
If I can’t convince my boss that Meteor is a good choice here I would have to go something like:
Webpack, Apollo, vue.
I would like to avoid this, since the boilerplate code would become quite hard to maintain for such a small team and we might have to give up on some of the easy to use Meteor sugar.
I see Grapher + Redis-oplog, as something far more maintainable and easier to learn than Apollo, although, not as flexible, since if we went that way we’d still be married to mongo, right? How much of a pain would it be to switch to another NoSQL or even a Relational db if we ever needed to?
If there’s anything else you can shoot my way to help me convince my employer to go with Meteor, I would very much appreciate it. I think I’ve wasted all my resources so far, but in the end I’ll have to go with whatever they choose.
Thanks!
This is not entirely true as Grapher already connects with other DBs using resolvers like GraphQL.
Thanks @martineboh that’s quite neat. Do you know how well does it perform compared to Apollo in that particular realm, if I where to connect it postgresql or cassandra?
Define “many”. Tens, hundreds, thousands?
I wouldn’t be worried about MongoDB scalability, there are some quite large customers using it. It is a lot about optimizing your queries and indexes. Meteor can be a bit more challenging as it has more moving parts to be worried about, but you will have those same issues with any other solution once you get to scale.
Thanks for the reply @storyteller. Many == thousands of users and even more devices spamming data to our broker and the broker throwing it back at us. I agree with you completely in fact, I’m standing by that. The thing is, I have to convince my employer of that and I’m not as half as good a salesman as I am a software developer sadly! It’d be great to have something like a list of those “large customers” using a stack that includes Meteor. Maybe some that are using it with Grapher or Apollo to reassure my employer that this is a solution that better serves the requirements for our software.
Stackshare lists some of the companies that are using Meteor:
There may be less of a need for a “Meteor vs Apollo” debate since the release of https://github.com/Swydo/ddp-apollo.
I’ve been trying it and like it so far, especially because you don’t need to run a separate server as you normally would need when using Apollo. You can simply re-write an existing Meteor app to use Apollo (after adding ddp-apollo and the other standard apollo packages) and it will just work.
Then let’s start with the schowcase: https://www.meteor.com/showcase
If you search the forums you might even find other companies that use Meteor at scale.
Topics about scaling are also your friend. Like: Some scaling lessons I've learned growing to 120k+ users
Though it might be a bit more difficult to get names sometime as explained in Saas Mastermind Group by @thebarty via this: