When working with microservices there are different patterns to handling communication between external clients. You need to make sure it happens efficiently and in a scalable way, especially when talking to a fine-grained authorization service that decides access control for your whole system and can change very rapidly in time. In this blog post, you’ll learn about three different API Gateways, Zuplo, Kong, and Apache APISIX, and how each one of them could work best for a service that uses Fine-Grained Authorization (FGA).
What is FGA?
Fine-grained authorization is an authorization system that allows you to grant specific user permission to perform certain actions in specific resources at a very granular level. FGA relies on Relationship-Based Access Control (ReBAC) and it’s inspired by Google’s internal authorization system: Zanzibar.
With FGA you can answer authorization checks such as “is user:carla related to document:planning via the viewer relation?” in a very performant and scalable way.
To learn more about Auth0 FGA, read the Auth0 FGA documentation
OpenFGA is one implementation of FGA, it is an open-source project owned by the Cloud Native Computing Foundation (CNCF). The OpenFGA project serves as the foundation for Auth0 FGA, which is a hosted, highly available and scalable authorization service.
What is an API Gateway
In a microservice architecture, you need to have a way for your client to communicate with your backend services. Instead of talking to multiple different backend services, your client can communicate only with one centralized service that can figure out to which service to talk to and give a response, this is called an API Gateway.
The API Gateway serves as a single point of entry between your client applications and your backend services. It can centralize authentication, authorization, routing, rate limiting, etc.
Let’s say you have a client application for your e-commerce business that needs to request information about the user’s cart but also needs to check if the user is authenticated and authorized to see that particular cart. Instead of making at least three different requests, it will only make one single request to the API Gateway which will then route to the appropriate services, collect the data, and send back a single response, simplifying the whole process.

