Nova: making Apollo just as easy to use as Meteor

When I first started looking into Apollo a few months ago I was very excited by how flexible and powerful GraphQL is. But at the same time, I quickly started missing many things I had taken for granted in Meteor.

For example, with Meteor a list showing the contents of a Posts collection will automatically be updated with any new posts you create. With Apollo, you have to write logic to explicitly insert that new post in your data store.

I wanted to port Nova (the continuation of the Telescope project) to GraphQL without losing that ease of use, so I ended up writing a whole bunch of utilities to take care of that kind of details for you.

And I really think the new version of Nova we ended up with is now the easiest way to get started with GraphQL and Meteor.

In practice, here’s what you get with Nova:

  • GraphQL schema generated from your SimpleSchema schema.
  • A flexible schema-based permissions system.
  • Automatically generated forms.
  • Paginated list component for easy data loading and updating.
  • Mutation helpers.
  • Out-of-the-box SSR.
  • Easy internationalization.

And just to clarify, although Nova does come with features like posts, comments, etc. out of the box, all of this stuff is completely optional and can be removed thanks to Nova’s package-based architecture.

Next on our roadmap is focusing more on the performance aspect (now that we’re not using DDP, methods, etc. anymore we should be able to get rid of quite a few Meteor-only packages) and building out the ecosystem with themes, plugins, etc. If you’d like to contribute we could definitely use a hand! And it could be a great way for you to learn about Apollo and GraphQL :wink: )

If you want to learn more, I suggest checking out the brand new documentation, especially the Nova Framework tutorial. And of course, if you have any questions you can always come say hello in our Slack chatroom!


This should cut down on the learning curve (for those well versed in simple schema or mongoose)

I’ve been trying to track down how to do this in meteor!



Yay! :tada:

It’s a lot of fun to build things with Nova, in terms of learning and development experience :rocket:


I’m confused, is Nova a new framework that utilizes Apollo and is it reactive in the same way Meteor is?

1 Like

Good question. I was under the impression it’s a boilerplate. Basically microscope built with Apollo.

Yeah, that would be one way to put it. Basically Nova gives you boilerplate utilities on top of Apollo that save you the time of having to write all the “reactivity” logic yourself.

Thanks @sacha, anything to supplement the Meteor Accounts lib? Or has this been solved for Apollo? This is kinda a big deal right?

Great question. Nova currently uses the regular accounts package in combination with accounts-ui, but we want to switch to a pure-Apollo solution using meteor-apollo-accounts soon.

Beyond that I think the best solution would be using a non-Meteor library like passport but given the amount of work required we’ll probably stick with Meteor accounts for the foreseeable future (although if the Meteor accounts stuff ends up being released as NPM packages, that could probably work too).


I’d be very interested to hear more about your findings. Stuff like:

  1. Now you’ve made the switch. Is Apollo a big winner? Does it make sense to move from DDP ATM?
  2. What is difficult in Apollo that’s easy in ‘classic’ meteor?
  3. What is difficult in classic meteor that’s easy with apollo?
1 Like

I’m going to write a full post about this topic soon, but briefly:

Is Apollo a big winner? Does it make sense to move from DDP ATM?

It really depends. If you’re relying heavily on real-time and reactivity, I would say no. If you’re running into performance issue because of real-time, then maybe yes. If you’re planning on leaving Meteor behind (or would just like the option to do so) at some point and want a smooth transition, then definitely yes.

What is difficult in Apollo that’s easy in ‘classic’ meteor?

Everything related to data updating. For example, let’s say you have a list of documents sorted alphabetically, and you insert a new document in the collection. With Meteor, the item will automatically appear in the right place. With Apollo, you have to insert the new item manually in the right spot (or else reload the whole list from the server).

Another example: you’re filtering a list to only show action movies, and you edit a movie to set its genre to “comedy”. With Meteor, the movie is removed from the list automatically, with Apollo you have to do it manually.

(Those are all things that Nova will do for you btw)

What is difficult in classic meteor that’s easy with apollo?

I always thought that Meteor’s pub/sub model was very confusing for newcomers. I think GraphQL makes a lot more sense. Define your GraphQL schema on the server, then ask for the exact data you need on the client, that’s it.

It’s also great to get the option to turn off real time, and generally have more control over your data. Even after years using Meteor I would still get UI glitches due to reactivity, with Apollo everything feels a lot more stable (and you also have tools like the React, Redux, and Apollo devtools to debug issues).


This looks good. Making things easy was Meteor’s main strong point.

A pure Apollo solution makes more sense, so I’m looking forward to the switch.