Coder Legion - Recent posts tagged edge-computing

Subdomain Routing with Cloudflare Pages Middleware

Fri, 02 Oct 2026 02:00:41 +0000

When you manage a static publication that includes standalone interactive tools, you eventually face a hosting dilemma. You want your users to access a focused tool on a clean, memorable address like timer.example.com, but you do not want to maintain a separate codebase, configure an independent CI pipeline, or burn extra build minutes. Pointing a subdomain to the same Cloudflare Pages project seems like an easy fix, but it introduces immediate architectural challenges. Search engines can index the exact same content under both domains, which splits your ranking authority and triggers duplicate content penalties. Naive edge redirects can also cause infinite loops or accidentally break static assets like JavaScript bundles and CSS files. For a related implementation, see Automated Content Syndication Canonical Seo Protection.

This article explains how to use Cloudflare Pages edge middleware to host branded subdomains on a unified static repository. You will learn how to intercept incoming requests by inspecting the Host header, pass through static assets, rewrite root paths for your sub-apps, and issue permanent 301 redirects for any unassociated pages back to your apex domain.

The Multi-App Monorepo Dilemma

Many engineering teams split every sub-project into its own repository or separate Pages project. While this isolates deployment concerns, it increases maintenance friction. Shared design tokens, typography styles, and utility functions must be published as internal packages or copy-pasted across repos. For smaller teams or solo developers, a monorepo built with a modern static site generator is much easier to maintain.

When you point multiple subdomains to a single Cloudflare Pages project, the platform treats all incoming requests as if they belong to the primary deployment. Without interception, visiting timer.example.com/about would serve the main site about page instead of protecting your canonical domain structure. You need a layer that runs before static file resolution to inspect the request and decide its fate.

Cloudflare Pages Edge Middleware Architecture

Cloudflare Pages supports middleware through a file named functions/_middleware.ts. This script executes at edge locations globally before the CDN attempts to match static files on disk. Because the middleware runs in the Workers runtime, execution takes only a few milliseconds and incurs negligible overhead.

The middleware intercepts the incoming Request object, reads the headers, and either passes the request through to the static assets, rewrites the URL internally, or returns an HTTP redirect response. This architecture lets you handle routing rules directly at the network edge without provisioning dedicated origin servers. For a related implementation, see Abi Filters Architecture.

Implementing the Four Routing Rules

To manage a dedicated subdomain like timer.example.com while keeping the rest of your site on example.com, your middleware must follow a strict evaluation order. The following implementation uses TypeScript to handle host header matching, asset preservation, root normalization, in-app routing, and canonical bounces.

export const onRequest: PagesFunction = async (context) => {
  const url = new URL(context.request.url);
  const host = context.request.headers.get("host") || "";

  // Fast exit for apex domain traffic
  if (!host.startsWith("timer.")) {
    return context.next();
  }

  // Rule 1: Allow static assets and workers to pass through
  if (
    url.pathname.startsWith("/assets/") ||
    url.pathname.startsWith("/timer-") ||
    url.pathname === "/robots.txt" ||
    url.pathname === "/favicon.ico"
  ) {
    return context.next();
  }

  // Rule 2: Rewrite root requests to the sub-app directory
  if (url.pathname === "/") {
    const targetUrl = new URL("/timer/", url.origin);
    return context.env.ASSETS.fetch(targetUrl);
  }

  // Rule 3: Allow internal app routes to render
  if (url.pathname.startsWith("/timer/")) {
    return context.next();
  }

  // Rule 4: Canonical 301 bounce for unrelated paths
  const canonicalUrl = new URL(`https://example.com${url.pathname}${url.search}`);
  return Response.redirect(canonicalUrl.toString(), 301);
};

Let us break down how each rule operates within this function:

Apex Fast Exit: The middleware checks the Host header immediately. If the request is not destined for a subdomain starting with timer., it calls context.next() and lets the platform handle the request normally. This ensures your primary domain traffic experiences zero performance penalty.
Asset Passthrough: Web applications rely on static assets, CSS, and worker scripts. If a browser requests /assets/main.js, the middleware matches Rule 1 and passes the request through. Without this step, your stylesheet requests might trigger redirects and fail to load.
Root Normalization: When a user visits timer.example.com/ directly, the path is /. Rule 2 intercepts this and fetches the internal static path /timer/ without changing the user's visible address bar if combined with a fetch rewrite, or it normalizes the entry point.
Canonical Bounce: If a user attempts to navigate to an unrelated section of the main site from the subdomain, such as timer.example.com/articles/foo, Rule 4 issues a permanent 301 redirect to the apex domain. Notice how it appends url.search to preserve query parameters, ensuring tracking tags and user filters are never lost.

Unit Testing Edge Logic Locally

Testing edge routing configurations traditionally required deploying code to a staging environment. You can avoid this by using Node.js built-in test runners to simulate Request objects against your middleware function locally.

