A few months ago I started use Apollo in my new project (Express + React + Redux as front-end and Go service as backend). I already like how everything works together and also it feels like GraphsQL was totally right decision where to go next.
Last weekend I tried to look at how Apollo + Meteor looks like. And I’m very surprised, that they are still don’t have close integration and that 1.5 branch isn’t in active branched list
I like React, I like Angular2, I like Blaze and even Vue, but Meteor never was about front-end for me. It was always easy to bootstrap platform with awesome data layer. Technology changes and GraphQL is new king. Apollo is awesome solution, but now it’s easier to bootstrap GraphQL/Apollo on express/koa2 server + React as frontend than on Meteor + React/Blaze .
Guys, are you going to kill Meteor slowly and move into GraphQL/Apollo direction as much as you can? How about Galaxy? Will you allow to host other kind of node apps which use graphql-server + apollo-client? Maybe it’s time to create separate forum for Apollo/GraphQL community if Apollo is not going to be main part of Meteor any time soon?
It looked like most people using Meteor were looking for other improvements in the short term, specifically around build performance. The most recent versions of Meteor, especially 1.4.2, made huge strides in that regard.
We can’t do that many things at once since we are a very small company, so we decided to prioritize the needs of current production Meteor users over helping people integrate Apollo. I’m curious what you are referring to though when you say it’s easier to use express instead of Meteor - with Meteor it’s much easier to set up accounts, run the database, set up the build process, etc. All of our production apps are using Apollo and Meteor today. Is there a specific thing that seems worse with Meteor than Express, for example?
We’re using Apollo with Meteor in both of our production apps right this moment. So there is literally no blocker to doing that. That’s why further improving the integration doesn’t seem like a priority over things like build performance which are literally blocking Meteor devs.
FWIW we have some apps running on Galaxy too, using Blaze with Apollo with this package by @jamiter: https://github.com/Swydo/blaze-apollo. And we’ve shipped Meteor with React and Apollo. It already works; what I’d like to see in the release that incorporates a tighter Apollo integration is less boilerplate and things like automatic accounts support and subscriptions.
@sashko it also might help to describe what Apollo and Meteor working together look like today, and how that differs from an imagined Meteor release with Apollo support.
I have Apollo running in my Meteor app. It works great and is very easy to add to Meteor, i.e. not a lot of lines of code are required. All that’s needed at this point is docs such as the blog post @sashko will be providing. Some items that may be helpful to include:
Setting up the server side (complete code sample would be very helpful)
Dealing with CORS issues (I posted some sample code for this here)
Can Apollo do fully reactive data today, like pubsub + Tracker? I saw some talks by FB about adding it in GraphQL but I don’t know anyone who’s using those features. and am not sure what the subscriptions in Apollo actually use under the hood.
Apollo and GraphQL currently do not support livequery functionality like Meteor does, and probably won’t for a while until there is more of a consensus of how those should work in the GraphQL standard.
@sashko, have you taken a look at redis-oplog? I am sure you are watching the forum, this package solidly extends the current publish functions to incorporate redis as a pub/sub framework. Is that a route you can consider for GraphQL? We are using it in production and it’s working great (in fact, as more people move to it, the barrier to switching to GQL will be higher as we are getting used to scalable reactivity)
At the moment, reactivity in the nodejs world has a big void now that rethinkdb is gone (other than Meteor + redis-oplog). This could be a solid business opportunity for Apollo!
We’re hoping to incorporate some reactive stuff in GraphQL too! If the Meteor stuff works for you right now, there’s simply no reason at all to move to GraphQL :]
We have a GraphQL subscriptions package that works off of redis, so perhaps it will be easy to hook the redis oplog stuff into there but I haven’t tried.
Yes, Apollo handles automatically calling static queries when your component loads, and includes options for polling. There’s no server-side push except for GraphQL subscriptions, which run off of a message bus like Redis (or the oplog if you hook it up)