Sep 19, 2016
Creating a serverless web app with Airtable, Glitch, Node.js, Surge.sh & Ember.js
TL;DR;
In this post I show how I built a serverless CMS/Blog system based entirely on free and modern PaaS services such as Airtable, Glitch (formerly Gomix, Hyperdev) & Surge.sh.
The end result is:
You can visit it at: http://caring-eggs.surge.sh/
And check out the source code:
- Frontend: https://github.com/benoror/experiment_blog_xt014_d
- Proxy: https://github.com/benoror/proxy_blog_xt014_d & https://glitch.com/#!/project/keen-gorilla
Ok, tell me more…
Lately I’ve been thinking how server code is becoming less and less relevant each day, and how everything you needed to code back in the day is now offered as a cloud service at your disposal, such as:
Authentication/authorization (Auth0, Twilio), asset hosting (AWS S3), database (Firebase, Airtable), AI (google prediction API), payment processing (Stripe), etc…
The remaining parts of your app, the ones that make you “unique”, can be written in isolated & scalable modules in any language and/or framework of choice, which nowadays can be also easily deployed. Such easy-to-deploy, lego-like blocks of functionality can be achieved with modern services such as AWS Lambda, Zeit Now or, what concerns us today, Glitch.
Since I’ve been messing around with these ideas for a while, I decided to see how doable it really was by making a PoC:
A Markdown Blog system, à la Canvas or Medium, with Airtable as Database/CMS
PaaS Architecture
Disclaimer: I chose services I’m interested in and/or using at the moment, altough the stack can be flexible at every level:
Database/CMS
Alternatives: Fieldbook (see my related post) , Firebase Realtime, etc…
Node.js Proxy/Auth Backend
Alternatives: Heroku, Zeit Now, Parse, Aerobatic, AWS Lambda, etc…
Ember.js SPA Frontend
Alternatives: Zeit Now, Aerobatic, Firebase Hosting, Pagefront, AWS S3, Github Pages, etc…
Designing the Database Structure
Posts table
Authors table
Comments table
Crafting a nice client with Ember.js
I won’t enter into much details here, but I prototyped a blog app with Ember.js, using my own ember-airtable data adapter addon. If you like to learn more make sure to check out my post about it.
I chose Ember.js since it’s the framework we’re currently using at work (Nimbo X), but you can use whatever framework/library you like, say React, Angular, Vue, etc…
The Ember app’s source code is available at: https://github.com/benoror/experiment_blog_xt014_d
At this point Ember Data’s Adapter is pointing directly to the Airtable API URL while exposing the secret API token to the browser, which is clearly not an ideal situation.
To overcome this issue I decided to pull a trick up the sleeve…
Setting up an HTTP Proxy
Storing credentials in a server is a good idea to keep them private. Also interesting are the possibilities of this architecture, as we can provide other kind of functionalities at this layer, such as Auth (albeit our experiment might become less serverless), but that’s material for a future post.
First I decided to avoid reinventing the wheel and use http-proxy-middleware to redirect request to my Airtable API. The code snippet to accomplish it is:
Deploying the thingy…
Deploying an app into Glitch is a breeze, as you can import the code from a Git repository, or edit it directly in the browser:
Storing secrets
With Glitch you can set .env file with the API secrets, visible only to you:
Tip: If you decide to use Zeit Now they recently announced support for environment variables and secrets!
Now we can change our Ember adapter accordingly:
Surge.sh
As usual business, deploying to Surge.sh is a piece of cake. We can see the application running immediately afterwards:
End Result
Production Deploy
Airtable as a CMS
