Apollo with Blaze?

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.

1 Like

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.

Meant to be a question, not statement of fact.

I’m trying to grasp the obvious here…

So without a Apollo + Blaze abstraction, any query using straight Apollo client inside the helper would be a straight Rest API call out to the Apollo client, and it will return a raw Json object?

It would be natural to have the queries inside the helpers I think. The Apollo + Blaze client we are discussing will abstract out the calls to the Apollo client correct, and this will be all its doing (it won’t be modifying Blaze itself)? And there will be no reactivity in the Apollo client, so there’s no way this abstraction will have reactivity. Therefore all these queries will one once on Temple render?

Agreed!

Apollo client is reactive. We just need a really thin bridge to convert an observable into a Tracker-reactive function, which should be about 3 lines of code.

Anyway, let’s see what @miro comes up with, then we can talk in much more concrete terms.

1 Like

Thanks for taking time out.

Agreed! I’m excited to see what comes out of this.

As an aside, if people here are looking for well-constructed patterns that maintain the Blaze split of data/view, check out this post. No helpers, access to template-scoped functions and data, and an overall (in my opinion) cleaner implementation of some of the main pieces of blaze. Since adopting this pattern, it’s hard to look back.

Also – Seeing posts like this, incorporating incremental dom, etc. is amazing to see, especially in light of how many times I recall seeing that “blaze is dying”…

2 Likes

Please post concrete design ideas here:

https://github.com/apollostack/blaze-apollo

CC @miro

Please make sure you have an in-depth understanding of GraphQL, Blaze, and Tracker, and intend to use this integration if it’s built, before proposing designs.

4 Likes

@miro will you give some insight into how you plan structuring the new API?

Sure, just let me get a hang of it first :slight_smile:

3 Likes

I now have two heroes - @mitar and @miro :slight_smile:

In addition to many great packages that have made Meteor so great to develop with!

2 Likes

@ramez, You’re working the incremental dom upgrade to blaze right?

Hey @sashko, I started to play with it and would appreciate if you could elaborate a bit on that one?

@miro if/when you have something to look at, can you share a repo? Honestly I haven’t had a chance to look much at Apollo yet but I would love to see early thoughts about how it could integrate with blaze

That’s the plan :slight_smile:

1 Like

I mean, if the client cache updates it will give you an update to your query result.

So basically this thin layer is just a way of defining helpers that will be refetched inside a tracker.autorun or using a reactiveVar internally?

This syntax is completeley wrong but are you meaning something like this(optimized)?

export const ApolloVar = {
      set(initValue,apolloQuery){
            var self = this;
            self.rVar = new ReactiveVar(initValue);
            client.watchQuery(apolloQuery, function callback(err,val){
                     if (!err){   
                            self.rVar.set(val);
                      }
              }
},
             get(arg){
                return this.rVar.get();
              }
}

so then we could init ApolloVar in onCreated and a use that var in a helper doing

onCreated():{
this.apllVar= new ApolloVar("initVal",'{ persons: {field1, field2} }');
}
helper: function(){
   return  apllVar.get();
}
2 Likes

This looks about right to me!