Comparing Frameworks for Node.js Serverless Apps

Cloud deployments have gotten more complicated over the years. That’s on them, but it’s not necessarily to a fault – there’s just so much more you can do now than in the past. That blossoming in capabilities really owes itself to each new service getting easier over time. AWS, Google, and Azure started offering to relieve the burden of on-premises computing infrastructure. Very quickly, users and providers were overwhelmed by demand and the proliferation of new cloud services. 

AWS launched in 2002, then started offering to replace on-premises infrastructure with its own. After Google and Microsoft launched their own offerings, Docker debuted in 2013 to organize (“containerize”) the multiplying number of services developers were starting to use. Kubernetes arrived soon after, and since then there has been a plethora of tools to try to make sense of Kubernetes itself. Obviously, this will be confusing for a novice, but it suffices to say for both the newly cloud-initiated and veterans that this is a lot of infrastructure to organize.

We’ve now arrived at the era of the poorly named “Serverless” architecture. In the same way that “in the cloud” doesn’t really mean a file now exists in the ether, “serverless” apps aren’t actually separated from servers. Serverless implies that developers don’t have to manage servers themselves (brass tacks: “serverless” apps are still on servers).

To clarify, these are Node.js frameworks for serverless applications. These are not Rest API frameworks, MVC frameworks, nor full-stack MVC frameworks. There are some great Node.js framework comparisons you can look at for more info. 

1. AWS SAM (Serverless Application Model)

Yes, AWS SAM has a squirrel as a mascot. Be warned, searching “Amazon SAM squirrel” returns A LOT of kids books about Sam-named squirrels

AWS has its own serverless framework called SAM. It’s open-source, with SAM and the SAM CLI both released under an Apache 2 license. The use of the SAM CLI to deploy an app is optional, or you can work through a third party-based pipeline. 

SAM has you model an app with YAML, but SAM also has its own syntax for functions and APIs. That syntax, which also deals with mapping and databases, is meant to be extremely simple. SAM is – as you might have guessed – pretty integrated with the rest of the AWS ecosystem, so it automatically takes an essentially shorthand syntax and expands it out to match CloudFormation syntax.

However, SAM’s main strength is also its main drawback – it is part, parcel and inseparable from AWS. On the one hand, there’s nearly a tool for every need: Use Cloud9 IDE for debugging, Lambda for serverless functions, CloudFormation for traditional monitoring, CodeDeploy for code…erm…deployment, etc.

AWS SAM architecture example (Diagram from AWS)

Additionally, SAM is newer relative to some of the other open-source options. That newness is probably, at least partially, responsible for the smaller community of plugin creators relative to some other solutions. 

Prereqs to installation include both an AWS account (plus IAM permissions and AWS credentials) and Docker. 

Update the installed packages and package cache on your instance.

1. Update packages:

sudo yum update -y

2. Install Docker.

sudo amazon-linux-extras install docker

3. Start Docker.

sudo service docker start

4. Add your ec2-user to the new Docker group (this way you can drop the sudo before each command):

sudo usermod -a -G docker ec2-user

5. Log out and log back in to activate the new Docker permissions. Just close your terminal window, then open a new one and reconnect to the instance where you just installed Docker.
6. Finally, install AWS SAM CLI

For ARM: 

If you’re using ARM architecture, the installation is really easy:

pip install aws-sam-cli

For x86:

Download aws-sam-cli-linux-x86_64.zip. Then unzip it:

unzip aws-sam-cli-linux-x86_64.zip -d sam-installation

And install:

sudo ./sam-installation/install

2. Architect

Architect (which you can also refer to as arc.codes, its URL, to avoid confusion when searching for info on the project) is another open-source framework, a part of the OpenJS Foundation with an Apache 2 license. It focuses exclusively on AWS. You can check out its GitHub repository for more details. Its maintainers call it an IaC framework (infrastructure-as-code) “at its heart.” 

There is support for some other languages in terms of function runtime: Python, Ruby, .NET, Java, and Golang.

This is where Architect’s focus on AWS becomes obvious. Despite it working as an independent framework from SAM, it still works through it in order to deploy an application. Architect takes application code in the form of an app.arc file, then compiles it into an AWS SAM app, preparing to ultimately deploy it in AWS CloudFormation. So while the bulk of your work is done within Architect, deployment means sending it through the very same conduit of tools that you would have had otherwise, had you just started building the app on AWS SAM in the first place.

But that is also an outgrowth of Architect’s original full focus on AWS, which it has tried to move away from at least slightly. It was once dependent on AWS API Gateway, it later moved to HTTP APIs. It also has its own configuration language – arc – that is easy to learn.

Its local development workflow lets you open an arc sandbox from Terminal. You can even test and debug the code offline.

Architect, Getting Started Quickly

It’s fairly simple to start a new project. Install a version of Node.js 14+. Then, open Terminal:

npm i -g @architect/architect

Create a new directory and a new app within it:

mkdir testapp
cd testapp
arc init

Start a local dev environment:

