I hope you guys have heard about GraphQL. It’s a data layer from Facebook team. We launched a new online course which is very similar to BulletProof Meteor called “Learn GraphQL”. It was a major success and everyone loved it.
BTW: earlier, I told GraphQL was a bad thing. Yep I did
And that’s the one of the reason why we built the Learn GraphQL project. I blogged more about it.
GraphQL and Meteor
GraphQL is just a data layer(on server side) and it’s not realtime. But it’s pretty powerful and you may like it. Give it a try.
I’m quite not sure, how it’s going to work with Meteor. But I hope we can somehow make it realtime. Even without making it realtime, that’s be a good way to integrate other data sources with Meteor apps.
GraphQL is a very early product(just ~3 months old). But it seems to be doing pretty good job so far. Even if you don’t wanna use it, keep watching on what’s going on there.
Nice tutorial. Make’s the value of GraphQL a lot more understandable.
There’s a lot more elements and features to it than I initially understood. It feels like a design pattern with a bunch of little approaches for supporting the larger design pattern.
I’d be interested to hear if you agree and to get your take on how/what elements of that design pattern you could easily adopt with standard Meteor… e.g. like maybe a good first step is to have only a single publication for each collection, the publications can accept a lot of parameters from the client, the client is responsible for asking for the minimum amount of data from that publication and supplying the parameters necessary for that.
Sure, but minus an actual implementation of GraphQL what are some of the major the take away principles/ideas that would impact how you would architect a standard Meteor application?
Having studied GraphQL does that suggest anything about what a good approach for managing publications and subscriptions might be?
To illustrate what I am thinking:
Maybe publications should be setup to always accept a selector and all supported Mongo find options
Meteor.publish("books", function (selector, options) {
if checkIfUserHasSecurityForSelectorAndOptions(this.userId,selector,options)
return Books.find({selector}, {options});
});
but its the template subscription job to provide the selector and options that minimally satisfy the template’s needs.
I am reasonably sure that in Meteor this will actually cause some performance issues. Live queries on the database are deduplicated internally, but they can’t be if they are all slightly different.
There is a huge advantage to having a smaller number of pre-defined queries. In fact, I think this is one of the reasons they are having trouble implementing realtime functionality for GraphQL.
I think the ideal solution for this would be to compile all GraphQL queries at compile-time, and deduplicate them into the smallest possible number of actual database queries. Then you can have the advantage of writing code with GraphQL, but none of the issues of actually accepting arbitrary queries at runtime.
Yep you are so correct about it. We used to call it Observer Reuse in Kadira. But, this is happening at right now when we are using template level subscriptions. (specially if someone subscribing in the bottom layer of the template tree)
I’ve seen it in many apps at Kadira Support.
So, having a such query deduplicate thing will be great. But, I assume it’ll be pretty hard to do covering all the scenarios. Best we can do is to create some best practices like try to make Observer Reuse high all the time.
Part of the rationale behind GraphQL is to be able to write new queries (for instance on a mobile app) without modifying the server. This is also motivated by the need to serve queries from multiple versions of the same application, so if I change a query in myApp v2.0 the server will still be able to serve it on v1.0 as before. I’m not sure how that will work with “Observer reuse” especially if these reusable observers are determined at compile time (instead of runtime)?
How is security done with graphQL? With meteor publications I have to authorize once (when a user subscribes to a publication) and I have some context.
