How to Build a Serverless Website- A Brave New World
By: Anuj Kothiyal
Tags: Serverless Website, Learning And Development, AWS, Architecture, Microservices

I. Introduction

Having shared my experience of implementing microservices in a serverless style in my previous blog, let us iterate the design and learn how to build a serverless website. Since we are iterating and extending the initial architecture design, the focus of this blog will be leveraging existing cloud provider services to build a website.

II. Questions

Let me continue the story that took place in the mystical fairy cloud kingdom, where I was working on a digital transformation program as the Lead Architect. The challenge at hand was different from the phase1, and we knew the benefits of serverless design. The primary driver was still solving the business problem (that is what an architect does, and just not technical solutions- a topic worth a blog in itself). Let us focus on the main functional and non-functional requirements for this phase:

Build a website for back-office users: Allow back-office users to create, manage, and correct records via a website. Maximum re-use of the existing platform: Leverage existing AWS platform and design already built to support serverless backend. Role-Based access for users: Granular role-based access control to restrict the functionality features as per the user role. Integrated platform: Integration with existing Data services used by Mobile channel.

III. The Test

Addressing requirement 1 turned out the heart of this phase as the choice of technology and stack made vastly fulfilled requirements 2,3 and 4. My previous blog shared our journey with a hybrid mobile application built on the Ionic framework that used Angular under the hoods. So the first logical question we had to answer was which framework to use for the website. Supportability, maintainability, and extensibility were always on the mind. AWS allows static website hosting on S3 (magical serverless moment) without worrying about the fluff of managing any servers. Choosing this option allowed us to stay true to our serverless motto. The pragmatic options at hand were, either use Ionic for building a website or just vanilla Angular. Sticking to Angular would allow us to move developers across the team when needed, and fewer skills to worry about for supporting it later. We did a quick spike with ionic and figured overriding the styling of ionic components was very hacky. We didn’t see any benefits of using another framework on top of Angular. All this created enough doubt for us to go down the safer route to build our website using vanilla Angular. The result was a SPA (Single Page Application) deployed on S3 as a website.

Coming to requirement 3, we also had to ensure that we had some form of role-based access for our back-office users based upon their job functions. It was relatively straight forward. We extended the existing lambda authorizer to allow the new angular application (registered with the IdP as a client application) access to backend endpoints based upon their authorization level determined from the role embedded within the JWT claims.

We did not have to create any new microservice in the backend and were able to use the existing ones. After all, we just added another consumer or channel to our platform. Though we added more features to existing microservices (extension), the effort spent was mostly on the front end. What we had built in the previous phase, we were able to use nearly 100% of it. As the client channels/consumers integrated with the backend microservices, providing access to the same data services and fulfilling requirement 4.

IV. The Build

Let us understand the architectural design and see how the existing solution extended to support our new requirements.