Apollo with Blaze?

apollo
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

65

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.

2 Likes
66

@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.

1 Like
67

You’re welcome Ramez! See the post you mentioned for my reply. I would like to keep this thread on topic :slight_smile:

68

I’d rather have my plan vetted by the users of my product than people inside the Silicon Valley bubble.

3 Likes
69

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!).

2 Likes
70

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.

5 Likes
71

And here it is! A first working version of the Blaze-Apollo integration. Something to play with during the weekend :wink: 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:

14 Likes