Hello everyone,
As we dive deeper and deeper into Meteor & Apollo integration we are noticing that there’s a chunk of Meteor’s beauty disappearing. And that is the client/server abstraction. Meteor has made it so easy to perform db operations from client or subscribe to changes effectively.
My vision is to somehow bridge all these goodies, and have an Apollo back-end that is ready to scale and be used by non-meteor apps also. Another idea was to have a sort of:
apollify(Meteor)
It would create queries, mutations, subscriptions. But since we can’t distinct a mutation from a query from Meteor code, and the fact that current Apollo Live subscription mechanism is limited to one cursor/subscription, it would’ve ended up far from perfect.
This is why we can learn from experience and start fresh. And we could do things like:
// This would automatically create query,mutations
const User = morph({
type: 'User',
collection: Meteor.users,
name?: 'users',
update(context, {filters, modifier}, {modifiedFields, modifiedTopLevelFields}) {
throw 'Not allowed'
},
insert(context, data),
remove(context, selector),
find({filters, options}, context, ast) {
// Grapher, ofcourse!
},
// maybe something like this to bridge it properly with subscription
reduceParams({ _id }) {
return { filters: { _id }, options: { } };
}
subscription: true
})
// Then on the client
import { User } from '/api/morphs';
User.insert({}).then(() => {});
User.createQuery(`
firstName
lastName
comments {
text
}
`).query(variables).then(() => {});
const subscription = User.createSubscription(`
firstName
lastName
`).subscribe(variables).listen(() => {});
This can be done via npm packages, and we can actually benefit of this crazy simplicity in React Native also.
We haven’t started work on this yet, but we definitely think an approach similar to this gets us closer to making Meteor what it was, while retaining the ability to fine-grain queries however you wish, as-in if you want to use polling or some different fetchPolicy you could just write your own query and be done with it.
I would like to hear maybe some input from the community surrounding this ?
More precisely my doubts are focused around these questions:
- Is Magic that bad ? I love the fact how people easily fall in love with simplicity of Meteor, bringing that back makes a strong case in my opinion.
- Allow/deny security logic to be replaced with: https://atmospherejs.com/ongoworks/security
- Wouldn’t it be interesting to use this: https://github.com/cult-of-coders/mutations for actual Apollo mutations ?
