Write less code, ship more apps: How Vulcan.js makes me an efficient developer

Published in

DailyJS

7 min readSep 18, 2018

This banner has been handcrafted with love. In case you did not notice, I am a developer, not a graphist.

Who hasn’t dreamt they could create web and mobile applications from scratch in a matter of days, while using cutting-edge technologies? With good programming patterns and a well-chosen framework, this dream is not as unrealistic as it seems…

Thinking in packages

Structuring applications in packages, when done correctly, has the tremendous benefit of allowing reusability across applications. See how Npm.js has allowed thousands of JavaScript developers to share libraries and saved zillions of hours of programming throughout the world.

The famous Node.js framework, Meteor, provides a fully functional package system out-of-the-box, and yet I believe it is one of the most underused feature of the framework. Too few apps I encountered in the wild fully exploited the possibility of a package-based architecture. Most of the time, packages are limited to low level features, while in theory they also allow to split business logic (e.g separating your forum from your back office from your core application…).

This makes sense, because thinking in packages is not easy at all. Beginners already have a lot of concepts to grasp, concerning Meteor but also web development in general. You can hardly split your app in reusable parts when writing it is already a lot of pressure.

One possible workflow is to write your app as it comes, and progressively split the monolith. Still, that isn’t half as easy as it sounds. Parts of the app may depend on each other to work, potentially with circular dependencies, or from common features, etc.

Another possibility is to write your app in packages from the beginning. This requires both a solid knowledge of the application domain and a solid experience in programming. Even very skilled developers can’t always get it correctly in the first row.

But don’t worry, the open source community is here to the rescue!

From Telescope to Vulcan

Telescope has been there to help Meteor users to structure their app in packages since the early hours of the framework, by providing a well-thought core architecture, as well as many independent and reusable packages implementing common features of a CMS (forum, notification, email management…). It served both as a backbone and as a boilerplate for Meteor apps.

And guess what, Telescope is not dead at all: it has been completely rewritten by its creator

Sacha Greif

, and is now one of the most promising JavaScript fullstack frameworks.

Remember the name: Vulcan.js. It’s kept up to date to the latest technologies, such as React or GraphQL, the new standard for API querying.

Its architecture is a great starting point but also an inspiration to whoever wants to write truly reusable packages and thus reduce development time.

Let’s take a closer look at Vulcan.js features that favor reusability.

Register everything

Register to share

An efficient pattern to handle common features while splitting the app in packages is “enhancement”.

A typical use case is routing. Application usually have only one routing system, but each package needs to define its own routes. Vulcan provides an addRoute function, that allows any package, well, to add its own routes to the app.

addRoute({
  name: 'forum',
  path: '/forum',
  componentName: 'Forum'
});

This way, a package can enhance the application by adding new pages. And if you remove this package? The additional pages simply disappear. This tolerance to adding or removing a package, even when it provides high level features like a forum, a blog or a whole backoffice, is a proof of reusability.

You may have noticed that in the example, we did not provide a *component*, but only a component name. This is because registration is omnipresent in Vulcan.

Register to customize

The registration pattern does not concern only routing, but also components, graphQL fragments, MongoDB filters… Enhancement does not only help to communicate with core functionalities, but also allows customization by replacing registered items.

Vulcan’s frontend used to rely massively on react-bootstrap. It has been improved by systematically using registered components. This way, the 3rd party Vulcan Material UI package is able to replace all the Bootstrap components with Material-UI components: you don’t need to change a single line of your application to swap out the frontend framework.

In this example, we define a basic button and use it. Registration allows other packages to override the underlying component and replace it, for example to improve its design.

Split concerns with enhancement

You are not always forced to do a full replacement. The addField method added by Vulcan is great to handle dependency between features related to collections.

For the Simply Charge application (see my previous article), one of my goal was to create a module to handle vending machines refillment. I already had a vending-machine package, but I did not want to pollute it with refillment features. After all, handling the machines and refilling them are two different things. Coupling them too tightly would make it difficult to swap the refillment management system with a new one for example.

Here is how the code look like:

The amazing thing is that the package which defined the VendingMachines collection knows nothing about this new field, and does not need to! So if I remove my refillment package.. nothing happens (except that the related feature disappear, of course), which proves that I correctly split my application.

Declare and conquer

A world of schemas

Outside of its package-oriented structure, Vulcan’s schema-centric structure is a blessing for reusability.

Working with a schema is not a new concept. The best examples are ORMs that helps you to setup a database structure and manage it based only on configuration files. Usually, they come with a pseudo-language that allows you to describe your data structures.

*A good old Mongoose schema, used to structure a Mongo database coupled with a Node server.*

But you know what is better than automatically generating your backend based on a schema? Automatically generating your whole app.

Meteor already allowed this by being an isomorphic fullstack framework: many of Meteor features are available both in the backend and the frontend with the very same syntax, which facilitates the reuse of schema related features, for example to automatically generate the UI.

Vulcan took this concept further by enhancing the aldeed:simpl-schema library, beloved by Meteor developers, and including an advanced SmartForm component out of the box.

The internal of the SmartForm are quite complex, but for the developer, its usage is trivial: pass a collection, and it generates a form. Inputs are fully customizable and you should barely need to write your own forms.

*The Vulcan.js schema centric architecture, a blessing for rushed developers*

This pattern can be seen as a declarative way to develop application. Configuration is split from implementation, which makes the latter fully reusable. After all, you don’t rewrite an application anytime the data are changing? That’s exactly the same principle, but at a higher level.

Meet “Awesome Vulcan”, our showcase app for reusability patterns with Vulcan

We used this principle on the demo application Awesome Vulcan. If you have a spare hour, take a look at the different underlying packages. For example, with the Vulcan Backoffice Builder you can auto generate a small back office for any given collection, based on its schema. The time saving is HUGE! And it’s just the beginning.

This administration page is auto-generated, depending on the provided collection schema. Adding a new kind of data needs only one line of code.

Form automated generation is REALLY cool. You can define your own reusable inputs if you have more complex data.

Schemas of the world

Now, let’s imagine that you are VERY lazy. But you aren’t, are you? Anyway, let’s imagine that you don’t even want to write your own schema. Then, you might be interested to know that some smart people took care of defining hundreds of schemas, about a whole lot of real life subject, and put them on an open platform, Schema.org. It can serve as an inspiration if you are not sure about the fields needed to represent a Customer, a Train Reservation, or, why not, a Zoo.

*No good article without a lazy cat picture.*

We even tried to convert Schema.org schemas into Vulcan.js compatible schemas. This is very experimental but it can give you a hint on the usage of a schema centric architecture: with some additional work, you could create an administration interface for any kind of data ever listed by humanity. Sounds great, doesn’t it?

Convinced? Then give Vulcan a try, it’s as easy as completing the amazing “Getting Started” interactive tutorial.

Not convinced? Comment and let us know why, we’d be glad to answer your questions and comments!