I’ve been working on a first draft for a Blaze integration. It has queries in helpers and has a lot of on control when needed. I’m trying to find a good balance between the reactivity we know and the way Apollo works.
Please let me know what you think of this! A prototype is on it’s way 
http://blog.jamiter.com/2016/10/03/blaze-apollo-a-first-draft
This looks great so far! Excited to see the prototype.
The draft looks very clean and easy to reason about, however I still can’t figure from this structure how it could work with apollo subscriptions (not watchQuery) and partial data load (what will be returned by queriesReady helper in that case?).
Maybe @miro has thought about it already
Thank you for your feedback!
About subscriptions: I’m not 100% into all the details yet, but we might be able to add a this.gqlSubscribe to the template, with its own functionality. The basics would be the same. I’ll try to think of a first implementation and add them to the draft.
About queriesReady and partial data: We could add an option to check if it should or shouldn’t wait for partial data. Something like this.queriesReady({waitForPartials: true}), and leave it up to the user if he wants to wait for them or not. I don’t know yet what the default should be, because I don’t have any experience with partial data yet.
@jamiter Thanks you SOOO much for starting this.
As the community takes over, we need heroes like you.
Can we put you down in the community maintainers list for this? See this post.
You’re welcome Ramez! See the post you mentioned for my reply. I would like to keep this thread on topic
I’d rather have my plan vetted by the users of my product than people inside the Silicon Valley bubble.
But that’s just it - they have listened to their users. Go back and look at the old Trello board, or look through the countless feature requests listed on GitHub. The highest voted Meteor requests all have to do with supporting databases other than Mongo and providing a better way to scale in an easy to understand and control fashion. MDG has definitely listened to its users, and has worked with its VC’s (and others) to find a way to please its user base, while at the same time turn a profit. Apollo is the new direction they’ve decided to head in to help address many outstanding concerns with Meteor, while at the same time open up countless new possibilities for both the Meteor user base and themselves. Apollo really does tick a lot of the Meteor feature request boxes, and tighter Meteor + Apollo integration is coming (but it’s already pretty good!).
Although it’s a good discussion, can we keep this thread focussed on the Blaze with Apollo integration? Thanks.
Edit: I mean the technical aspect of it.
And here it is! A first working version of the Blaze-Apollo integration. Something to play with during the weekend 
It’s still in it’s early stages, but queries work and mutations in the apollo client do show up in the template.
Here is an example app for some more context:
As always, feedback is appreciated!
P.S. If your near Amsterdam next week, join us at the Meteor meetup where we’ll discuss all the details of using Apollo with Meteor: