Morphing Apollo deeper into Meteor

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:


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(() => {});
	comments {
`).query(variables).then(() => {});

const subscription = User.createSubscription(`
`).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:

  1. 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.
  2. Allow/deny security logic to be replaced with:
  3. Wouldn’t it be interesting to use this: for actual Apollo mutations ?

For now I can easily make a comment on 1. The Magic is what got us into using Meteor five years ago, and the Magic is still largely what makes us stick with Meteor nowadays.

Meteor’s reactivity & real-time by default was a real boon from the skies. If you knew what you were doing. If you didn’t, you would whine that Meteor doesn’t scale.

I’m certain that same goes for security, with allow/deny not being inherently insecure, but here I cannot comment much. We always used methods for mutations, mostly because we need to mutate data in a secondary DB, along Mongo.

It would be sad to see the real Meteor disappearing and leaving behind only (an otherwise excellent) build tool.

I genuinely believe you should start an OpenCollective / Patreon account so the community can support financially the multitude of goodies you brought to Meteor, including, hopefully, this.

1 Like

Thank you Manuel(@illustreets) for your feedback.

I’ll start with the bottom. Currently we don’t have a process set in place for that and if we do something like this we need to offer a concrete plan and roadmap, as a company we are going to continue growing Meteor regardless and I’m super happy other companies like Qualia share our vision.

I also think Meteor’s magic needs to stay alive, and keep the same simplicity, and also exposing a full GraphQL server that can be used by an external consumer would be a dream come true.

Meteor is much more than an excellent build tool. It’s a framework with a webserver included. With lots of tooling around Accounts and Mongo, RedisOplog, Grapher, Amazing modularisation (Packages), Assets, BuildPlugins – things that were possible thanks to Meteor’s simplicity.

I think the reactive data graph concept can also be solved quite nicely and using the same simple patterns.

We solve client-side abstraction using what I pasted in first post.

And next we solve optimistic-ui, by adding another layer over this:

So basically what’s gonna happen soon, is that we’ll have Meteor as we knew it, but as a bonus, have an Apollo powered backend which lets you do lots of crazy stuff + A strong UI integration with React.

Btw I know that you use Blaze in your app, give this a try: this is something other frameworks can only dream off, it almost makes me shift back to Blaze tbh… But I plan on doing the same with React, but it’s a bit more complicated, because @veered did a ton of hacks to make this work.


Oh, I completely forgot about qualia:reval. I remember Lucas posting on the forums about it, got excited, then got busy, then forgot to try it :slight_smile:

Thanks for the reminder.

Can’t wait to see your vision brought to reality!

1 Like

I’ve got a nice walkthrough of it in my Meteor talk!

1 Like

I installed it yesterday, and I can see it does a fantastic job! I just need to figure out how to make it not throw in the towel when editing .styl files.

Looking forward to your presentation. I’ve seen that everyone has uploaded their slides, but I’m waiting for the videos. I like going through slides after the videos.

This is live. we can now benefit of the elegance we had on isomorphic inserts on the client but using Apollo, and works with ReactNative and it is not bound to Meteor’s client, and works without a websocket? WOOP WOOP! This makes it super easy for beginners that just want to bootstrap their app!

As we know from Meteor’s old allow() deny() concepts, they are hard to secure, but that is true in some cases only, depending on your data model and business logic.

For example, when the update becomes hard to secure is when you don’t know HOW the field is modified, not which field. For example if you have a post that contain likedByUserIds a User cannot fully modify it, it can add himself to it, or remove himself to it. (

Therefore, what I recommend is completely block those fields and adapt them separately in a different mutation resolver.