What is an API Gateway?

An API gateway is a managed front door for your APIs — one entry point that routes, authenticates, and rate-limits every request. The idea is centralization: the cross-cutting work every endpoint needs (who are you, how fast may you call, where does this go, what happened) moves out of N services and into one policy layer that clients can’t walk around.

Key takeaways

What the front door does

A gateway’s job list, as configuration rather than N copies of middleware — a typical declarative route:

# gateway route: one entry, policy attached
route: /orders/**
  service: orders-api:8080          # routing — topology stays private
  auth: bearer-jwt                  # authentication at the door
  rate_limit: 100/min per key       # budgets before backends
  transform:
    strip_headers: [X-Internal-*]   # translate between edge and inside
  timeout: 5s
  observe: log + trace + metrics    # one place to watch everything

From the client’s side, a managed gateway disappears into the SDK — one call, with the door’s checks applied before any code of yours runs:

// JavaScript / Node.js — Back4app JS SDK
// One managed entry point: auth, rate limits, and routing applied per call
const receipt = await Parse.Cloud.run('placeOrder', { cartId: 'crt_812' });
// The platform's gateway verified the session, applied limits,
// and routed to the function — none of it in your code.
console.log(`Order ${receipt.orderId} confirmed`);

// Flutter / Dart — Back4app Flutter SDK
// One managed entry point: auth, rate limits, and routing applied per call
final function = ParseCloudFunction('placeOrder');
final response = await function.execute(parameters: {'cartId': 'crt_812'});
if (response.success) {
  print('Order ${response.result['orderId']} confirmed');
}

// iOS / Swift — Back4app Swift SDK
// One managed entry point: auth, rate limits, and routing applied per call
ParseCloud.callFunction("placeOrder",
                        parameters: ["cartId": "crt_812"]) { result in
  if case .success(let receipt) = result {
    print("Order confirmed: \(receipt)")
  }
}

// Android / Kotlin — Back4app Android SDK
// One managed entry point: auth, rate limits, and routing applied per call
val params = hashMapOf("cartId" to "crt_812")
ParseCloud.callFunctionInBackground<Map<String, Any>>("placeOrder", params) { receipt, e ->
  if (e == null) Log.d("Orders", "Order ${receipt["orderId"]} confirmed")
}

The four look-alikes, separated

The canonical pattern description adds the variation worth knowing: the Backend-for-Frontend — one thin gateway per client type, each shaping responses for its client — which trades deployables for the end of one-size-fits-none APIs.

The drawbacks, stated plainly

The gateway centralizes power, and centralization bills you four ways. Single point of failure: everything flows through it — run it clustered behind a load balancer or accept that its outage is the outage. The new bottleneck: every feature team now files config changes against one shared component; governance and self-service tooling are part of adoption, not extras. The monolith reborn: aggregation logic accumulating in the gateway quietly rebuilds the centralized app you decomposed — keep it policy-thick and logic-thin. Config sprawl: hundreds of routes with per-route policies is a codebase; review it like one. None of these argue against gateways; all of them argue against casual ones.

Common use cases

• Microservices front doors — the origin story: many services, one coherent API, topology free to evolve behind it.
• Multi-client products — web, mobile, and partners with different auth, shapes, and limits — the BFF’s home turf.
• API monetization — keys, plans, quotas, and usage metering enforced at one point.
• Migrations — the strangler pattern: the gateway routes old paths to the legacy system and new paths to its replacement, invisibly.
• Edge policy — CORS, TLS, header hygiene, and rate limiting applied once instead of N times.

Do you need one? A decision matrix

The unowned answer on most comparison pages: not yet is a legitimate architecture. Add the door when there’s a building behind it.

Limitations and trade-offs

• Availability is now the gateway’s availability. Cluster it, health-check it, and rehearse its failure — the mitigation is standard and non-optional.
• One hop of latency, honestly netted against the round trips and duplicated middleware it removes; measure, don’t assume either way.
• Aggregation is a slope. Composing responses is legitimate; business logic in the gateway is the ESB pattern wearing a new badge.
• Open-source options carry ops. Excellent gateways exist as open source (Envoy-based stacks and peers) — each a distributed system you now run, upgrade, and secure.
• Managed gateways trade control for silence. The platform-operated door is the right answer exactly when gateway ops would be undifferentiated toil.

The gateway on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The gateway layer comes with the platform: every request — REST, GraphQL, SDK, or Cloud Code call, as in the code tabs above — enters through a managed edge that authenticates sessions and keys, applies per-app rate limits, and routes to the generated APIs or your functions, with the platform operating the clustering and scaling that make a front door safe. The decision matrix collapses: you get the gateway’s guarantees on day one, and skip owning the door entirely.