Great News: Meteor/Apollo Integration Coming in 1.5

Awesome news from @benjamn in issue 7072:

… the current plan for Meteor 1.5 is to focus on Apollo/GraphQL integration, in order to support databases other than Mongo (among other important goals).

:rocket: :+1:


That’s super nice.

I’ve tried out Apollo with Meteor 1.3 and that works fairly well too. See http://sandbox.kā

I wonder what they are going to do.

1 Like

I don’t think it’s great news if you see at what cost it comes. npm-installable meteor was way higher on my wishlist.


It does work, but it’s a bit of a hack, since you’re using Apollo alongside things like livedata and DDP, which it doesn’t need. I imagine a tighter integration between the two will make more of the internal Meteor components configurable/removable, so it’s easier to leverage only the parts of Meteor/Apollo you want to use together.

I was a bit torn on this one as well. Ideally I want both, but I’m guessing that as they work on tighter Meteor + Apollo integration, they’ll be splitting up or modularizing more of the Meteor core. This preliminary work will help make things easier as they transition to npm later on.


So that means we will be able to turn DDP/livedata/etc. off? Will it be done automatically if we choose to go with Apollo? Does this also not mean that if we choose to go the Apollo way, we will have to leave DDP behind once and for all?

Automating all this configuration based on selections will be very neat, if that’s what in the works. I think this is a very good movement.

Sorry, but as my reply on the pull request stood with various open questions for two months, having an npm integration is magnitudes more important to residing teams than the next feature slammed onto meteor.

We should try out apollo with the meteor build tool? No thanks.

To those who are interested in real time systems that integrate well into existing build chains, you may want to check out

The video on the landing page also addresses the short comings of Meteor for npm and it’s build chain friendliness; which is one of the goals of horizon.

-> Get meteor on npm
-> Get apollo on npm
-> Archive the integration this way!


Is there any reason why MDG should give this a higher priority than the database thing? One of the biggest disadvantages of Meteor is the focus on MongoDB. If you need transactions you may go with a SQL database, if you need scalable live data you may go with RethinkDB - but both databases are only available with unmaintained plugins.

Adding Apollo into the stack is the next logical step for me. MDG doesn’t have enough resources to maintain all feature request at the same time - but I think we all know, that there will be an NPM version of Meteor in the future.

Grüße nach Köln

Most projects have already some sort of integration into node js currently running. It’s a no brainer to use meteor as a delivery pipeline as soon you add it to the existing node environment and are not required to transform the whole pipeline first.

And I don’t say apollo should take a massive step back, I love the project, but implementing it into the inflexible meteor build chain that receives continous heat over the past two years - gets sometimes more - sometimes less attention - is a nightmare.
(For years now, threads & problems like this Ideas For Faster Reloads )

I want to see meteor on the reliable and professional managed npm system with the rest of the JS community and than welcome any feature addition to the meteor system, leave it for installment via npm, or not.

I am personally really sick of “teaching people meteor” even though everybody already knows the node and npm environment perfectly well. And the barrier of acceptance is just getting larger. Especially in an Agile/Scrum driven environment.

Note: And rethink DB is a great data delivery pipeline.

Grüße zurück aus Köln :sunny:️!


MDG Magic 8-Ball

const numberOfPeskyCommunityQuestionsToAnswer = 3;
const potentialMDGAnswers = [ 
  'Definitely Maybe', 
  'Perhaps Someday Maybe', 
for (let i = 0; i < numberOfPeskyCommunityQuestionsToAnswer; i++) { 
      Math.floor(Math.random() * numberOfPeskyCommunityQuestionsToAnswer)



Well, for me one of the biggest current disadvantages of Meteor is lack of incremental loading \ code splitting - and they seem to totally neglect that one.


And also - they still don’t have a public roadmap available. Well, it’s 2016, I don’t even know what to say…

I also don’t really see why Apollo/Meteor integration is taking priority here… unless it’s for reactivity, it’s not impossible or even difficult to use other databases with Meteor currently

1 Like

It’s here:

Well, I’t s not a roadmap, just a collection of fixes for 1.4 and possibly 1.5.
Would you call that a roadmap? Where are concrete features tied to concrete update versions? Where are dates? Where is feature list?
Even old trello roadmap was better.

Definitely true - I guess one of the main reasons why I’m excited to hear about this is that for the past little while, it seems as though MDG’s focus has been entirely on Apollo. I get why, and I’m really excited about its progress, but at the end of the day I still love working with Meteor (as we know it today), and am continuing to build successful apps with it. I’m happy to hear that MDG is still showing Meteor some love, and is going to be breathing new life into the platform with tight Apollo integration. Shortly after that I’m sure the next “monetization strategy” shoe will drop, but I’ve been so pleased with Galaxy that I honestly can’t wait to see what’s next!

1 Like

Put another way, I’m happy to hear MDG isn’t planning on letting Meteor become introspective meme Pug …

1 Like

Horizon is the future. After a few days with it, I’m convinced. It’s Firebase without the nasty limitations. If your app is CRUD or mainly CRUD, I’d strongly suggest looking at Horizon.

In terms of advancing Meteor, integrating Apollo is the most bang for the buck.

  • Better caching and more controlable reactivity -> better scalability
  • Cleaner APIs
  • Better integration with Redux and React Native
  • Multiple DB support and removing Mongo dependency

NPM integration is nice, but I don’t think it solves as many problems.


One of our biggest problems is that Meteor is its own thing right now. It’s a platform I love to use, but it’s always a hard sell having to be stuck using it standalone. NPM Meteor is top of my list as far as getting other people on board with it, though Apollo is right behind it.

The biggest issue is testing tools, Meteor not being on NPM makes this so difficult. It’s a place I don’t have full control either so it’s other teams trying to hack them in then stuff breaking because of meteors current import transform situation.


as someone building production apps for clients Apollo/GraphQL is by far the most important next step. At the moment if we can’t use Mongo that means no Meteor, and honestly, fine-grained control of reactivity in meteor is long overdue.

Having Meteor installable via NPM offers little utility in my world right now, and the developer experience in terms of getting meteor setup is pretty great. Would it be nice, sure, but Apollo definitely offers the most bang for my buck.