Developer Spotlight: Compare Amazon API Gateway vs Express Gateway
Express Gateway and Amazon API Gateway are two different products for configuring middleware servers that provide services like rate limiting, authentication, and proxying. As a developer, I want to share the major trade-offs between using Amazon API Gateway and Express Gateway across several important dimensions.
Express Gateway is an open source software project, so the software is free, but you are responsible for hosting and running your Express Gateway server. The cost of hosting an Express Gateway server may vary depending on your use case, but you can run an Express Gateway server on Amazon EC2’s free tier.
Amazon API Gateway is a closed-source software-as-a-service (SaaS) product, so there is no way to separate out hosting costs from the cost of the software. Amazon charges you per million API calls, per GB of data transfer, and optionally for caching.
What you pay:
- $3.50 per million API calls
- $0.09 / GB for your first 10 TB of data transfer, $0.085 / GB for the next 40 TB, $0.07 / GB for the next 100 TB, and $0.05 for the next 350 TB
- Optionally per hour for caching results. You pay a different per-hour fee depending on the size of your cache, ranging from $0.02 / hour for a 0.5 GB cache to $3.80 / hour for a 237 GB cache.
Amazon API Gateway has a free tier, so you will pay nothing for your first 12 months as long as you are under 1 million API calls per month.
One of the primary areas I would like to address is built-in functionality. So, below is a quick comparison for Express Gateway and Amazon API Gateway. One of the key differences is that Amazon API Gateway requires you to build your own OAuth 2 support via custom authorizers and general request transformation via AWS Lambda. In order to use OAuth 2 with Amazon API Gateway, you need to use Lambda or another API provider to host your OAuth 2 logic.
|Express Gateway||Amazon API Gateway|
|OAuth 2||x||No Built in Solution. Need AWS Lambda|
|Request Transformation||x||No Built in Solution. Need AWS Lambda|
Building Custom Plugins
When built-in plugins are not enough, both Amazon API Gateway and Express Gateway have a mechanism for extending your gateway with custom functionality. Amazon API Gateway’s mechanism relies primarily on AWS Lambda. In addition to being able to use API Gateway to proxy requests to AWS Lambda, you can also use custom authorizers to call AWS Lambda functions.
Deployment and Database Support
Deploying Amazon API Gateway is done via GUI or AWS’ CLI. You need to create a new deployment and a new stage. You can think of a stage as a snapshot of the API configuration, analagous to a tag in git.
Amazon API Gateway doesn’t integrate with a database directly. In order to store data like users and API keys, you need to either use AWS’ IAM users and permissions, or use custom authorizers and AWS Lambda. If you choose to use custom authorizers, you will need to set up your own database independent of Amazon API Gateway.
Deploying Express Gateway is very different, because Express Gateway is not a hosted solution. You have numerous options for hosting Express Gateway, including running Node.js on Amazon EC2 or using Docker with Amazon ECS.
Unlike Amazon API Gateway, Express Gateway can store users in Redis independent of any centralized auth setup like AWS IAM. Express Gateway can run without a backend data store like Redis, but without a backend data store your users will be lost if your Express Gateway server restarts.
Development and Maintenance
Amazon API Gateway and Express Gateway have very different models for managing your gateway configuration. Amazon API Gateway is configured and managed through either a CLI or the AWS console GUI. Stages serve a similar purpose to releases and allow you to have a separate development API to test against.
You can also manage Amazon API Gateway separately by maintaining a Swagger configuration in JSON and importing the configuration into Amazon API Gateway every time you make a change. This would enable you to track your API gateway configuration in a version control system like git.
Express Gateway’s high-level configuration is defined in a YAML file that you can track in GitHub. There is also a CLI and admin API for managing users and credentials, but unfortunately there is no officially supported GUI for the admin API. However, unless you need to create users and credentials, you can configure Express Gateway entirely using a YAML file. This means tracking your API gateway configuration in a version control system like git is trivial.
Another limitation of Amazon API Gateway is that your gateway has a separate configuration for each resource. There is no way to configure your gateway to handle requests differently based on the request hostname or the IP address of the incoming request and there’s no way to share logic between resources, unless you write your own code in AWS Lambda. With Express Gateway, you can turn on features like rate-limiting by hostname or by IP address with a single line in your config file, and policies enable you to reuse logic in different pipelines.
Amazon API Gateway and Express Gateway both have their strengths and weaknesses. Amazon API Gateway has a compelling case for massively scalable API gateways. Based on the current pricing model, your API gateway can service 1 million requests per day with an average of 10 KB data transfer per request for approximately $125 per month, with no extra operational overhead. With Express Gateway, you are responsible for hosting and running your own API Gateway, which may be more or less expensive depending on your experience and the load on your API Gateway.
In particular, you may need to manage the number of Express Gateway servers you’re running and configure a load balancer in front of your gateway servers if your API has sufficient load, which may be cumbersome and expensive.
On the other hand, Amazon API Gateway’s documentation is quite cumbersome. A great deal of their documentation goes into excruciating detail on tangential topics without actually telling you how to use the functionality, like their guide to rate limiting. Setting up rudimentary API gateway tasks, like OAuth2 or key authorization, require plugging in additional AWS services, like Lambda and IAM users, so it is unlikely you’ll be able to use Amazon API Gateway independent of the rest of AWS. Express Gateway has more concise documentation and an active blog with detailed overviews of use cases. And, if all else fails, you can just read the code because Express Gateway’s source code is available on GitHub.
Like more of this content?