Over the past 5 years I have been working with various serverless technologies, building APIs, IoT integrations, data ingestion pipelines amongst other things. Today, however, I want to share with you how we’ve built up our way of creating a frictionless development environment in which we utilize for many of our clients large and small. You’ll find that it not only saves development time, brings you to market quicker but also keeps your AWS bills cheaper and your site far more scalable. This is a multi-part series and will start off rather dry since we’re focusing on building up to everything you’ll need to have a highly scalable, flexible environment.What are we talking about exactly? Well, Serverless Framework, AWS, Express.js, Prisma, OpenAPI and GraphQL (among some other goodies intermixed here and there).

Overview

We’re going to start with a general overview of each of the tools that we will be using throughout the article, there are certainly more within each area but these are the largest ones that will dictate how we are programming everything moving forward.

Serverless Framework

The Serverless Framework is one of the largest frameworks for doing serverless based development on AWS and is integrated in such a way that using CloudFormation is built-in to the framework and coupled to accelerate the development timeline, bringing both agility and repeatability.

Express.JS

Express.JS is a fast, unopinionated, minimalist web framework for Node.js which is very well documented and extremely welcoming to new comers getting started in writing backends in node.js based on the connect middleware model.

Prisma

Prisma is an ORM that works with PostgreSQL, MySQL, SQL Server, SQLite and MongoDB. It has quickly become one of the best ORMs on the market for ease of use and packed with features that makes development much easier!

OpenAPI

The OpenAPI Specification allows us to write a specification document which documents our specification allowing us to easily share documentation, build out clients and mock our APIs through the tools in its ecosystem. I personally am a huge fan of creating my specifications with Stoplight.io.

GraphQL

We all know that GraphQL is great for front-end development, however, has historically been a horrible pain for backend development. Near the end of this series we will be using typegraphql with primsa to show you a painless execution to essentially build your entire backend off of a prisma schema by decorating your schema with rules.

Getting Started

Now that we understand the main players in the game, let’s jump in head first and start building out the base of our application. This area is fairly opinionated on certain development practices, but it makes everything run more smoothly for a team moving forward. At this point, we assume that you have node.js installed (hopefully through nvm) and using node.js v16.

Creating the Serverless Project

If you currently do not have serverless installed, let’s do that now npm install -g serverless or yarn global add serverless. Once that has been installed, to start our new project we are going to follow the guide by typing in serverless which will create the project in a subdirectory.

~/Projects ❯ serverless
Creating a new serverless project
? What do you want to make? (Use arrow keys)
❯ AWS - Node.js - Starter
  AWS - Node.js - HTTP API
  AWS - Node.js - Scheduled Task
  AWS - Node.js - SQS Worker
  AWS - Node.js - Express API
  AWS - Node.js - Express API with DynamoDB
  AWS - Python - Starter
  AWS - Python - HTTP API
  AWS - Python - Scheduled Task
  AWS - Python - SQS Worker
  AWS - Python - Flask API
  AWS - Python - Flask API with DynamoDB
  Other
? What do you want to call this project? frictionless-serverless
✔ Project successfully created in frictionless-serverless folder
? What org do you want to add this service to? [Skip]

At this point, we can now cd into our project and start leveraging the Serverless Framework. However, we have a bit of work to do before we start wiring everything together.

NOTE: I did skip over some implementation details here as you can also include serverless as an account for additional insights into your application as well as using that as a great place for interfacing for your organization which I highly recommend.

First, lets cd frictionless-framework and ls the directory, we can see that it has a few files in here. All of the files with the exception of the serverless.yml file are irrelevant, you may keep the README.md if you would like, but by the end of this article you’ll likely want to revamp it to ensure your team understands what is going on under the hoods.

Before we move forward with anything else, we’ll want to configure our development environment to ensure that our team is being consistent and we’re following the same processes.

Setting up the Development Environment

In our development environment, we force a lot of consistency which saves us all time by leveraging various tools to ensure commit message consistency, code formatting consistency, and linting and changed files. We do this with a variety of tools mainly:

• husky — which hooks into git for our commit hooks to call our various programs.

• lint-staged — which takes our staged files and validates them against our programs.

• commitlint — which validates that our commit messages are consistent i.e. (fix|chore|feat): message

• prettier — which ensures that the code style is consistent

• eslint — which ensures that we are following various rules

In our environment, I state that our opinion is that we do not have an opinion on code formatting, commit formatting, etc other than we enforce that we have it in place. This means we utilize the defaults of many of these tools rather than argue over semi-colons or no semi-colons, tabs vs. spaces, or any other code formatting argument that exists out there. Simply put, it’s a waste of time to even think about it, let the tools do the work and just follow the process.

Let’s get these installed shall we?

Once these have been installed, it’s time to start to configure each individual package.

.eslintrc.yml

Here we tell the system that it extends prettier and that we are utilizeing node and the latest version ECMAScript. You can define other rules inside of the rules:parameter if necessary (we often reject any console.* commands as that means you should be providing user feedback or logging it to an internal error tracker.

.prettierignore

Only thing we really want to ignore, is the code that did not come from us, otherwise, everything else is fair game.

.lintstagedrc

Most of the time, we really don’t care about reformatting markdown documents, etc. But we do care about the JavaScript files, feel free to add additional files as you see fit.

.commitlintrc.yml

We all want certain commit messages, the convention format means that you are prefixing your commits with:

(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test): message

This is useful to help for the people that just commit messages such as “wip” which is irrelevant especially when you are attempting a git bisect

Husky

Husky is our runner, husky handles our commit hooks and ensures that these things are running on commit.

Now we just want to make sure that in our package.json we now have the scripts prepare portion setup as follows to ensure that after a yarn or npm install that husky has been initialized to run our commands pre-commit.

What Now?

Well, now at every commit, we’ll be testing that our code formatting is consistent and fixed as well as that our commit messages are logical. What happens if they’re not??

Well the commit-msg filter will error not allowing us to commit if we’re not following the format, and between prettier and eslint it will ensure that our code style is consistent with everyone else's no matter how we wrote the code to ensure style guidelines. This means that code review will be FAR less about how many spaces / tabs or semi colons you used and about how you architected the application. The commit message will help us to identity when looking through git history what might have had an impact on the project when we’re bi-secting for a bug.

Next Steps

Following this article, we’ll start to discuss getting our CI/CD running so that we have an easy way of deploying and managing our serverless setup moving forward as we continue to add in the additional features that are necessary.