{"componentChunkName":"component---src-components-blog-template-js","path":"/blog/2025-07-13-edge-computing/","result":{"data":{"markdownRemark":{"frontmatter":{"title":"Edge Computing","date":"2025-07-13"},"html":"<p>Traditionally, web applications are deployed to a centralised data centre or cloud region. When a user in Auckland makes a request to a server in Virginia, the data has to travel across the Pacific and back. That round trip adds latency. Edge computing moves computation closer to the user by running code at locations distributed around the world.</p>\n<h3>What the Edge Means</h3>\n<p>Edge servers are part of a content delivery network (CDN) that has points of presence in many geographic locations. Instead of just caching static files like images and CSS, modern edge platforms can run application code at these locations. The user's request is handled by the nearest edge server, reducing latency significantly.</p>\n<p>Platforms like Cloudflare Workers, Vercel Edge Functions, and Deno Deploy allow us to deploy serverless functions that run at the edge. The deployment is global by default. We write the code once and it runs at hundreds of locations worldwide.</p>\n<h3>Use Cases</h3>\n<p><strong>API responses that depend on location.</strong> Serving different content based on the user's country, like currency, language, or legal disclaimers, is a natural fit for edge functions because the geographic information is available at the edge.</p>\n<p><strong>Authentication and authorisation checks.</strong> Verifying a JWT or checking an API key can happen at the edge before the request even reaches the origin server. Invalid requests are rejected close to the user, saving the origin from unnecessary load.</p>\n<p><strong>A/B testing and feature flags.</strong> Routing users to different variants at the edge avoids the latency of making a round trip to the origin to determine which variant to serve.</p>\n<p><strong>Response transformation.</strong> Modifying HTML on the fly, like injecting headers, rewriting URLs, or personalising content, can be done at the edge without changing the origin application.</p>\n<h3>Constraints</h3>\n<p>Edge environments are more constrained than traditional server environments. They typically have limits on execution time, memory, and available APIs. Most edge runtimes use a subset of the Web API rather than a full Node.js environment. File system access is usually not available, and connections to traditional databases that require persistent TCP connections can be problematic.</p>\n<p>Data storage at the edge is also different. Key-value stores like Cloudflare KV or edge-compatible databases like Turso are designed for this environment. They replicate data globally so that reads are fast from any location, but writes may have eventual consistency.</p>\n<h3>When to Use Edge</h3>\n<p>Edge computing is most beneficial when latency matters and the computation is relatively lightweight. For a simple API gateway, authentication check, or content personalisation, the edge is a good fit. For heavy computation, complex database transactions, or tasks that require a full server runtime, a traditional server or serverless function in a specific region is more appropriate.</p>\n<p>The edge is not a replacement for backend servers. It is an additional layer that handles work that benefits from being close to the user. Knowing when to use each layer is key to getting the most out of the architecture.</p>"}},"pageContext":{"slug":"/2025-07-13-edge-computing/"}},"staticQueryHashes":[]}