Route and proxy APIs at the edge
Match exact, parameterized, and wildcard paths, then forward traffic to upstream services or Worker-native bindings.
Cloudflare Workers
One API entrypoint. Fewer edge decisions scattered across your stack.
Serverless API Gateway is a config-driven Cloudflare Worker for routing, CORS, JWT/Auth0/Supabase auth, service bindings, and request mapping. The docs and blog now live as first-party product content so readers get one consistent source of truth.
Reader-first fit
- Expose multiple backends behind one public API domain.
- Protect selected routes while keeping health and onboarding endpoints public.
- Run Auth0 callback/profile/refresh routes or Supabase OTP flows at the edge.
- Use service bindings and pre-process hooks for Worker-to-Worker composition.
What you get
Core gateway behavior that already exists in the repo
The content hub is grounded in the product surface that is already implemented and tested, not a speculative roadmap.
Centralize auth and CORS
Apply JWT, Auth0, or Supabase checks once and keep browser CORS behavior consistent across services.
Shape requests without custom glue code
Inject headers and query parameters from verified JWT claims, request values, and gateway variables.
Keep the contract readable
Use JSON config, tested examples, and first-party docs instead of burying gateway behavior in ad hoc Worker code.
Why this content hub exists
Docs for builders. Articles for decisions. One canonical domain.
The site now treats documentation and blog content as one learning system: docs cover implementation details, while blog posts help readers decide when and why to use the gateway. Both point back to the real product limits so the content stays trustworthy.
Current scope
- Routing: exact, parameterized, wildcard, and method-aware path matching.
- Auth: JWT, Auth0 callback/profile/refresh flows, and Supabase OTP plus JWT verification.
- Integrations: HTTP proxy, Worker services, service bindings, pre-process, and post-process hooks.
- Request shaping: config variables, env/secret replacement, header/query mapping.
Latest first-party guides
See every article »Start with quick implementation guides, then move into comparisons and migration notes once you know where the gateway fits in your stack.
From Ghost Blog to Product-Led Content Hub
Why moving the blog into the product’s own landing repo improves canonical control, internal linking, and reader trust.
What to Measure When You Migrate to Edge Routing
The metrics and operational signals that matter when you replace a more traditional API entrypoint with an edge Worker gateway.
How to Test an API Gateway Before Production
A practical testing sequence based on the repo’s existing Vitest and local Worker runtime coverage.
Config-Driven Gateways vs. Code-Driven Gateways
A guide to when a declarative gateway model helps teams move faster and when custom code is still the better choice.
How to Think About Latency at the Edge
A practical framework for deciding which latency problems the edge tier can solve and which still belong to origin systems.
Cloudflare Worker API Gateway Cost Model Explained
How to think about cost for a Worker-native gateway without pretending the current repo implements a full cost analytics layer.
FAQ
Common questions before adoption
What is the fastest way to start?
Start with a single upstream, one health route, and the docs quickstart. Add auth and mapping only after the basic proxy path is working.
What does this project not do today?
It does not currently ship rate limiting, analytics dashboards, OpenAPI generation, API key management, or an admin UI.
Why move the blog into this site?
So canonicals, redirects, navigation, RSS, and product context all live in the same repository and build pipeline.