How Serverless Architecture brings the most agility to API development

APIs have become a strategic investment for any business going through digital transformation because they allow business data and functionality to be accessed from any device anytime, anywhere. That in-turn opens up a whole new, data-driven revenue stream for businesses.

However, developing APIs is a painful exercise filled with many challenges whether you develop the APIs in-house or you are depending on 3rd party consultancy to do the development for you. In either case, the API development powered by traditional architecture is slow, expensive and has a lower quality than what you hoped for. Add to this the over growing challenges of coming with new ideas for Apps while remaining agile with the same number of development resources if not less.

With all of the above challenges, you will end up having no time to focus on the features that increases the adoption of your APIs. The top features you need to focus on to increase adoption of your APIs are:

• Full working OpenAPI Specs for your APIs with "Try it now" feature working smoothly
• Smooth developer on-boarding process with first API call within 5 minutes
• API resource design that enables easy development of API clients
• SDKs and Sample code (with strong presence on https://github.com/) that enable front-end developers to easily experience the best practices in calling your APIs in a real-life App scenario
• Reliable, secure and high performing backend that can cater for an increasing load and spikes from the front-end Apps without interruptions
• Hackathons where you bring developers to make new Apps using your API in a short period of time

The above would require businesses to move from the traditional architecture for APIs to API Serverless Architecture. API Serverless architectures refers to applications that significantly depend on third-party services?(knows as Backend as a Service or “BaaS”). In our case here it would refer to APIs that depends on AWS Cognito Identity Pool, AWS WAF, API Gateway, Lambda and DynamoDB. With API Serverless Architecture, APIs, SDKs to call the APIs as well as infrastructure is ready for you after a little bit of design, configuration & scripting. This is in turn gives you a boost in-terms of agility, quality, far lower cost for the development of your APIs and so much time to focus on the top features to increase adoption mentioned above.

There are several technical capabilities and business benefits that makes API Serverless Architecture very compelling. Mainly, agility and cost of the implemented solution. The cost model of API Serverless architecture provides the best value for money and decreases your Opex dramatically.

Why do you need to care about API Serverless Architecture

The increased level of sophistication for customer experience requirements combined with the requirement to remain agile; while having the same number of development resources, make it too challenging to continue to operate effectively using traditional approaches toward a robust API architecture and development.

API Serverless Architecture proposed in the architecture of this article is mainly composed of AWS Cognito Identity Pool, AWS WAF, API Gateway, Lambda & DynamoDB which are all serverless components. The benefits of API Serverless Architecture can be summarised as follows:

1. Fully Managed backend: saves time & headache on designing building or maintaining infrastructure.
2. Scalable: designed to scale automatically to give you the throughput you require
3. Fast: high throughput at very low latency.
4. Cost effective: You don't pay for idle time where your servers are not carrying any load.
5. Durable and highly available: Consistent reliability and availability even under complex failure scenarios
6. Flexible: NoSQL database which doesn't have a fixed schema
7. Low Cost: simple predictable pricing model
8. Security: Out of the box find-grained security and event driven design.

With the above benefits, you can do so much more with the same number of development resources if not less and also your activities would be more config with little or no development. You can also leverage DevOps in Serverless Architecture by adding them as a development resources to the API development team without not much re-skilling as they already have experience with AWS and experience writing scripts which is the only two skills needed here.

How the API Serverless Architecture looks like

Throughout this section, I would be describing a design based on AWS technologies. I think you can use other cloud providers to achieve the same. The reasons behind choosing AWS, is the maturity and popularity of the platform compared to other cloud platforms which means more free support online that covers many business use cases.

1. Front-End Apps: A mobile app, website or in the case of the prototype demo associated with article, it is swaggerhub where you can make API calls.
2. WAF: Web Application Firewall provides caching and application security.
3. API Gateway: This where we include several security controls on the incoming API calls including allocated quota to API keys to control the max number of requests a particular front-end App can make within a timeframe. Here also, we can configure mapping between requests received and requests that can be understood by DynamoDB. We can configure schema to match incoming requests and if it doesn’t match, we reject requests.
4. Splunk Cloud: This is where we collect and index API call events and generate operational intelligence dashboards that can be used to make immediate critical decisions.
5. DynamoDB: Fully managed NoSQL database where we would have the Organisation data. It can act as the single source of truth for data or it can be fed data from the single source of truth system.

The below diagram illustrates the end to end process for exposing APIs and sharing them with external front-end developers.

1. Front-End Developer: Those are the developers developing front-end apps that calls the APIs.
2. myprototype.com.au: This is the developer portal where developers can signup, login and get the API key that would be used by front-end app to call the APIs. The API key is not used for security, it is used to identify which app is calling the API and apply the allocated quota policy.
3. Cognito Identity Pool: This is the identity store for developers where we will store developers signup details and API Key.
4. Lambda Function: Cognito Identity Pool has a trigger configured to trigger this lambda function after the user clicks on “verify” on the email that would be sent to verify the email the developer used to signup with. The lambda function here creates API Key for the developer after email verification and stores API key in the developer profile in Cognito Identity Pool. The lambda function here is written using Python scripting language.
5. Swaggerhub: This where API docs are created for developers to understand and try the APIs.
6. WAF: Web Aaplicarion Firewall
7. API Gateway: Controls access to APIs and proxy requests to DynamoDB, gets response back and send it to front-end apps.
8. DynamoDB: This where we store Toilets Map data for developers to query.

The 8 hours implementation

Your steps for exposing your data securely as APIs on serverless architecture can be summarized as follows:

1. Configure AWS Cognito Identity Pool for developer identities
2. Design Microservice APIs on swaggerHub using OpenAPI Specs
3. Configure AWS API Gateway with the OpenAPI Specs from step 1
4. Design the data in DynamoDB and load Toilet Map Data or any other data set from https://data.gov.au using aws command tool (aws dynamodb batch-write-item but there is a trick that can make it load whatever number you want it to load).
5. Proxy API requests to AWS DynamoDB.?
6. Protect APIs using API Key and configure Usage Plans Rate and Quota.

Bonus: Developer Portal Prototype Demo

With this article, I'm giving away a tested Developer Portal Prototype Demo to give you ahead start with the following features:

1. Developer Signup & email verification
2. Developer Login & OpenID Connect JWT Token Anatomy
3. Using Sandbox API Keys to make API calls from swaggerHub

When you login to the developer portal (after you verify your email), you can see your API Key and check your Id Token issued by AWS Cognito from the top right drop down menu.

You can experience the Developer Portal prototype demo at https://www.myprototype.com.au

Conclusion

API Serverless Architecture if designed very well, it gives you a boost in-terms of agility, quality, security, far lower cost for the development of your APIs and so much time to focus on the top API features to increase its adoption.

There are other AWS products that can provide a bit of fine-grained authorisation as well as third party products like Axiomatics Policy Server. In the next article, I will detail how you can achieve fine-grained authorisation on your data using all of these products easily and quickly. Stay tuned!

All of my articles can be found here .

Notice of Non-Affiliation and Disclaimer:?The author of the article is not affiliated, associated, , endorsed by, or in any way officially connected with any of the software product vendors (Amazon AWS, Github, or SwaggerHub) mentioned in this article, or any of its subsidiaries or its affiliates.