Building Your Own vs Using an API Gateway
Depending on your company size, business needs, and project complexity, you could consider building your own API Gateway instead of using an existing option. Over time, new requirements arrive like role-based permissions, tenant-level rate limiting, retries, scaling canary deployments, detailed logging, or even an authorization service that needs to call out to an external service like OpenFGA. This approach gives you more control. You can create something that is tailored to your environment, keep the code as simple as possible, and avoid depending on external projects. This approach can work well if your requirements are limited, your traffic patterns are unique, or you want to minimize external complexity
On the other hand, using an existing solution brings maturity and multiple built-in features. They are designed to handle high performance routing, secure communication, and integrations for advanced use cases such as FGA. They also come with strong community and vendor support, which can reduce the burden on your own engineering team. The trade-off is that you need to learn the gateway’s way of doing things and adapt your architecture to fit their constraints.
Either way, it’s up to you and your team to decide what works best. Teams that want full control and only need a narrow set of features may lean toward building. Teams that want proven reliability, faster setup, and ongoing support often choose an existing gateway. It all depends on your technical needs, business goals, and the resources you are willing to invest.
Evaluating API Gateways for FGA
When choosing an API gateway to handle FGA, there are many factors to consider. Let’s focus on four main points: performance and scalability, extensibility, ecosystem maturity, and business trade-offs.
1. Performance and scalability
A gateway sits in the middle of every request, so its performance directly affects the user experience. The ideal gateway should add minimal latency, handle high volumes of traffic, and scale up or down with demand. Features such as caching, efficient request handling, and robust load balancing are especially important when authorization checks need to happen quickly.
2. Extensibility
FGA often requires more than simple token validation. A strong gateway should allow you to extend its behavior with plugins, custom logic, or policy integrations. This flexibility makes it possible to connect with external policy engines, enrich requests with user context, and enforce authorization rules that match your business needs.
3. Ecosystem maturity
A healthy ecosystem provides confidence that the gateway will continue to evolve and stay secure. This includes active contributors, frequent releases, good documentation, monitoring tools, policy engines, and integrations with identity providers. Community maturity also means more shared knowledge and best practices you can draw from when implementing FGA.
4. Business trade-offs
Finally, every technical choice comes with business implications. Running an open source gateway yourself may reduce licensing costs but requires more operational effort. A managed or commercial gateway can lower the maintenance burden, but it comes with subscription fees and sometimes less flexibility. The right balance depends on your team’s size, skills, and budget.
Now let’s look at three API Gateways options and see how they correlate with the criteria above.
Option 1: Zuplo
Zuplo is a fully managed, cloud-native API gateway built with a strong focus on developer experience. Unlike traditional gateways that you install and operate, Zuplo is offered as a SaaS platform, removing much of the operational complexity. Configuration is code-driven, and the gateway emphasizes fast onboarding, developer-friendly workflows, and integrations with modern identity and observability tools.
FGA support
Zuplo enables FGA through JavaScript-based policies and middleware that run directly at the gateway. Developers can customize authorization logic using familiar code, or integrate with external policy engines and services through simple API calls, for example the OpenFGA Authorization Policy. Because it is managed, Zuplo also handles scaling and deployment of these policies automatically, making it easier to enforce access control without maintaining infrastructure.
Strengths
- Performance and scalability: Being a SaaS product, Zuplo abstracts away scaling and performance tuning, offering global infrastructure without the need for in-house operations.
- Extensibility: Supports code-driven customization in JavaScript, allowing developers to write flexible policies quickly.
- Developer experience: Designed to be approachable, with strong tooling, clear docs, and modern workflows.
- Operational simplicity: No need to run or maintain gateway infrastructure yourself.
Weaknesses
- Limited ecosystem maturity: As a newer entrant, Zuplo has a smaller community and ecosystem compared to long-standing open source projects.
- Less control: Being SaaS-only, teams have less flexibility to customize infrastructure-level details.
- Business trade-off: Comes with subscription costs, which may be a challenge for cost-sensitive teams.
Best use cases
- Teams that want a fully managed solution with minimal operational overhead.
- Developers who value fast iteration and code-driven policies using familiar JavaScript.
- Organizations looking for a lightweight, modern gateway without investing heavily in platform engineering.
Option 2: Kong Gateway
Kong is one of the most widely adopted open source API gateways. It is built on top of Nginx and optimized for performance. It is used in production by startups and large enterprises. Kong comes in two flavors: the open source gateway and Kong Konnect, a commercial offering that provides additional management and security features. Its focus has always been on speed, extensibility, and enterprise readiness.
FGA support
Kong supports FGA through a rich plugin system. Developers can use built-in authentication and authorization plugins or extend functionality by writing custom ones in Lua, Go, or other supported languages. Kong integrates well with policy engines like Open Policy Agent (OPA), and OpenFGA, either via custom plugins or community projects such as the OpenFGA authorization plugin. This makes it possible to enforce complex access rules at the gateway layer while delegating policy logic to a dedicated service.
Strengths
- Performance and scalability: Kong has been tested at very large scales and has strong performance under heavy traffic.
Extensibility: A mature plugin ecosystem and support for custom logic make it highly adaptable.
Ecosystem maturity: One of the most established open source gateways with strong community support and commercial backing.
Enterprise features: Kong Konnect adds centralized management, analytics, and enterprise-grade support.
Weaknesses
- Operational complexity: Running Kong at scale may require additional components such as a database (Postgres or Cassandra) for storing configuration, unless using the DB-less mode.
- Learning curve: The plugin system and configuration options are powerful but can feel complex to new users.
- Commercial trade-off: Advanced features (like Konnect’s management plane) require a commercial license.
Best use cases
- Teams that need a proven, high-performance gateway in production environments.
- Organizations that want strong plugin flexibility for integrating FGA engines.
- Enterprises that require commercial support and advanced management features.
Option 3: Apache APISIX
Apache APISIX is a dynamic, cloud-native API gateway under the Apache Software Foundation. It has gained traction for its performance, plugin-driven architecture, and strong focus on modern deployment models like Kubernetes and service mesh. It’s written in Lua, built on top of Nginx and etcd, and designed to be highly configurable and adaptable to different environments, from edge gateways to internal service routing.
FGA support
APISIX provides FGA through a wide range of plugins and integrations. It supports external policy engines such as OpenFGA via community plugins like the APISIX plugin for integration with OpenFGA, and it can call out to external services to enforce access control decisions
Strengths
- Performance and scalability: Built on Nginx with etcd, APISIX delivers very high throughput and low latency.
- Extensibility: Rich plugin ecosystem, with the ability to write custom plugins in Lua, Python, Go, or Java.
- Cloud-native design: First-class support for Kubernetes, declarative configuration via Custom Resource Definition (CRD), and seamless integration with service meshes.
- Open governance: Backed by the Apache Foundation, ensuring open source neutrality and active community development.
Weaknesses
- Ecosystem familiarity: While growing quickly, APISIX has a smaller ecosystem and fewer enterprise deployments compared to older gateways.
- Operational expertise: Running and tuning APISIX effectively requires familiarity with Nginx, etcd, and Lua.
Best use cases
- Teams that want a high-performance, cloud-native gateway with strong Kubernetes integration.
- Organizations looking for flexible plugin development in multiple languages.
- Developers who prefer an open source project with Apache governance and strong community momentum.
Find a Gateway That Grows With Your Business
FGA is becoming an important part of modern APIs as microservice systems grow larger and more complex. API gateways have a central role in this, since they handle requests, apply authentication, add context, and check authorization policies.
In this post, we looked at the main things to consider when choosing a gateway:
- Performance
- Extensibility
- Community maturity
- Business trade-offs.
We also explored how Kong, Apache APISIX, and Zuplo approach these areas. Each tool makes different choices, from the flexibility of open source projects to the simplicity of managed platforms.
With this overview, you can investigate further and choose the gateway that fits your needs as your system grows. To learn more about Auth0 FGA, take a look at the documentation.
About the author

Carla Urrea Stabile
Staff Developer Advocate
I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby and Python.
After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies.
When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha.
