Why Your API Needs to Run at the Edge

Why should your API operate at the edge? In this talk, I explore the benefits, trade-offs, and real-world applications of deploying APIs at the edge. I cover latency improvements, caching, database considerations, and even demos an edge-powered ATM locator API. If you're an API engineer, developer, or tech leader looking to optimize performance, this is for you!

tl;dw: Why Your API needs to Operate at the Edge#

Here's a text summary of my talk in case it's too long for you.

1. What I Mean by “The Edge”#

Normally, you deploy an application or API in one region (for example, “us-east-1”), which forces users around the globe to contend with high network latency. Edge computing, on the other hand, distributes application logic to servers in different geographical locations—often the same Points of Presence used for CDNs. This dramatically cuts down on the distance (and time) for requests to travel, improving performance. It also takes advantage of lightweight runtimes that start up almost instantly.

2. Trade-Offs of Edge Compute#

However, running code at the edge can come with constraints:

Runtime Restrictions: Many platforms (like Cloudflare Workers) only support JavaScript (and WebAssembly). Full Node.js libraries may not be supported, and bundle sizes can be limited.
Data Location: Even though my code is near the user, my database might still be somewhere else. If I always have to reach across the globe for data, I might lose the performance benefits.
Connection Pooling & Caching: If a lot of edge functions connect to a central database, they can exhaust database connections. Tools like Prisma Accelerate or RDS Proxy can help by managing and pooling connections at scale.
Consistency vs. Speed: When data is replicated to multiple regions, writes can take longer or become inconsistent. I have to design carefully around these trade-offs.

3. Why I Believe APIs Benefit from the Edge#

Many companies offer public APIs to developers worldwide, so performance matters. By offloading tasks like authorization, request validation, rate-limiting, and caching to the edge, I can quickly filter out invalid requests before they ever reach the main application. This approach also speeds up typical API calls because less work happens in distant regions.

4. My Demo: An ATM Locator API#

To illustrate how edge compute can help:

Use Case: I built a simple “ATM locator” API that returns nearby ATMs for a given latitude, longitude, and radius.
Setup: I hosted my frontend on Vercel (Next.js) and used Zuplo as my edge-based API gateway. The ATM data lived in Cloudflare D1 (a globally distributed SQLite-like database).
Latency Challenge: The first request took 1–2 seconds because my database instance wasn’t truly nearby. D1’s query time was actually very fast, but the network round trip took most of that time.
Caching Solution: By caching query results at the edge (for example, based on truncated lat/long prefixes), subsequent calls dropped to mere tens of milliseconds—often outperforming the original Capital One API upon which the dataset was based.

The big takeaway from my demo is that a good caching strategy at the edge can significantly improve performance, even when your database isn’t perfectly colocated.

5. Final Thoughts#

In my view, running APIs at the edge can dramatically reduce latency and improve the user experience, especially when you combine it with a robust data strategy—be that proxies, replicated databases, or aggressive caching. Even if your data is in a central location, simply placing authentication and caching logic at the edge can make your API feel much faster to users around the globe.

If you have questions, I encourage you to connect with me on LinkedIn and check out the open-source example code I shared.