import test from "node:test";
import assert from "node:assert";
import { onRequest } from "./_middleware";

test("redirects non-app paths to apex with query params", async () => {
  const request = new Request("https://timer.example.com/articles/guide?ref=twitter", {
    headers: { host: "timer.example.com" }
  });
  
  const context = {
    request,
    next: async () => new Response("ok"),
    env: { ASSETS: { fetch: async () => new Response("asset") } }
  };

  const response = await onRequest(context as any);
  assert.strictEqual(response.status, 301);
  assert.strictEqual(
    response.headers.get("location"),
    "https://example.com/articles/guide?ref=twitter"
  );
});

This test verifies that incoming requests on the subdomain targeting invalid paths receive the expected 301 status code while preserving query parameters. Running these checks in your continuous integration pipeline catches routing regressions before they reach production.

Conclusion on Subdomain Edge Routing

Hosting branded subdomains on a single static site deployment requires careful management of edge request lifecycles. By implementing targeted middleware that evaluates the Host header, bypasses static assets, and enforces canonical redirects, you can provide dedicated micro-tool experiences without sacrificing SEO equity or duplicating your codebase. Testing these rules locally gives you confidence before deploying changes to your production infrastructure.

Why Developers Are Looking Beyond the Cloud

Tue, 19 May 2026 16:37:11 +0000

For years, the default advice was simple: move everything to the cloud.

Need compute? Use the cloud.
Need storage? Use the cloud.
Need databases, queues, observability, networking, backups, and security? Use managed services.

That advice made sense for a long time. Cloud platforms changed how software was built. They made infrastructure programmable, global, fast to deploy, and accessible to small teams without large capital investment. A startup could launch worldwide without buying a single server. A developer could create a production environment in minutes.

But something interesting is happening now.

Many engineering teams are quietly becoming more selective. They are not abandoning the cloud, but they are no longer treating it as the automatic answer to every infrastructure problem. Bare metal is coming back. Private cloud is being reconsidered. Edge infrastructure is growing. Developers are paying more attention to cost, latency, data control, portability, and operational independence.

The new trend is not anti cloud. It is cloud maturity.

The cloud was never magic

The cloud solved real problems, but it also created new ones.

At first, the value was obvious. Instead of waiting weeks for hardware, teams could deploy instantly. Instead of guessing capacity, they could scale on demand. Instead of building everything from scratch, they could consume managed services.

But over time, many organizations discovered that convenience has a price.

Cloud bills can become unpredictable. Managed services can create deep vendor lock in. Data transfer fees can turn architecture decisions into financial surprises. Debugging distributed systems across many managed components can become harder than managing a smaller, simpler platform.

The cloud did not remove infrastructure complexity. It changed where that complexity lives.

For a small team, that tradeoff is often worth it. For a growing company with stable workloads, high traffic, heavy storage, or strict compliance requirements, the equation starts to change.

Predictable workloads do not always need elastic pricing

One of the strongest arguments for the cloud is elasticity. If demand changes constantly, paying for resources as you use them is powerful.

But not every workload is unpredictable.

Many applications have steady traffic. Internal platforms, analytics pipelines, databases, monitoring systems, storage clusters, CI runners, media processing jobs, and enterprise services often run 24 hours a day with fairly known capacity needs.

In these cases, renting infrastructure forever may not be the most efficient model.

A dedicated server that runs at high utilization can be dramatically more cost effective than equivalent cloud resources. A small private cluster can handle predictable workloads with lower monthly cost and more control. Even colocation, which once felt old fashioned, is becoming attractive again for teams that understand their baseline capacity.

This does not mean every company should buy racks of servers. It means engineers should ask better questions.

Is this workload variable or stable?
Does it need global elasticity or predictable capacity?
Are we paying for convenience, or are we paying because nobody reviewed the architecture?
Would a hybrid model reduce cost without increasing risk?

The future belongs to teams that can answer these questions clearly.

Latency is becoming a product feature

Infrastructure decisions are no longer only about cost. They are also about user experience.

Modern users expect applications to feel instant. A few hundred milliseconds can change how a product feels. For gaming, collaboration tools, trading platforms, video, IoT, payment systems, and real time dashboards, latency is not a technical detail. It is part of the product.

This is one reason edge infrastructure is growing.

When compute moves closer to users, applications can respond faster. When data processing happens near the source, systems can avoid unnecessary round trips. When services are deployed regionally, reliability improves because one central location is no longer the only path.

The cloud is still important here, but it is not the whole story. Edge nodes, regional data centers, CDN compute, private points of presence, and local processing are becoming part of modern architecture.

The best infrastructure is not always the biggest. Sometimes it is simply closer.

Developers want portability again

