Rethinking SaaS Architecture: Moving API Routes to the Edge

When I first started building SaaS products, I fell into the classic trap. I’d spin up a standard serverless function for my API routes, hook it up to a database, and call it a day. It worked fine for my local tests. But when I launched and got users from Europe and Asia, the complaints started rolling in. The dashboard was snappy for me in the US, but felt like molasses for everyone else. I was struggling with cold starts and regional latency. I realized that treating all my backend logic the same way was a mistake. So I decided to build something different.

The problem with traditional serverless setups for global SaaS is that every request has to travel to a single origin region. If your API is hosted in us-east-1, a user in Tokyo is adding 150-200ms of pure network latency to every single interaction. For a simple dashboard, it's annoying. For an interactive SEO analyzer or a checkout flow, it's conversion-killing.

Many developers ignore this until launch day. But retrofitting an app to use edge computing later is painful. You end up untangling tightly coupled backend logic from your frontend, dealing with edge-compatible runtimes, and rewriting database calls because traditional ORMs don't always play nicely at the edge. The cost of ignoring architecture early is a massive rewrite later.

When architecting SaaSLaunch, I wanted a stack that was edge-first from day one. I chose Next.js 14 with the App Router for the frontend and React Server Components. For authentication, I used NextAuth.js with OAuth providers, keeping session logic cleanly separated. But for the heavy lifting and API routes, I turned to Cloudflare Workers.

Why Cloudflare Workers instead of just sticking to standard serverless functions? It comes down to execution environment and cost at scale. Workers run on the V8 isolate model, which means virtually zero cold starts. They spin up in microseconds.

Let’s look at how I structured the SEO analysis tool. Instead of routing the request back to a central server, fetching the target HTML, parsing it, and returning it, I push this logic to the edge.

// Cloudflare Worker for edge SEO analysis
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname !== '/api/analyze') {
      return new Response('Not found', { status: 404 });
    }

    const targetUrl = url.searchParams.get('url');
    if (!targetUrl) {
      return new Response(JSON.stringify({ error: 'Missing url' }), {
        status: 400,
        headers: { 'Content-Type': 'application/json' },
      });
    }

    // Fetch target page at the edge (low latency worldwide)
    const response = await fetch(targetUrl, {
      cf: { cacheTtl: 300, cacheEverything: true },
    });
    const html = await response.text();

    // Run SEO checks (regex-based, no DOM needed)
    const title = html.match(/<title[^>]*>([^<]*)<\/title>/i)?.[1] || '';
    const desc = html.match(/<meta[^>]*name=[\"']description[\"'][^>]*content=[\"']([^\"']*)[\"']/i)?.[1] || '';
    const h1Count = (html.match(/<h1[ >]/gi) || []).length;

    return new Response(JSON.stringify({ title, desc, h1Count }), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

Notice the cf object in the fetch call. That’s Cloudflare-specific caching. By doing the HTML parsing with simple regex at the edge, we avoid the overhead of a full DOM parser, which can be heavy for isolate environments.

When designing the data flow, I had to make a conscious trade-off. Edge environments like Cloudflare Workers don't support long-running background tasks or heavy native Node.js modules. This meant I had to rethink how I handled external API calls. Instead of relying on heavy SDKs, I stripped the integrations down to raw fetch calls and handled the JSON parsing manually. It was more verbose to write initially, but it kept the bundle size tiny and the execution lightning fast.

For the core SaaS billing, I integrated Stripe subscription billing with checkout and webhook handling. I kept the Stripe logic in standard Next.js API routes because it requires secure, stateful server-side environments. It’s a hybrid approach: edge for read-heavy public tools, standard serverless for stateful billing.

To make this accessible, I set up one-click deployment to both Vercel and Cloudflare Pages, so you don't have to wrestle with CI/CD pipelines just to get a TypeScript-first boilerplate running.

The results of this hybrid architecture have been eye-opening. What surprised me was how little code I actually had to rewrite. Because Next.js and Cloudflare Workers both embrace standard Web APIs, the mental context switch was minimal. Another unexpected benefit was the developer experience. Writing TypeScript-first code across both the Next.js frontend and the Cloudflare Workers meant I had full type safety from the database schema all the way to the edge response. Sharing types between the client and the edge worker eliminated an entire class of runtime bugs.

For example, an SEO analysis request that typically took 400ms from a distant region might now resolve in under 50ms.

If I could change one thing, I’d spend more time on the database edge-caching strategy earlier. While the API routes are fast at the edge, fetching relational data from a central database still introduces some latency. I’d implement a dedicated edge-caching layer from the very first commit next time.

If you want to see how this edge architecture performs in the wild, I built a free SEO checker using these exact Cloudflare Worker patterns. You can run it against your own landing pages to see how fast edge-based analysis can be. Check it out at the SaaSLaunch free tools page: https://saaslaunch.dev/free-tools/seo-checker

---

Full disclosure: I'm the developer of SaaSLaunch. I built this because I needed it myself.