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.
Currently a blog post about how we (and others) are using Meteor and Apollo would likely fall short of an “official” or supported integration, but hopefully it would be helpful in the interim.
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!
So how does it interface with REST APIs? Does it do polling? For some reason I was under the impression that Apollo eliminated the need to repeatedly/manually call something like HTTP.get.
Apollo currently has publish and subscribe capability for reactive data. Here’s a link to a Stackoverflow page where I posted sample Apollo pubsub code in response to a question:
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)
Not to derail the thread, but I think rumors of Rethink’s death are greatly exaggerated. I wouldn’t be surprised if in 5 years it becomes the Postgres version of open source NoSQL.
I’m tackling it now. There are some good posts out there. What concerns you and maybe I can provide some links…?
Any links would be useful, especially regarding Meteor. I’ve found a few posts and stuff, but not many that give you tons of insight into the best way to set things up etc.
Off-topic though, do you know of a good way to integrate RethinkDB into Meteor? I still love Rethink, so it’d be great to use that in some way!
