We reach to the fourth chapter of the Mailing List App series. In previous articles, we saw the project definition, we set up a development environment for the Backend API, and we set up the public website development environment too.
In the current post, we will prepare the Production environment deployment for our application.
You can ask why we are building the deploy before start coding the application logic? So simple, once we have the production infrastructure ready, we can start obtaining value from any feature we create.
For example, we can start by creating the mailing list subscription flow and putting it in production to begin collecting “clients” emails, before making any mailing distribution logic.
Of course, to do that, we need to prioritize what feature can impact better in our business logic.
2 Production Environment
Let start doing a small technical overview of the tools that we need. First, we will use the Serverless Framework both for the Nuxt public website and the PHP backend API. Also, we will use some different Amazon web services, like API gateway, Cloudformation, and Cloudwatch.
2.1 Preparing deployment
2.1.1 Serverless
What is Serverless Framework?
The Serverless Framework is an abstraction layer between the cloud provider and our lambda function. It gives an easy way to deploy serverless applications in many cloud providers using a YAML format file.
The Serverless framework has an enterprise edition with a lot of o features to facilitate serverless application management. You can sign up on the official website to check all its features.
In this tutorial, we will use the open-source version. It works perfectly to deploy javascript lambdas out of the box.
What is Bref?
Bref is a plugin for Serverless Framework. It allows deploying PHP applications as AWS Lambdas out of the box.
Bref is an Open-source project created and maintained by Mathiew Napoli(@mnapoli).
Using Bref, you can execute PHP functions, PSR7 Request Handlers, or most common PHP frameworks as a Lambdas without much effort.
We will use it to deploy our backend API and Admin area.
2.1.2 Amazon Web services
As I said before, we will consume several AWS services. More concretely, we will use the Lambda service withing an API gateway. We will also use a Cloud Formation stack stored in an S3 bucket to manage environment deployments. And we will use Cloud Watch withing S3 to store our application logs.
AWS Lambda
The series star, AWS Lambda, is a service that allows remote execution of some piece of code without the need to manage any server.
One of the most powerful features of a Lambda is the ability to autoscaling without any human interaction. Besides, Amazon offers a free tier that allows a million zero cost requests per month.
AWS API Gateway
The Amazon API Gateway will allow us to route HTTP traffic to our lambda entry points inner a unique domain. It will solve common problems like CORS, and it will let our application to deal with high traffic.
AWS Cloudformation
Cloudformation is a language provided by Amazon to manage AWS and 3rd party infrastructure as code. It allows managing all services using configuration files.
AWS Cloudwatch
Amazon Cloudwatch is the service used by amazon Lambda to store runtime logs.
2.2 Deploy Public Website
Great, now we have some background on the task we are going to do. Come on, let start by tweaking our Nuxt app to use it as a Lambda function.
In the current stage, you can check out the project’s Github repository on the step-2 branch.
Be sure that you have your AWS console access configured to use the Serverless Framework, and the Serverless Framework installed globally in your machine.
2.2.1 Tweaking Nuxt
Let’s start installing serverless dependencies for the project using our dockerized node.
docker-compose run --rm node yarn add serverless serverless-apigw-binary
docker-compose run --rm node yarn add serverless-offline --dev
With the above command, we install the serverless API gateway binary to allow serving static files, serverless online package to simulate lambda execution in our development environment, and serverless framework locally.
Now we have to tell the Serverless Framework how to deploy our application, to do that, we need to create a “serverless.yml” file in the public website root directory.
Now update “nuxt.config.js” file to use module.exports
instead of export default
because we will import it in nodeJs context.
We need some more dependencies to configure Nuxt as a Lambda function.
docker-compose run --rm node yarn add fastify fastify-static aws-serverless-express nuxt-start middie
In the first place, we will use Fastify as a node server, you can use Express too if you fill better with it. We will use fastify-static to serve our “website/.nuxt/dist” directory. With the nuxt-start package, we will get a faster bootstrap from our Nuxt application. And we will need aws-serverless-express to proxy HTTP traffic from Lambdato to our Fastify server.
Come on and create a server file.
We only need to create the Lambda function handler to have the Nuxt app ready to deploy.
2.2.2 Deploying Nuxt as a Lambda
Build the Nuxt app using the following command
docker-compose run --rm node yarn build
If everything works, the only thing we need is to run the serverless deploy command.
serverless deploy
Open your browser in the given URL. If everything is ok, you can see our Nuxt application deployed.
2.3 Backend API
The process to make our backed API works as a serverless function is quite straightforward than the Nuxt version, thanks to the Bref PHP package.
2.3.1 Setting Up Backend API
We only need to do two things, install Bref using composer, and ensure that our application writes on /tmp
.
From the backend API root directory, execute the next command.
docker-compose run --rm backend_php composer require bref/bref
Then create the serverless.yml
file.
We just need to set cache files to be written on the /tmp
directory of the Lambda.
2.3.2 Deploy Backend API
We already have everything we need to deploy our Backend API as AWS Lambda.
Now execute the serverless deploy command
serverless deploy
Open your browser in the CLI output URL in the /api/v1/
path and check if it works.
In the next chapter, we have to set up a domain name and use an API gateway to route the HTTP traffic for each application.
Conclusion
First of all, I want to thank you for reading to the end;-D I’m glad to wake up your interest.
In this long post, we touch a lot of concepts related to serverless infrastructure by doing a small overview of all AWS services that we will use for the current stage of the project.
Then we learn how to execute a Nuxt SSR application and Antidot Framework Backend API as serverless functions.
I hope you like it. Happy coding!!!
* Serverless Nuxt approach based on https://logaretm.com/blog/2019-08-29-cost-effective-serverless-nuxt-js/