Apollo with Blaze?

[aadams]

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;
},

[miro]

If you think it’s possible to do a usable version within said time frame

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?

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.

[sashko]

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.

So does this mean we should make a distinction between returning a cursor and a record for Blaze template consumption?

There is no concept of returning a “cursor” or “field” from GraphQL.

And where is reactivity handled, within Apollo? So in the future, where would we turn off and on reactivity?

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.

[aadams]

There is no concept of returning a “cursor” or “field” from GraphQL.

So this is where the integration would come in. Blaze is expecting something else?

[sashko]

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.

[aadams]

Blaze is expecting something else?

I disagree

Meant to be a question, not statement of fact.

I’m trying to grasp the obvious here…

There’s no way Apollo will look like Minimongo, because it’s completely different

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?

We need to find something that’s a natural way to use GraphQL together with Blaze

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?

[sashko]

It would be natural to have the queries inside the helpers I think.

Agreed!

And there will be no reactivity in the Apollo client, so there’s no way this abstraction will have reactivity.

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.

[aadams]

let’s see what @miro comes up with

Thanks for taking time out.

[vigorwebsolutions]

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”…

[sashko]

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.

[aadams]

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

[miro]

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

Sure, just let me get a hang of it first

[ramez]

I now have two heroes - @mitar and @miro

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

[aadams]

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

[miro]

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.

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

[vigorwebsolutions]

@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

[miro]

@miro if/when you have something to look at, can you share a repo?

That’s the plan

[sashko]

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

[tcastelli]

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();
}

[sashko]

This looks about right to me!