I recently created a code base called Wrapper.js, which combines NextJS, Serverless Framwork and Terraform within a Monorepo.
Table of Contents
What is Wrapper.js and why you should care about it
A TLDR from my previous blog post:
Wrapper.JS orchestrates these technologies into one neat solution, which would normally be difficult due to the complexities of each specialism (e.g front end vs back end vs cloud infrastructure).
How Wrapper.js combines these technologies
Without going into the actual detail of the code logic, I’ll talk through the way the codebase is structured so you can understand how the technologies work together.
Environment & Orchestration Files
Here is a view of the codebase, looking only at the index directories.
Looking at the code base in its most basic form, lets start by looking at the index directory files:
index.js bitbucket-pipelines.yml .env package.json devops/ backend/ frontend/
The nodejs wrapper script, that triggers logic based on the npm command that is executed.
The Devops Infrastructure
The devops folder enables the wrapper script (the root level index.js) and is also the home of the terraform code.
One of the core concepts of Wrapper.js, is the creation and use of environment variables throughout the stack. This, as well as running a local dev environment and cloud deployment commands, is what the scripts folder enables.
Terraform is configured in this codebase to dynamically generate and manage all cloud resources (apart from lambdas) based on these environment files.
index.js bitbucket-pipelines.yml .env package.json devops | └─── continuous-deployment | └─── Dockerfile └─── scripts | └─── next.js | └─── serverless.js | └─── terraform.js | └─── utils.js └─── terraform └─── main.tf └─── backend.tf └─── variables.tf └─── terraform.tfvars.json └─── modules └─── acm | └─── ... └─── apiGateway | └─── ... └─── cloudfront | └─── ... └─── s3 | └─── ... └─── ... backend/ frontend/
Contains a Dockerfile for the configuration of the ci/cd server that enables the bitbucket pipeline.
The Backend Services
Unlike Terraform, which is being used to create all architectural cloud resources, Serverless Framework is being used to deploy lambda functions only.
This means that within Wrapper.js, Terraform is creating a blank ApiGateway and Serverless Framework is modifying that API Gateway with end points that trigger lambda’s – further details on what is deployed in Terraform vs Serverless can be found here.
Back end code is organised into backend services, each service contains lambda functions based on the business logic that needs to be be performed.
index.js bitbucket-pipelines.yml .env package.json devops/ backend | └─── index.js └─── utils.js └─── serverless.common.yml └─── serverless.env.json └─── package.json └─── services └─── serviceOne | └─── serverless.yml | └─── package.json | └─── lambdaOne | | └─ lambdaOne.yml | | └─ lambdaOne.js | └─── lambdaTwo | └─ lambdaTwo.yml | └─ lambdaTwo.js | └─── serviceTwo └─── ... frontend/
A script to orchestrate the local host development, cloud deployment and removal of multiple Serverless Framework services through npm commands.
The Frontend Application
Last but not least, the front end folder contains the front end application which is written with ReactJS and uses NextJS as a framework for structuring the codebase.
index.js bitbucket-pipelines.yml .env package.json devops/ backend/ frontend | └─── .next └─── .babelrc └─── components | └─── ... └─── pages | └─── ... └─── public | └─── ... └─── stores | └─── ... └─── next.config.js └─── package.json
Standard NextJS directory that contains dev and build configurations.
This post has detailed Wrapper.js’s approach to how it practically structures the technologies in the same codebase.
I hope this has been helpful and that someone out there is able to use this (or parts of this) to help them!!
Hope this was fun to read – enjoy automating 😀