It’s no secret that cloud native applications are designed to maximize resilience through predictable behaviors. Several factors, including API exposure and application design, play key roles in the successful deployment of cloud native applications. For instance, API exposure and providing internal or external access via standardized methods can fundamentally change your growth trajectory. You can create new services, integrations and expose customer insights. As an important area of growth, designing your application also plays a critical role. Are you designing with microservices in mind? Breaking down monolithic applications with containers? For example, cloud native technologies like Docker give you the ability to decompose your once monolithic applications into sustainable microservices. If you’re building the next generation of cloud native applications, where what does that roadmap look like? Let’s break it down.

“Give a man a fish, and you feed him for a day. Teach a main to fish, and you feed him for a lifetime.”

This old saying is the premise behind what we were thinking of building next based on community feedback of what we had released initially with Express Gateway.

Express Gateway comes with a lot of powerful features baked in, like OAuth2 and key auth. When built-in features aren’t enough, Express Gateway has an expression policy, which lets you execute arbitrary JavaScript to modify the request and response. In this article, I’ll show you how the expression policy works with several sample use cases.

One of the key reason why we built Express Gateway on ExpressJS is because of an existing rich ecosystem of 3,000+ middleware modules that is already being used out of the box with Express. Not all Express modules are relevant to the API gateway use case - but many are. Said a different way - almost all API gateway use cases can be covered by utilizing an existing Express module.