The Shift to Edge Computing: How It Changed My SaaS Architecture

#nextjs #cloudflare #webdev #typescript

When I first started building my indie SaaS projects, I spent more time wiring up the boilerplate than actually building the core product. I’d spin up a new Next.js app, spend three days configuring Stripe webhooks, another day wrestling with NextAuth, and then realize my API routes were too slow for global users. I was struggling with the same architectural setup every single time. I kept asking myself: why am I rebuilding the foundation instead of shipping features? So I decided to build something.

The Latency and Boilerplate Problem

The traditional SaaS stack often forces a compromise. You can have a great frontend framework like Next.js, but when it comes to backend processing, you're usually hitting a single central server. For things like SEO analysis, web scraping, or heavy API requests, this introduces noticeable latency. If your users are global, a server in us-east-1 isn't going to cut it for a developer in Tokyo or London.

Furthermore, setting up Stripe subscriptions and handling edge-side logic usually requires stitching together three different tutorials. The cost of ignoring this architectural shift? Your app feels sluggish, your SEO tools crawl slowly, and you burn out before you even launch. The industry is moving towards edge computing, but adopting it for a full SaaS stack still feels fragmented for many developers.

A Technical Approach: Pushing Logic to the Edge

To solve this, I started designing an architecture that pushes logic to the edge. The core insight was separating the heavy frontend rendering from the lightweight, globally distributed API routes. I chose Next.js 14 with the App Router for the frontend and UI, but I offloaded specific API tasks—like web scraping and SEO analysis—to Cloudflare Workers.

For the billing side, I kept the Stripe checkout logic in the Next.js API routes since it requires secure server-side environment variables and direct database interactions. But for the SEO checker, I moved the heavy lifting to the edge.

Here is what the Cloudflare Worker for edge SEO analysis looks like:

// 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' },
    });
  },
};

Why This Architecture Works

There are a few key decisions here. First, by running this Worker at the edge, the fetch request to the target URL originates from a server geographically close to the target, drastically reducing network latency.

Second, notice the SEO checks are regex-based. At the edge, CPU time is a premium. Parsing the entire HTML into a DOM tree using a library like cheerio or jsdom would consume too many CPU cycles and slow down the worker. Using simple regex to extract the <title>, meta description, and <h1> counts keeps the execution time in the single-digit milliseconds.

The trade-off, of course, is that regex isn't perfect for parsing complex or malformed HTML. But for quick, high-level SEO checks on standard web pages, it's a highly effective compromise that keeps the edge function lightweight and fast.

Practical Results and Takeaways

Moving the SEO analysis and API routing to Cloudflare Workers drastically reduced latency for global users. What surprised me was how much simpler the deployment became. By keeping the Workers lightweight and using TypeScript-first across both the Next.js app and the Workers, type safety caught bugs before they hit production.

One-click deployments to Vercel for the frontend and Cloudflare Pages for the edge tools made the CI/CD pipeline almost non-existent. I could push a change to the SEO logic and have it live globally in seconds.

If I were to change one thing, I’d probably integrate more edge caching directly into the Worker responses. I initially relied too much on the client-side caching, but passing Cache-Control headers directly from the Worker would save even more compute time on repeated checks.

Testing the Edge Yourself

This edge-based approach works so well that I packaged it into a complete starter kit. But you don't need to buy a boilerplate to test out edge SEO analysis. I built a free SEO checker that runs on this exact Cloudflare Worker architecture, so you can see the low-latency analysis in action for your own site.

You can try it out and analyze your landing pages at https://saaslaunch.dev/free-tools/seo-checker.

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

DEV Community