@a.com – agreed!
@sashko, is this something you can help us organise? If so, we could set up a call. The foundation could even help offset MDG’s costs and investment. Features can be financed and developed based on community needs, while you guys focus on what is core and essential for your near term. The foundation could also be an asset for MDG, as a direct arm into the community.
We’re putting in a lot of work, especially in the last few months, to empower meteor contributors and community, and we would certainly appreciate more help! That’s something @zol spends a lot of time thinking about.
Blaze will work just fine with Apollo. The current React bindings for Apollo were built and are being maintained by the community, I really hope someone will step up and do the same for Blaze!
Just stirring the waters here (now that Blaze is set loose 
- any news on Apollo/Blaze front?
Still waiting for someone excited to use this in production and become a maintainer!
If this is something you’re interested in, I’d be happy to walk you through building an integration.
Well, in fact, the reason for my question is that I’m starting a new project and I would like to use it in production, but I’d need it really soon, like in a next 2-3 weeks (for a pilot phase).
If you think it’s possible to do a usable version within said time frame, than I’d be willing to take that responsibility and would appreciate if you could help me out.
I think so - most of the complex stuff is inside the Apollo Client core, and the react/angular integrations are relatively thin. In fact, we’re actively trying to move more in this direction so that the integration layers are as small as possible.
I think you could get really far in 2-5 hours. The hard parts are (1) designing it to feel great to Blaze users, and (2) maintenance, bug fixes, and keeping up with new versions of Apollo Client.
How can we start? Perhaps I should create a repository for it, then we can discuss a design. Have you used Apollo or GraphQL before with React or Angular?
Please, anyone doing this integration, put much time and focus on this. I like this approach, but if this doesn’t work somehow, please have a smart interface, one that fits in with its current constructs.
Do you have any specific suggestions?
I won’t be of any use, as I don’t know a thing about Apollo or what the calls would look like. But if you don’t mind, I wouldn’t be shy about discussing how we should be thinking about this.
Very rough and simple example (please provide a better one if you like):
But typically I have a subscription in the onCreated:
var instance = this;
var reactiveVar = Session.get('reactiveVar');
var sub = instance.subscribe("persons", reactiveVar);
if (sub.ready()) {
// do something
}
Then in my helpers:
return persons: function () {
var cursor = persons.find();
return cursor;
},
or sometimes I’ll just get one value from the record (in helpers):
return fullName: function () {
var person = persons.findOne(userId: Meteor.userId());
return person && person.fullName;
},
Then in the template:
<div>
{{#with persons}}
<p>Authored by {{fullName}}</p>
{{/with}}
</div>
<!-- or just the value -->
<div>
<p>Authored by {{fullName}}</p>
</div>
According to your example we’d had something like the following:
{
person (id: "5") {
title,
first,
last,
address {
street,
...
}
}
}
I don’t know where something like this query would live.
This replaces both the subscribe and the find.
In the Meteor Guide, we’ve been saying: “It is best to place the subscription as close as possible to the place where the data from the subscription is needed.” https://guide.meteor.com/data-loading.html#organizing-subscriptions
GraphQL lets us embody this idea much more directly. So instead of:
Meteor.subscribe('x');
x = X.find({ x: true });
You get to do:
x = client.query(`
x {
field1
field2
}
`)
This gives you a lot of great benefits:
None of the code snippets you posted are surprising - that’s exactly what we recommend in the Guide as well, and I think the best we can do is carry those recommendations over, and add some stuff that takes advantage of GraphQL’s unique features too.
So… nothing about the subscription in the onCreated… we’d place the query in the helpers instead?
In the helpers:
return persons: function () {
var object = client.query(`
persons {
field1
field2
}
`)
return object;
},
Then in the template?
<div>
{{#with persons}}
<p>Authored by {{fullName}}</p>
{{/with}}
</div>
Yeah I think doing it in the helper would work! So I guess it’s the same as before, you just skip the subscription step.
So does this mean we should make a distinction between returning a cursor and a record for Blaze template consumption?
return cursor from helper:
return personsCursor: function () {
var personsCursor = client.query('
persons {
field1
field2
}
')
return personsCursor;
},
return just a field from helper:
return personFullName: function () {
var record = client.query(`
persons { fullName }
`)
return record;
},
And where is reactivity handled, within Apollo? So in the future, where would we turn off and on reactivity? For example, would we pass a isReactive on a field by field basis or something else?
return cursor from helper:
return personsCursor: function () {
var personsCursor = client.query('{
persons: {field1, field2}, reactivity: {field1: 1, field2: 0}
}')
return personsCursor;
},
Sounds good! Let’s start with a repo and some “quick start” docs to get me up to speed.
Unfortunately I’ve been too busy to fiddle with any of GraphQL and React/Angular beyond a few quick hacks out of curiosity, but I’m gonna dive into docs now so we can discuss it further.
This is probably the best thing to read: http://dev.apollodata.com/react/
We just rewrote it from scratch so it should be pretty complete.
There is no concept of returning a “cursor” or “field” from GraphQL.
Apollo Client has two methods: query and watchQuery. The first is a one-time fetch and the second is reactive. There’s no per-field reactivity right now and probably won’t be in the near future.
So this is where the integration would come in. Blaze is expecting something else?
I disagree - There’s no way Apollo will look like Minimongo, because it’s completely different. We need to find something that’s a natural way to use GraphQL together with Blaze, it’s going to necessarily be different from what we had before.