How to Structure Your Serverless Apps Using a Shared API Gateway

The case for separate stacks

Photo by Victor Lu on Unsplash

1. What is a Shared API Gateway?
2. Why use a Shared API Gateway?
3. Implementing a Shared API Gateway
4. Deploying the Shared API Gateway
5. Conclusion

What Is a Shared API Gateway?

A shared API gateway is when multiple services use a single API gateway. These services could be fully separate APIs or, more commonly, smaller components of a larger API.

Why Use a Shared API Gateway?

There are a few benefits of shared API gateways. The primary is breaking large APIs into smaller, more manageable components. By breaking up larger APIs into smaller components, there is much less overhead when updating these components.

With large monolithic code bases, to update a single lambda function, for example, the entire API would need to be redeployed. This creates unnecessary overhead by increasing deployment times and complexity.

Utilizing shared API gateways, a single component may be updated and redeployed without redeploying the entire API.

Another benefit of breaking an API into smaller components is the flexibility of endpoint security. By utilizing separate APIs, security may be implemented differently per API. For example, an Auth API that handles sign-up, email confirmation, and sign-out, would not necessarily need secured endpoints. Whereas a user API that returned user data would need secure endpoints.

By having separate components for auth and user APIs, security could be implemented only on the user API instead of unnecessarily being implemented on both user and auth APIs with a more traditional monolithic API.

Implementing a Shared API Gateway

This implementation will be broken down into the following three components. The code repository will be provided at the end of the article.

1. Shared API Gateway
2. Auth API
2. User API

Shared API gateway

This is the main serverless file with the API Gateway. Adding Outputs is the main way this differs from a traditional API gateway. Outputs allow variables to be passed between the shared API gateway and other API components. The primary variables needed by other components are the RestApiId and RootResourceId.

service: shared-api-gateway
frameworkVersion: '3'

provider:
  name: aws
  runtime: nodejs16.x
  region: us-east-1
resources:
  Resources:
    SharedAPIGateway:
      Type: AWS::ApiGateway::RestApi
      Properties:
        Name: SharedAPIGateway
  Outputs:
    apiGatewayRestApiId:
      Value:
        Ref: SharedAPIGateway
      Export:
        Name: SharedAPIGateway-restApiId
    apiGatewayRestApiRootResourceId:
      Value:
        Fn::GetAtt:
          - SharedAPIGateway
          - RootResourceId
      Export:
        Name: SharedAPIGateway-rootResourceId

Auth API

This is an example component for an auth API that could be part of a larger API. Compared to a traditional serverless lambda implementation, the primary difference is passing the RestApiId and RootResourceId within the provider. This is done using the apiGateway parameter.

service: shared-api-gateway-auth
provider:
  name: aws
  runtime: nodejs16.x
  region: us-east-1
  apiGateway:
    restApiId:
      "Fn::ImportValue": SharedAPIGateway-restApiId
    restApiRootResourceId:
      "Fn::ImportValue": SharedAPIGateway-rootResourceId
  httpApi:
    cors: true
    disableDefaultEndpoint: true
functions:
  signUp:
    handler: authHandler.signUp
    events:
      - http:
          path: auth/sign-up
          method: post
  signIn:
    handler: authHandler.signIn
    events:
      - http:
          path: auth/sign-in
          method: post
  confirmEmail:
    handler: authHandler.confirmEmail
    events:
      - http:
          path: auth/confirm-email
          method: post

User API

Similarly to the auth API, this is an example component for a user API that could be part of a larger API. This implementation is the same as the auth API regarding passing in the RestApiId and RootResourceId within the provider using the apiGateway parameter.

service: shared-api-gateway-user
provider:
  name: aws
  runtime: nodejs16.x
  region: us-east-1
  apiGateway:
    restApiId:
      "Fn::ImportValue": SharedAPIGateway-restApiId
    restApiRootResourceId:
      "Fn::ImportValue": SharedAPIGateway-rootResourceId
  httpApi:
    cors: true
    disableDefaultEndpoint: true
functions:
  getUser:
    handler: userHandler.getUser
    events:
      - http:
          path: user/get-user
          method: getDeploying the Sahred API Gateway

Deploying the Shared API Gateway

A standard serverless deployment may be used to deploy the shared API gateway and other API components. The shared API gateway must be deployed first, initially. However, only the changed component needs to be deployed for future deployments.

Deploy using the following serverless command, serverless deploy, within the respective directory of the API being deployed (shared gateway or components).

Within the repo provided, a deployment script will deploy the shared gateway along with auth and user components.

Conclusion

Shared API gateways are a great way to break up larger APIs into smaller components and streamline development and maintenance.

I hope this article was a good introduction to the benefits and possibilities provided by shared API gateways. As mentioned, the full code for this implementation may be found below.

Stay tuned for more articles regarding implementing security within shared API gateways.

GitHub - EJOzyazgan/aws-shared-api-gateway: Example for implementing a shared API gateway in AWS