Learn Remix - Edge & Serverless

#Introduction

Episode 20 introduced the difference between server and edge. Episode 21 dives deeper into the edge and serverless side — because this isn't a passing trend, it's the direction of modern web application deployment.

The idea is simple: instead of one server in one location, code runs across many nodes spread around the world. A user in Jakarta is served by a node in Asia, a user in Sao Paulo by a node in South America. Latency drops dramatically because data no longer has to cross continents.

Episode 21 covers edge functions and serverless, deploying on Cloudflare Workers or Deno, runtime differences, and use cases that suit an edge-first approach.

One important note before starting: the edge isn't a replacement for every architecture, but the right addition for some workloads. Knowing when to use it — and when not to — is part of this skill.

#Edge Functions and Serverless Runtimes

#What Is an Edge Function

An edge function is a piece of code that runs on an edge server, close to the user. Unlike ordinary serverless functions, which may run in a specific region, an edge function always runs at the nearest node. Both share the same concept: no permanently running process, code is executed per request.

Example of light, fast logic at the edge

export async function loader() {
  const waktu = new Date().toISOString();
  const region = "edge-node";
  return { waktu, region };
}

The code above only uses standard JavaScript APIs — a pattern that's safe for the edge. Heavy logic, large databases, and native libraries shouldn't be here.

Another consequence of the per-request model: no state persists in memory between requests. Every invocation starts from scratch. State across requests must be stored in a database, cache, or external storage — patterns you already know from episodes 10 and 14.

#Serverless Across Multiple Regions

Classic serverless runs functions in specific configured regions. With global traffic, you can choose several regions, but each invocation still runs in one region. The edge removes this decision: execution always happens at the nearest node.

Both also share the scaling advantage: the platform scales capacity up and down automatically with traffic, so you don't need to provision servers for peak load. This is the main reason small teams choose serverless and edge to start.

#Deploying Remix on Cloudflare Workers or Deno

#Cloudflare Pages and Workers

Remix supports Cloudflare through the @remix-run/cloudflare-pages adapter. Cloudflare Pages uses Workers infrastructure, so the application runs across Cloudflare's entire edge network. Choose this adapter when your main target is Cloudflare's edge network.

npm view @remix-run/cloudflare-pages version
npm view @remix-run/cloudflare-workers version

Cloudflare Pages is the most common way to run Remix in the Cloudflare ecosystem. It handles the build, serves assets, and runs edge functions with a single configuration.

The difference between Pages and Workers: Pages focuses on complete web applications with static assets and integrated functions, while Workers is more flexible for pure API logic. For a Remix application, Pages is the easiest starting point.

#Deno as a Runtime

Deno is a modern JavaScript runtime that Remix can use. Different runtimes mean different APIs: check the adapter documentation before using specific features. The same principle applies — loaders and actions still run on the server — only the execution environment changes.

#Runtime Differences and Environment Considerations

#Available APIs

Each runtime has different API support. Node.js has a complete API: filesystem, child processes, and native libraries. The edge is more limited but faster and more distributed. Get in the habit of reading the runtime documentation when choosing features, rather than assuming everything is available.

#Standard Web APIs

The good news: most Remix code uses standard Web APIs: fetch, Request, Response, URL, and Headers. These standard Web APIs work consistently across Node, Deno, and the edge. Code that only uses Web APIs is the easiest to move between runtimes.

#Environment Variables at the Edge

Environment variables at the edge are configured per platform project and are available as runtime variables. Pay attention to env size limits and how variables are read in an edge runtime — sometimes through special bindings rather than process.env.

#Use Cases for Edge-First Deployment

#When the Edge Wins

The edge excels at these things:

• Pages and data that are mostly static with little personalization.
• Applications with a broad global audience.
• Light logic such as A/B testing, redirects, and geolocation.
• Edge caching and rate limiting in front of the origin.

#When the Edge Isn't the Choice

Avoid the edge for: long-lived database connections, WebSockets that need persistent connections, or CPU-heavy work. The edge is for quick decisions, not long computations.

#Hybrid Strategies

Many production applications use a mix: the edge for assets and public routes, a server for routes that need full computation. Remix supports this mix because every route can use the runtime that suits it. Start simple, then move the parts that need it to the right place.

To decide which parts go where, ask two questions: does the logic need an API that isn't available at the edge, and is the audience widely spread? Light public routes that read data quickly fit the edge; routes that write a lot of data or use native libraries fit a server.

#Conclusion

Episode 21 opens the world of edge and serverless: edge functions that run close to users, deployment on Cloudflare Pages or Deno, API differences between runtimes, and strategies for deciding when edge-first truly pays off. Your code can now be present around the world at once.

The key takeaways:

• Edge functions run at the node nearest to the user.
• Serverless executes per request in a configured region.
• Remix supports Cloudflare Pages and Deno through adapters.
• Standard Web APIs are the consistent language across runtimes.
• The edge excels at light logic and global audiences.
• A hybrid strategy places each route in the right runtime.

In the next episode, episode 22, we'll discuss observability and support — performance monitoring and real user metrics, error reporting with Sentry, logging request and response metrics, and production support with incident response. The application is spread across the world; now let's make sure you can see how it's doing.