At GoDaddy, Charlie Robbins is heading the Warehouse.ai project, a framework that enforces a coherent workflow for serverless front-end deployments. In his talk at Node.js Interactive, Robbins said that deployments are all about serving new functionalities to visitors. Most Node.js front ends have some code asset — an app written using React, Angular, JQuery, or whatever. You push the code asset onto the server, and it ends up co-located with the server. Then it is served to users/visitors.
Version your assets
A typical example is one where you have an Express app that you use to serve up static middleware. Inside your HTML, you have a link relative to your URL, something like:
<script src='/js/app.min.js'></script>
The problem is that any change to your front-end requires a server change. This makes using a CDN imperative for any serverless deployment. Because, otherwise, your front-end assets are associated with your back-end project, and in every deployment, you deploy both of them.
One step in the direction of solving this (i.e., making updates to the front-end code *only* about the front-end code) would be start be taking the link relative to your URL and changing it to something that is relative to the CDN. This could look something like this:
<script src='https://yourcdn.com/app.min.js'></script>
But, any change made to the front-end still requires a server side change due to the fact that URL is still static and completely unversioned.
So what does a versioned asset look like? You could use semantic versioning, like you use with Node:
<script src='https://yourcdn.com/1.2.3/app.min.js'></script>
Or use a SHA compiled from the asset:
<script src='https://yourcdn.com/a023ffe/app.min.js'></script>
The latter is probably the best way to version your assets, according to Robbins. A SHA will almost always be unique, it doesn’t have to change over time, and it can be really useful when you’re trying to find assets.
How to approach serverless deployments
When you send your code to your CDN, your app sends out a query to ask what assets it should serve — what should it put in the script and link tags that exist on the page? That is what is shipped down to the customer. The users, instead of getting the assets from the server, get them from the CDN.
But how does the server receive new versions? How does your server know it has to serve this:
<script src='https://yourcdn.com/a023ffe/app.min.js'></script>
or this:
<script src='https://yourcdn.com/b347aa0/app.min.js'></script>
instead of this:
<script src='https://yourcdn.com/ff03598/app.min.js'></script>
Robbins says, “A serverless front-end deployment requires an external service knowing what version(s) should be running in what environments for any or all locales.”
Robbins then explained how, with Warehouse.ai, it was possible to create a workflow that is allowed to implement these services. The Warehouse.ai framework allows serverless deployments of your front-end code by providing automated builds pushed to any S3-compatible CDN through a simple npm-based workflow.
You can use npm publish to trigger a new build, you can promote or rollback a build you using npm dist-tag add, and, finally, if you want to see what build is in which environment, say, to see whether version 1.2.3 is in production and 1.4.0 is in test, you can run npm dist-tag ls.
Warehouse is an npm-publish proxy, which means it receives all your “publishes” and it then puts them in any npm registry behind the scenes. That is, Warehouse.ai is not private registry, but a proxy to a registry. When it receives a publish, it triggers a build for the assets you want to publish. And it will trigger that in any locales you configured. At GoDaddy, Robbins said, they trigger about 500 builds a day using Warehouse.ai and they build in 28 different locales.
If you would like to try it out, you can download all the code and documentation from GoDaddy’s GitHub repository. Note that Warehouse.ai depends on carpenterd, an API capable of building modules to run in a browser.
You can also watch the complete presentation below:
If you are interested in speaking or attending Node.js Interactive North America 2017 – happening in Vancouver, Canada next fall – please subscribe to the Node.js community newsletter to keep abreast with dates and time.
