Too much indeed!
Apollo is gaining popularity and it deserves it, and as I mentioned, Grapher can be integrated in Apollo, for now we simply had to find a solution to solve the joining problems. We worked on a social network, and doing that in MongoDB without something like Grapher would have been an impossible task.
Yeah, somehow Meteorās growth is doomed by its own overwhelming PubSub nature
Meteor has few problems left, the problem with the pub/sub system we already tried to solve it (and we solved it), by moving to redis, and giving control over reactivity from within the app: https://github.com/cult-of-coders/redis-oplog You can now create chat apps, live games with Meteor, reactivity leveraged by Redis 
Genius! Genius! Genius!
Which now works with Apollo: https://github.com/nicolaslopezj/meteor-apollo-accounts
The way to go is: Meteor + Apollo + React
@janikvonrotz very nice!
But if we use Apollo do we have reactivity for our data ? Is this something you looked into and you can share your experience ?
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.