A few years ago, many teams were comfortable building deeply around one cloud provider. Managed databases, serverless functions, proprietary queues, cloud specific IAM, hosted observability, and provider specific deployment models made development faster.

But the cost of that speed often appeared later.

When everything depends on one provider’s unique services, moving becomes difficult. Even testing locally can become complicated. Engineers may understand the application code but not the platform behavior around it. A simple migration can turn into a long and expensive rewrite.

This is why portability is becoming valuable again.

Containers, Kubernetes, Terraform, OpenTofu, PostgreSQL, object storage compatible APIs, standard observability formats, and open networking tools are popular because they give teams options. They allow workloads to run in more than one environment. They also reduce the fear of being trapped.

Portability does not mean pretending every platform is identical. It means designing systems so that the business has choices.

A portable system can run in the cloud today, on bare metal tomorrow, and across multiple regions when needed. That flexibility is not just technical. It is strategic.

Compliance and data control matter more than ever

For regulated industries, infrastructure is not only about performance and cost. It is also about control.

Finance, healthcare, telecom, government, and critical infrastructure companies must think carefully about where data lives, how it moves, who can access it, how logs are stored, and how systems are audited.

Cloud providers offer strong security capabilities, but responsibility still belongs to the organization using them. Misconfigured storage, overly broad permissions, unclear network boundaries, and weak audit processes can still create serious risk.

Some workloads are easier to govern when they run in a more controlled environment. Others benefit from managed cloud security services. The point is not that one model is always better. The point is that infrastructure should match the regulatory reality of the application.

For developers, this means security and compliance can no longer be treated as something that happens after deployment. They must be part of architecture from the beginning.

Where does the data live?
Who can access it?
What happens during an incident?
Can we prove how the system behaves?
Can we rebuild it from code?
Can we audit every important change?

These questions are becoming normal engineering questions.

Simplicity is becoming a competitive advantage

One of the biggest lessons of the last decade is that complexity scales faster than teams expect.

A system can start with a simple architecture and slowly turn into dozens of services, queues, functions, databases, secrets, dashboards, policies, and deployment pipelines. Each part may make sense individually, but together they become hard to reason about.

This is why many senior engineers are rediscovering the value of boring infrastructure.

Boring does not mean outdated. It means understandable, reliable, documented, and easy to operate.

A boring PostgreSQL database is often better than five specialized data services.
A boring Linux server can be better than a fragile chain of managed components.
A boring deployment pipeline can be better than a platform nobody fully understands.
A boring network design can be better than a clever one that fails in strange ways.

The best infrastructure is not the one that looks most impressive in a diagram. It is the one that survives real production pressure.

The rise of hybrid thinking

The most practical teams are not choosing between cloud and bare metal as a matter of ideology. They are using both.

A common pattern is emerging:

Cloud for burst capacity, global reach, managed services, and fast experimentation.
Bare metal or private cloud for stable workloads, databases, storage, CI, and cost sensitive systems.
Edge infrastructure for latency sensitive workloads.
Open source tooling for portability and control.
Automation everywhere to keep operations repeatable.

This hybrid approach requires more engineering discipline, but it can produce better results. Teams get the speed of cloud where it matters and the efficiency of owned or dedicated infrastructure where it makes sense.

The key is automation. Without automation, hybrid infrastructure becomes chaos. With automation, it becomes a flexible platform.

Infrastructure as code, Git based workflows, monitoring, configuration management, immutable images, automated backups, and clear runbooks are what make this model realistic.

Infrastructure knowledge is becoming valuable again

For a while, some people believed developers would no longer need to understand infrastructure deeply. Managed platforms would hide the details.

That prediction did not fully come true.

Modern software still depends on networking, storage, Linux, DNS, TLS, routing, load balancing, databases, queues, observability, and security. When something breaks, abstraction is helpful only until it hides the root cause.

The best engineers today are not just writing application code. They understand how their code behaves in production. They know what happens when latency increases, when disk IO is saturated, when DNS fails, when a certificate expires, when a region goes down, or when a deployment creates unexpected load.

Infrastructure knowledge is no longer only for system administrators. It is becoming a core engineering skill again.

The future is not cloud first. It is architecture first

The next phase of infrastructure will not be defined by one platform.

It will be defined by better decision making.

Cloud is excellent for many things. Bare metal is excellent for many things. Edge is excellent for many things. Managed services, open source platforms, private clouds, and colocation all have a place.

The mistake is choosing any of them automatically.

The better approach is architecture first:

Understand the workload.
Understand the business constraints.
Understand the cost model.
Understand the security requirements.
Understand the operational capacity of the team.
Then choose the infrastructure that fits.

This is a more mature way to build systems. It is also more honest.

Infrastructure is not just a place where applications run. It is part of the product, part of the cost structure, part of the security model, and part of the user experience.

The cloud era taught developers to move fast. The next era will teach them to choose wisely.