Edge redirects and functions

Edge platforms run lightweight logic close to users: 301/302 redirects, URL rewrites, A/B assignment, geolocation routing, header normalization, and auth hints before origin round-trips.

Use cases: apex-to-www redirects, legacy path migrations, canonical host enforcement, bot challenge injection, and serving static responses without hitting Node.

					// Conceptual edge function (Workers-style)
export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname.startsWith('/old-blog/')) {
      return Response.redirect(
        'https://example.com/blog' + url.pathname.slice(9),
        301,
      );
    }
    return fetch(request);
  },
};
				

Keep edge functions deterministic and fast — no heavy DB calls. Complex authorization still belongs at origin.

On interviews: when edge logic reduces latency versus when it fragments business rules; cache interaction with redirects; testing edge config across PoPs.

Common pitfalls: redirect loops; inconsistent rules between edge and origin; running secrets-heavy logic at edge replicas.

The trade-off is balancing simplicity, performance, safety, and operability — name which axis you optimized and what cost you accepted.

Checklist:

• Use edge for cheap, global request shaping.
• Version redirect maps and test with curl -I.
• Avoid stateful domain logic at edge.
• Document ownership between edge and origin teams.