I agree with this 100%. If you’re getting ready for Apollo then writing methods over pubsub is well worth the investment. Migrating old code from methods to Apollo has been super nice. Still struggling with bugs in migrating pubsub.
The root cause for us was tracker and subscribes and all this jazz are hard to keep predictable. So just opens up a can of worms when moving it from pubsub which had its own set of characteristics.
With methods it’s quite predictable already so the migration was very 1 to 1.
Good to see both perspectives! Just wanted to chime in and say all of the stuff I have personally seen moved in our internal apps was pub/sub, but it’s good to know that migrating methods is easy as well.
For what it’s worth I think it might be nice to use Apollo with minimongo. I would have no problem with running GraphQL queries and depositing them into local collections. Maybe minimongo can be rebranded as a reactive cache and maybe the two actions could be integrated somehow.
I haven’t looked into Apollo too much. but here’s how I’d guess it should look in Meteor:
// run query
UserList = new Apollo.query('add-query-here')
// returns reactive data to template
UserList.data().fieldName
// re-run Query
UserList.update()
Yep, this is totally do-able. I wonder if you would want to wrap the GraphQL call with a function that will handle inserting the local collection? That might clean up some of the verboseness with Blaze. maybe something like the code below? (though if one is using React the apollo-react bindings are more simple since it has it’s own cache).
I think trying to shoehorn mutations into the minimongo API would be awkward since you tend to think differently about data.
Categories = new Mongo.Collection(null);
function getCategory() {
client.query({
query: gql`
query getCategory($categoryId: Int!) {
category(id: $categoryId) {
name
color
}
}
`,
variables: {
categoryId: 5,
},
forceFetch: true,
}).then(({ data }) => {
Categories.upsert(data._id, data);
}).catch((error) => {
console.log('there was an error sending the query', error);
});
}
I don’t know after writing this out maybe a better approach would be to create some kind of Blaze bindings to get a more similar API like apollo-react?
// A bit verbose since we intend most people will use an integration
const observableQuery = client.watchQuery({ query: `...` });
observableQuery.subscribe({
next: (data) => { ... data here ...}
});
observableQuery.refetch();
Most people use it through react-apollo or angular2-apollo, though, which looks more like:
graphql(`query`)(MyReactComponent)
I’d imagine the Blaze version, if someone wanted to build one, would be something like:
If you are the maintainer of the Blaze-Apollo integration, you can make it look however you like :]
I had a few ideas for a Blaze-Apollo hyperframework (IDK if that is a word) where you would basically write zero code, and your templates would look like:
<template name="stuff">
<graphql>
query allPosts {
posts {
id
title
votes
author {
id
firstName
lastName
}
}
}
mutation addPost($id: ID!) {
addPost(authorId: $id)
}
</graphql>
<div>
{{#each post in posts}}
<h1>{{post.title}}</h1>
<p>By {{post.author.firstName}} {{post.author.lastName}}</p>
{{/each}}
<button onClick={{addPost(id = post.author.id)}}>Add post</button>
</div>
</template>
We’re probably a while away from building apps like that, but I think it would be super sick. Basically, the data “just shows up” when you need it, you can define all of your data updates in GraphQL, and then you just need a server. Jonas has some ideas for how to make the server super trivial as well.
Anyway, this isn’t at all what we are prioritizing right now, or probably for the next year. But it’s a glimpse into what I mean when I say “GraphQL doesn’t have to be complicated”.
*hyperframework: something that will blow your mind because the app just writes itself
Generating the query from the UI is definitely mixing logic and UI
I kinda like the idea of writing it twice, and having the UI check if it’s consistent with the query. Otherwise, you have to reimplement all of the features of GraphQL (directives, fragments, type conditions, aliases, and more) in Blaze, and that doesn’t sound great at all.
(bonus point) Using the GraphQL language directly will make it easy to integrate with existing and future GraphQL tools, without needing to build a special tool for the BlazeQL language.
I don’t see how you figured that. The idea here is the build tool will magically construct the query from the handlebars and then embed the code into the application.
Hmm, I think magic opens a lot of opportunities here
Sure, but not relevant in the context of a goal to build a hyper framework.
Anyways, just a wild idea. Not sure how much effort its worth yet.
Yeah, I guess in my mind there are some things that improve code clarity, and IMO GraphQL query strings are really clear where HTML and property accesses aren’t, especially if you add custom expressions, helpers, etc.
The build tool can parse the template file, extract all the data fields necessary, and then bundle a query into the app code files. It’d be like a cracked out transpiler.
