VulcanJS: An Open-Source Project to “Meteorize” GraphQL
A full-stack app-building framework with React and GraphQL
This is a guest post from Sacha Greif, co-author of Discover Meteor and creator of VulcanJS and Sidebar.
When Meteor first came out in 2012, it put out a pretty groundbreaking vision: full-stack JavaScript, client-server reactivity, a unified development environment… And what’s even more amazing is that five years later, that original vision still hasn’t been matched.
Meanwhile, the JavaScript ecosystem has been making advances in the direction of modularity. The end result is a more mature, more solid JavaScript ecosystem thanks to amazing tools like React and Redux.
Still, what if there was a way to get the best of both worlds? In other words, the ease of use of Meteor combined with the flexibility of modern JavaScript libraries?
Note: just to be 100% clear, Vulcan is a community initiative and is in no way affiliated with the Meteor or Apollo projects. But I do think that they all work great together, as you’ll soon see!
Discovering Apollo
Before I go on, let me tell you a bit more about myself. I started using Meteor back in 2012 to build a little side project that ended up becoming Telescope, one of the most popular Meteor open-source apps.
As I was building Telescope, I also teamed up with Tom Coleman to take everything we’d learned so far about Meteor and put it into a book, Discover Meteor.
Despite my love for Meteor, over the past couple years I’ve started making efforts to broaden my horizons. I learned React (and ported Telescope to it), then got familiar with Redux, and six months ago started looking into Apollo, Meteor Development Group’s new GraphQL data layer project.
The Power of GraphQL
GraphQL is a query language that gives you a way to write a platform-agnostic, database-agnostic data layer and query it through a very natural and expressive syntax; and if you’re wondering what all the fuss is about, then I wrote the perfect blog post for you.
Since GraphQL is just a syntax specification, you need a set of tools to take advantage of it, which is exactly where Apollo comes in.
After a few weeks playing with Apollo and GraphQL, I decided to make the switch and port Telescope to this new data layer. At the end of the day, my decision boiled down to three main factors:
- GraphQL being database-agnostic means it’s easier to use databases other than MongoDB.
- Unlike Meteor, Apollo is not real-time by default, which means better server performance for apps that don’t need real-time.
- Apollo is not limited to the Meteor ecosystem, meaning a potentially larger developer community, more resources, more tools, etc.
But as it turns out, swapping out your entire data layer is easier said than done! And I soon discovered that Meteor had spoiled me in some aspects…
The Challenges of Apollo
When you stop to think about it, Meteor’s decision to use MongoDB both on the server and client was a stroke of genius when it comes to data updating: when a document is created or updated on the server, the same operation can be replicated on the client with no ambiguity whatsoever, all in an automated fashion.
Apollo, on the other hand, stores its data in a Redux store. While this is great in terms of flexibility and inter-operability, it does mean that when a new document is inserted in your database, Apollo won’t have a clue what to do with it.
In other words, once I switched to Apollo data sync was now something that needed to be handled manually for many operations, which as you might expect was quite different from what I was used to with Meteor.
But I did end up getting the hang of it, as well as understanding many other aspects of the Apollo stack. Which leads us to where we are today with Vulcan.
Vulcan: “Meteorizing” Apollo
Vulcan is the follow-up to the original Telescope project. It’s the result of all these months experimenting with Apollo, and all the many years using Meteor that came before that. Here’s a quick video intro about Vulcan, or else just keep reading!
In a nutshell, Vulcan is an app-building framework for Meteor architected around Apollo and React, and its goal is to bring Meteor’s original vision and simplicity back; except this time using modern, standardized JavaScript libraries.
In practice, Vulcan achieves this through the following core features:
Rich Schemas
In Vulcan, everything starts with your collection’s JSON schema. You can use it to specify field types, default values, and various other validation options, but you can also go much further, using it to control which fields should be published to which users, as well as which groups can modify any given field:
postedAt: {
type: Date,
optional: true,
viewableBy: ['guests'],
insertableBy: ['admins'],
editableBy: ['admins'],
control: 'datetime'
}Based on this information, Vulcan can then auto-generate your GraphQL schema from your collection schemas, saving you the effort of writing your schemas twice.
Powerful Forms
Having access to rich schemas also lets Vulcan generate and handle forms for you (like if Autoform had been baked right into Meteor).
In other words, if you mark a schema field as editableBy: ['admins'], then Vulcan will know to only show that form field to admins on the client, and disallow any updates to that field by non-admins on the server.
And since you have all the power of React at your fingertips, you can use any React component you want inside your form. Think datepickers, multi-selects, or even integrations with third-party services like Embedly or Google Maps:
Easy Data Layer
Vulcan also gives you a number of utilities and helpers to make using Apollo easier. For example, in order to load data on the client you can use the built-in withList higher-order component:
const options = {
collection: Posts,
fragmentName: ‘PostsList’
};export default withList(PostsList);
Just specify the collection to load data from, as well as a fragment (in other words, a list of field names) specifying which fields to load, and the withList function will do the rest, loading your data and passing it on to the PostsList component as a results prop.
And like I said, Vulcan’s goal is to “meteorize” Apollo, making it as painless to use as good old Minimongo. Which is why withList will also transparently take care of keeping your Redux store in sync with the database for you when it comes to the main insert/edit/remove mutations.
Enjoy Server-Side Rendering, User Accounts, and more…
So far we’ve only scratched the surface of what Vulcan can do. Besides classic features like a user accounts package and built-in server-side rendering, Vulcan also has packages for things like generating an email newsletter from your content, scraping URLs for metadata, as well as example projects such as Instagram and Hacker News clones.
…Or Don’t!
Vulcan was built with modularity in mind from the start, and the fact that it uses a package-based architecture means you can replace any aspect of the app with your own custom package without breaking the rest of the codebase.
What’s more, this philosophy extends everywhere in Vulcan. Would you rather handle your GraphQL schema yourself? Then just turn off schema generation and provide your own. Like to write your own higher-order components? Then just replace the afore-mentioned withList with your own tailor-made version. Anything that Vulcan offers can also be turned off if you prefer.
So Why Vulcan?
More than a list of features or technologies, Vulcan boils down to a vision: make it easier than ever to quickly build new apps, without sacrificing scalability and maintainability.
It does this by building on top of strong foundations, and in a way that lets you swap out any part at any moment.
Getting Started
So if you’d like to give Vulcan a shot, here’s the three things you need to do:
- Install Vulcan (5 min)
- Work through the Movies Example tutorial (45 min)
- Watch the Instagram Example video and go through the example’s code (30 min)
This should be more than enough to give you a good idea of how Vulcan works, and whether or not it fits your needs. And don’t hesitate to join our Slack chatroom if you have any questions, or just want to say hello!
