Robust Rest APIs with Serverless Micro Service

Robust Rest APIs with Serverless Micro Service

Category : Uncategorized

I’ve worked for various companies which both wanted to present a robust set of APIs on a single URL, as well as develop with a Micro Service architecture.  While there are various design patterns which I’ve used, the draw back in terms of complexity or singular bottlenecks for development and release always made that dream difficult.  It wasn’t until I got into serverless architectures where I’ve discovered that there is a simple way to build your robust verb based APIs while keeping the Micro Service architecture and mindset intact.

This blog entry is going to talk about how Lambda and API Gateway can be used in conjunction to allow you to create robust rest interfaces while allowing you to have multiple teams develop and own portions of the API without conflicts in the development or shared resources.

Leveraging API Gateway to decouple your API

API Gateway and Cloudformation nested stacks are probably one of the best combinations I’ve used when it comes to defining restful interfaces.  The first step is to leverage a basic design pattern where you’re going to define your parent API Gateway resource, and then define your sub-resources in nested cloudformation templates by passing in the API Gateway reference as a parameter.

This approach accomplishes two things.  First you now have a resource which can be deployed independently from other APIs, and secondly, you’ve created the framework for your micro service and their infrastructure definitions.  When deployed you’ll have a single url with a holistic and robust API.

The Lambda Micro Service

Once you’ve defined your parent and child cloudformation templates, which can either live together or be hosted in separate source control repositories, it’s time to build out your lambda micro services.  By leveraging the newly built child Cloudformation templates as container, we can now define our lambda infrastructure, roles, permissions and database resources (such as RDS or NoSql options such as DynamoDB).

Since we’ve built our child templates to only rely on parameters passed in, this enables us to deploy out a single resource to a test environment, or multiple combine multiple to generate our robust API capabilities.

Benefits to Approach

This approach, while simplifying your cloudformation templates and grouping together related infrastructure definition, also changes the way which new APIs can be developed in an organization.  Limitations around centralized resources goes away, multiple teams can work on different parts of the API in parallel, and finally your API components can be released independently, allowing your teams to move at their optimal rate without having to wait for other non-related aspects to get completed, integrated or through a UAT process.  From my perspective though, the ability to get a Robust API to market quickly, leveraging multiple teams, departments and vendors, might be the biggest reason to go in this direction.

Leave a Reply