Creating a serverless web app with Airtable, Glitch, Node.js, Surge.sh & Ember.js
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
Disclaimer: I chose services I’m interested in and/or using at the moment, altough the stack can be flexible at every level:
Node.js Proxy/Auth Backend
Ember.js SPA Frontend
Designing the Database Structure
Crafting a nice client with Ember.js
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:
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:
As usual business, deploying to Surge.sh is a piece of cake. We can see the application running immediately afterwards: