Apollo with Blaze?

apollo
45

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

46

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.

47

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?

48

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
49

Thanks for taking time out.

50

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
51

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
52

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

53

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

3 Likes
54

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
55

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

56

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

57

@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

58

That’s the plan :slight_smile:

1 Like
59

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

60

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
61

This looks about right to me!

62

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 :slight_smile:

http://blog.jamiter.com/2016/10/03/blaze-apollo-a-first-draft

9 Likes
63

This looks great so far! Excited to see the prototype.

64

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