CodeParva Blogs

Do you intend to deploy SPAs using EC2? Here are few things to keep in mind

31 Mar, 2021

logos of Nginx, Angular, PM2, and Amazon EC2

Business Context:

We at CodeParva help our customers (Self Storage Facilities) in building their landing pages, to ensure the tenants can perform the majority of the core operations like Pay Rent, Move In & Reserve online from the comfort of their homes, without ever visiting the facility physically. And also help them in improving their local SEO rankings.

Deployment via EC2:

Ideal Solution:

One of the easiest ways to deploy a SPA is to integrate a CI/CD like Travis/Jenkins and you just trigger the command and it takes care of building and deployment on an EC2 server.

But this approach was not possible due to the way our current repositories that are hosted on a third-party

 vendor, where the webhooks are not supported currently out of the box.

First Solution:

This led us to follow the below process for deployments:

  1. Locally build the dist bundle.
  2. Compress the bundle.
  3. Transfer the bundle manually to EC2 server.
  4. Uncompress the bundle on EC2 server.
  5. Setup a nginx site configuration.
  6. And serve the website via nginx reverse proxy.

SEO Optimized Solution:

The above process caused us a few issues initially:

  1. The SPA was not optimized for SEO.
  2. Since we had multiple update requests for websites, the transfer & deploy took around 10% of our developers' time on a daily basis.
  3. Plus we were expected to build tenant websites for at least 100 of our customers.
  4. We needed to periodically upgrade our EC2 instance.
  5. Initial loading performance was a bit slower than what we expected.

Our first approach to ensure the websites were optimized for SEO, was to enable Server Side Rendering.

Major pain points in the current approach:

This solved the issue of SEO, but then it led to a few more pain points, as discussed below:

  1. Increased the memory consumption, since we had to keep the Server-side process alive via PM2. (We could mitigate by setting auto restart after 150MB memory consumption)
  2. Increased our EC2 operational costs since we had to upgrade the instance to the next tier frequently.
  3. Now since it is a Server Side application, it was not straightforward to deploy it behind a Cloudfront, to reduce the initial load latencies.
  4. Frequent downtime of websites, due to frequently running out of memory and requiring manual server restarts.

As it was evident from the above pain points, we needed a more scalable, sustainable, and cost-effective solution. To provide reliable and performant websites to our customers.

Therefore in our search for alternative solutions, that can work within our constraints. We found Netlify. We’ll explain how this was a Quality of Life change for both the Users & Developers, in our next article.

Visit CodeParva Technologies to know more about us. Linkedin | Instagram


Vinay Gopalaiah