I just wanted to share a new spike that I made this weekend. It’s running @arunoda 's wonderful GraphQL package and a standard version of RethinkDB running the rethinkdbdash driver.
Also after taking a day to learn with @arunoda 's Learn GraphQL course and some tinkering on my own making a blog API I was really surprised at how easy it is! It’s by far easier than writing your own REST API.
### Create a new post (instead of a Meteor method)
If you're curious about how the meat of it works, GraphQL creates types that create 'model' (although it's not really quite a model) that can be referenced when you say, this post has a `Comment` or fetch me all `Comment`s. It refers to a row in the database.
This is much like simple-schema and publish-composite:
Comment = new GraphQLObjectType({
name: 'Comment',
fields: () => ({
id: {type: GraphQLString},
text: {type: GraphQLString},
// if author was embedded in the comment document you would just do this:
// author: {type: ... },
// but we'll demonstrate fetching from another table (or even db)
author: {
type: Author,
// when something asks for the `comment.author` key, fetch this and use returned val as that key
resolve(comment) {
return r.table('comments').get(comment.author).run();
}
}
})
})
Nice, I most likely will tomorrow unless something unexpected pops up.
Also speaking of example apps and PRs, do you think separating the mutations and queries out makes things easier to read or more complex? I can’t decide myself… to me it seems simpler but I guess the file jumping can be an issue too.
So basically everything except subscribe/publications which is great because i’ve always disliked that part about Meteor… the 20% use cases stole away any productivity the 80% originally bought me
In a Blaze app you can take the response (JSON) and insert it into a local MiniMongo collection and the rest of the app is ignorant of how data is fetched. If you needed realtime though, you would need to re-fetch every N seconds and re-insert for the UI to auto update. (GraphQL doesn’t support realtime yet but soon)
you would need to re-fetch every N seconds and re-insert for the UI to auto update
What happens if the data needed by a component doesn’t change between two fetches ? Is everything still re-sent and re-rendered ? That would be rather inefficient :s
Genuine question, I don’t know how GraphQL handles that kind of things.
Re-rendering won’t be an issue in React. It won’t re-render DOM.
This will be an issue if you are processing more than 10000 docs in the client.
If so, there are ways to deal with that too.
What happens if the data needed by a component doesn’t change between two fetches ? Is everything still re-sent and re-rendered ?
It depends on how MiniMongo handles new data… not sure if it will force a re-render. However, if it does force a re-render and it’s polling every say 30 seconds then it’s not that big of a deal as most UI will render in less than 16ms (to hit 60fps). If your UI is React then it won’t matter since the virtual dom would diff it.
GraphQL is more less like a Meteor method. However, Relay would have enough smarts to not re-render… but it’s fairly complicated. Luckily @arunoda wrote Lokka which is much simpler and uses Meteor internals.
Oh wow, I didn’t look close enough at that yet! I’m going to use this with my React Native app that’s already using flux and slowly sneak GraphQL into it
:
