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:

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

https://airtable.com

Alternatives: Fieldbook (see my related post) , Firebase Realtime, etc…

Node.js Proxy/Auth Backend

https://glitch.com

Alternatives: Heroku, Zeit Now, Parse, Aerobatic, AWS Lambda, etc…

Ember.js SPA Frontend

https://surge.sh

Alternatives: Zeit Now, Aerobatic, Firebase Hosting, Pagefront, AWS S3, Github Pages, etc…

Designing the Database Structure

Posts table

https://airtable.com/shrwpGUmpyeRtvpfT

Authors table

https://airtable.com/shradskAUbxUeUPhf

Comments table

https://airtable.com/shriWy0K1HdG8qTs9

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:

Source Code Repo: https://github.com/benoror/proxy_blog_xt014_d

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

http://caring-eggs.surge.sh/

Airtable as a CMS

https://airtable.com/shrCOSd1PWB1mDFzG