API Gateway in a Nutshell

In this article, we will explore what are API gateways, the use-cases that you wanna solve with it and the benefits that you rip out of using them. This will be an introductory post to a series of articles that will showcase API gateway development using ASP.net Core, NodeJS and Docker.

Articles in the Series

This article belongs to a series of articles that explains the importance of API gateways and how to build them using ASP.net Core. If you're interested to learn more about API gateways, it might be a good idea to spend some time reading the articles listed below.

Pre-requisites

In order to survive the article, you would need to have a basic grasp of the concepts listed below to fully appreciate the value of API Gateways.

  • Microservices - Architectural pattern used in designing highly resilient and cost efficient large scale software platforms. The architectural pattern encourages splitting of large applications into smaller pieces (Services) grouped into smaller groups (Bounded Contexts) that enables fine-grain targeted scaling of individual pieces.
  • Bounded Contexts - A subset of a business domain. In the realm of microservices, a bounded context would be represented by a set of tiny little services (API, Background Jobs, Serverless Functions, etc) that work together to handle all requirements related to a bounded context.
  • Web APIs - A bunch of web-based application programming interfaces that could be invoked by client-side components to store or retrieve transactional data from the persistence layer of an application.

Abstract

Microservices encourages the implementation division of large software platforms into fine grain pieces (Services) that focuses on a single thing. This division had brought a bunch of advantages like loose coupling, development independence, fine-grain scaling, tech-stack independence and etc.

However, the architecture had introduced its own set of problems, one of them is the Death Star Pitfall. Death star pitfall is an architectural anti-pattern that occurs if services are highly coupled with each other. Therefore, increasing the complexity involved in maintaining software systems.

In order to solve the problem, smart architects had introduced the concept of bounded context. A bounded context is a set of tiny services (API, Background Jobs, Serverless Functions, etc) that work together to deliver requirements related to a sub-domain of a large software. Bounded contexts ensure that there would be minimal coupling across independent sub-domains of a business (eg. Deliveries, Accounting, Authentication, Promos).

To achieve low coupling between bounded contexts, everything that external parties would want to perform on data governed by a bounded context would be exposed through main Web APIs. However, having too much bounded contexts offloaded the burden to front-end applications by introducing the issues listed below:

  • Front-end applications need to communicate with several endpoints (Bad due to latency and TLS factors).
  • If a single transaction involves several sub-domains, client-side applications need to communicate with all of them.
  • Cross cutting concerns (Authentication, Logging, Security, Monitoring) needs to be implemented across all web APIs.
  • Each web API needs to have its own SSL and Domain name(Added Cost).
  • Cross-Origin Resource Sharing (CORS) gets more complex.

API Gateways to the Rescue

API gateways were introduced to solve the problems faced by client-side applications that needs to work with back-end systems built on top of microservices. API gateways are mainly useful in encapsulating the existence of the bounded context APIs from clients. This is achieved by building a single API that serves as an aggregator and router for all the bounded contexts.

API Gateways gives the illusion of a single endpoint to clients by handling HTTP requests and performing necessary splitting and propagation of HTTP requests to concerned bounded contexts. To add a cherry on top of the cake, API gateways proved to be extremely useful by introducing the following benefits:

  • Faster Communication Between Client and Server Side

    Front-end applications can now communicate with a single point of contact (API gateway). This improves the speed of communication between the client and server machines. This speed gain proves to more valuable for cross-continental communications (eg. EU-based servers and asia-based clients) as they reduce the latency required for performing communication as compared to having several point of contacts.
  • Sub-domain Abstraction from Client-Side Components

    Client-side developers can develop against a single point of contact which abstracts knowledge about your sub-domains on the back-end. This enables you to make changes in your back-end systems without breaking consumers contracts.
  • Centralized Cross-Cutting Concerns

    Cross-cutting concerns don't need to be implemented across several sub domain APIs (Bounded contexts) which results to cheaper and more reliable solutions. Cross-cutting concerns can be centralized on a single point (API Gateway) and eases the development and maintenance effort to cover your whole microservice ecosystem.
  • Centralized Authentication + Authorization

    Client-side components don't need to maintain and manage several JWT tokens since athentication and authorization is centralized.
  • Single Domain Name and SSL Certificate

    The need to maintain several SSLs and domain names for each bounded context is eliminated by an API gateway since it encapsulates the existence of bounded contexts from client side components.
  • Added Layer of Security

    Since API gateways encapsulate your context-APIs, they hide the physical servers that contains your context APIs and data from public clients, this results to higher levels of security as attackers have to undergo another layer of defense in the form of gateways.
  • More Reliable Fault Tolerance Strategies

    Downtimes will always occur especially in distributed systems, since your application's back-end system is broken into smaller pieces, circuit breakers deployed on API gateways help you deal with a dead context to prevent it from taking down your application. This enables your front-end applications to continuously function and handle back-end related troubles gracefully.

Things to consider

We all know that nothing is perfect and there will always be a room for improvement and problems. API gateways do present the following cons:

  • It introduces additional development costs.
  • It adds some communication latency because of the routing logic.
  • It scares developers that haven't heard of the pattern before.
  • You need a highly matured development team to execute such strategy.

Conclusion

API gateways offers tremendous amount of advantages and helps in solving issues between client-side and back-end components of large scale applications. Like other architectures, it also presents its own set of constraints and disadvantages. I will be writing several tutorials on how to build API gateways with the all new shiny containerized APIs using ASP.net Core and Node JS so please stay tuned.

Related Articles


Get Some Cool Stuff From Amazon!


Comments

Popular posts from this blog

HTTP 2 Server Push

10 Steps to Setup and Containerize an Express Server

Containerizing API Gateways using Alpine Base Image