A little peek at the Serverless hype

Jan 19, 2020

Being a JavaScript developer, I have naturally felt insecure and outdated for some time because I didn’t know much about the revolutionary shiny concept of Serverless architectures. So I did what every modern JS developer does, I jumped headlong onto the hype train!

Serverless in a nutshell

Serverless applications are broken up into functions, and hosted by a third-party vendor (e.g. AWS) who charges the application developer only based on the amount of time each function runs.

The idea behind serverless is that it saves you from the tedious server management chores, one of the most important being managing scaling and resource allocation. In other words, if your application grows beyond your wildest dreams and you start getting a ton of traffic, the cloud provider will automatically scale your app and you can continue exploring the latest JavaScript shiny things.

It is important to keep in mind that developing on a serverless architecture does not mean there are no servers. Your code is actually executed inside traditional servers but you as the developer do not have to worry about stinking servers.

So the biggest selling points of serverless are:

  1. Easy scaling – you let the cloud provider do the hard work.
  2. Cheap – you are only charged for how much your functions are used.

There is also the added benefit that you can say you’re doing everything serverless – how cool does that sound?

An example Serverless service

The app: Display scraped posts from tech blogs

So, I was just bored one day and decided to go shopping for a new shiny JavaScript toy and found Puppeteer – a Headless Chrome Node.js API.

I just wanted to put my shiny new toy to use so I ended up using Puppeteer to scrape some blogs and display their latest posts in a single place. My non-existent reader can view the glorious creation here and also the Github repo.

A screenshot of the end result.

Puppeteer is an excellent tool in case you’re looking for a browser automation tool.

Serverless to the rescue

So as part of my scraper project, I have a build:prod npm script which does the following:

  1. Scrape the blogs with Puppeteer and save the results on the filesystem.
  2. Build the website with Gatsby’s gatsby build command. The website displays the scraped results.

Now, I didn’t want to manually run this build:prod command every day and deploy to production in order to scrape the latest posts. I wanted this process to be automated because automation is so cool.

Because I use Netlify to host my websites, I knew they had a featured called Build hooks which give you a way of triggering new builds and deploys simply by invoking a unique URL.

With all the wonderful serverless knowledge fresh in my mind, I found a perfect use case for it. I could create a little serverless service that made a request to the URL that invoked the Netlify build hook which in turn rebuilt and redeployed my scraper website!

Here is a breakdown of the flow:

  1. Schedule a serverless service to invoke Netlify build hook every 12 hours.
  2. Build hook rebuilds my site using the build:prod command – scraping the latest blog posts.
  3. Build hook deploys newly built site to production.

What a serverless application / service looks like

I used the Serverless framework to make it easier to build my service.


Serverless apps are essentially a collection of functions that do some particular task. For my very simple case, I just needed one function to invoke the Netlify build hook.

import axios from 'axios';

export const triggerBuild = async () => {
  // NETLIFY_BUILD_HOOK_URL is set in the AWS console.
  await axios.post(process.env.NETLIFY_BUILD_HOOK_URL);

  return {
    statusCode: 200,
    body: 'Build triggered successfully.'


The beauty of serverless is that I don’t have to provision a Linux server, install Node.js and setup a Cron job that calls my triggerBuild function. That is far too much work for so little.

Instead, utilizing the Serverless framework, I can create a serverless.yml file where I can configure events that should trigger my function. Events can be HTTP requests or in my case, a scheduled job that runs every 12 hours.

service: my-wonderful-service

  name: aws
  runtime: nodejs12.x
  region: eu-west-2

    handler: handler.triggerBuild
      - schedule: rate(12 hours)

The provider section takes care of hooking up the service with AWS and configuring the runtime (Node.js 12) in which the functions should run.

The Serverless framework is really awesome and lets you deploy your functions to AWS with a single serverless deploy command. If you decide to explore the serverless hype, you should really check out this framework to avoid dealing too much with AWS and getting DevOps fatigue (is that a thing? Must be…).

You can view the Github repo for my scraper service here.

The use cases & future of Serverless

Having a simple scheduled function / AWS lambda like in my case and building an entire or atleast a significant portion of your back-end using a serverless model is a whole different thing.

Admittedly I’ve only had a very surface-level exposure to it, but I’m skeptical that serverless is the right choice for a typical CRUD web API which is the wonderful land that I mostly work in!.

I suppose I will have to explore it a little more but for now I’m sticking to my guns – Rails, Django etc.