arc sandbox

Deploy to staging in AWS:

arc deploy

Finally, deploy it to production in AWS:

arc deploy --production

3. Claudia.js

Claudia is similar but has a little more going for it right now. It too is an open-source Javascript-based framework, but has about triple the activity and contributors on GitHub. Rather than a full-fledged framework, Claudia.js aims to be “an open-source deployment tool” or “deployment utility” according to its docs.

It’s also limited to AWS, but in this case API Gateway in addition to AWS Lambda. To that effect, it includes an API Builder which Claudia’s maintainers argue is “minimal and standalone.” It includes extension libraries both for API building and chatbot development.

It also has very simple commands. They also boast of being able to use NPM packages to build and deploy APIs without having to bother with an extra tool like Swagger. Some common configurations, like error routing or CORS support, are set by default in Claudia.

It has numerous extension libraries for different APIs, a straightforward versioning tool, and is extremely easy to learn (anyone with decent Javascript experience should get a quick grip on this one).

Claudia.js, Getting Started Quickly

Claudia.js is pretty straightforward when it comes to installation. Prerequisites include NPM, Node.js, and an AWS account with IAM and Lambda access. Install it using NPM and then create a designated AWS profile to connect it. 

1. FIRST, install locally. We’ll give you the fastest installation breakdown here, as a global entity (the easiest route according to Claudia’s docs):

npm install claudia -g

(You can also install it as a dependency, but even the dependency Claudia installation process is fairly simple)

2. NEXT, on AWS, create a profile with full access and/or admin privileges to 1) IAM, 2) Lambda and 3) API Gateway. 
3. THEN, set the AWS_PROFILE variable to whatever name you want (let’s call ours jeanCLAUDIAvanDAMN). Save the key set (presumably where you usually save your AWS keys):

[jeanCLAUDIAvanDAMN]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_ACCESS_SECRET

If you want to use a separate profile to access Claudia.js, you can create multiple thanks to the AWS Node.js API. Default access will go to the one you used for Step 3, but you can always add more:

AWS_PROFILE=profileNumberTWO claudia <options>

4. “Serverless Framework”©

I saved this one for last for an important reason: its name is confusing. It is definitely the most popular option for a framework to build and deploy serverless apps. But because of its name, searching for information about any (lowercase) serverless framework will inevitably lead you to info about the (uppercase) Serverless Framework©. (You could also stylize it “Serverless ⚡” to fit with its old logo).

There is way more to this framework though than just its marketing-friendly name. It has an extremely wide range of options. It works with all three major cloud services and supports more than 10 different languages. It also has a long list of plugins. And yes, it’s also open-source.

Again, it can handle multi-cloud deployment. That means you can use AWS Lambda with Amazon Cloud, Azure Functions with Azure’s cloud services, and Google Functions with GCP (Google Cloud Platform). 

But it goes further than all that. It offers real-time logging and metrics, dipping into some of the services you might expect from observability service providers. Its AWS monitoring will automatically include, for instance, Lambda logs, AWS spans, and finally HTTP spans. You can also turn off all those default settings in serverless.yml:

custom:
  enterprise:
    disableHttpSpans: true
    disableAwsSpans: true
    collectLambdaLogs: false

In contrast to a framework choice like AWS SAM, Serverless Framework has a large plugin contributing community. On the flip side of that, it has a lot of lower quality plugins. And being independent of a gigantic cloud ecosystem, it is dependent on third party tools for monitoring. That can make things more time-consuming, even if you would prefer to have those third party tools in your stack.

Even with those negatives taken into account, it is a lot more flexible than other tools. It is quicker to deploy serverless apps, provides detailed information about software updates *while updating*, and much simpler CLI arguments.

To install, make sure you have all the prerequisites, then simply download with NPM:

npm install -g serverless

Comparing Serverless Options for Node.js Frameworks:

This is clearly just an introductory comparison to the major frameworks available for serverless applications in Node.js. There are several other considerations to factor into making a decision on where to build most or all of your Node apps in a serverless architecture. Here is a chart comparing some of the main points. (Assume that prerequisites include at least Node.js 14+, NPM and a relevant cloud provider account with full permissions.)

Statistics in this chart are as of 30 March 2022. We will update these periodically.

That scalability and background processing fills in some of the few disadvantages of Node.js. Complementing an already event-driven runtime like Node.js with serverless architecture creates a potent base for a serverless application stack.No matter the language you choose, serverless applications are a step above what came before them. They have faster deployment cycles, simultaneous scaling while abstracting cloud infrastructure, and a lot of maintenance is handled outside your own organization.

Be that as it may, current standards of serverless debugging leave a lot to be desired. Debugging by individual lines is either limited or unavailable, and overly complex logging is the only alternative a lot of developers see to remedy that shortcoming. On top of that, you face the same challenges more commonplace with microservices: multiple configurations, multiple sets of permissions, and more chances to make an error in setting those up.

Let us know if you would like to see more information in a deeper comparison among these four or other serverless framework options for Node.js applications.