We Rebuilt Our Node.js API for Edge Functions—Here’s What Actually Changed

You know that pain when your API feels sluggish—users are scattered across the globe, but your backend is stuck in North America. Requests from Sydney? Laggy. From Berlin? Still laggy. I got tired of apologizing for "regional latency." So, we rebuilt our Node.js API for edge functions, aiming to run our logic closer to users. If you’re skeptical about moving APIs to the edge, I get it. I was too. Here’s what really changed, what broke, and what genuinely improved.

Why Move an API to the Edge Anyway?

For years, our API lived on a trusty Node.js server, behind a load balancer. It worked, but we kept hearing complaints about slow responses. As our user base grew more global, the old setup just didn’t cut it.

The promise of edge functions is simple: run your code in data centers all over the world, slashing latency for users no matter where they are. But the thing is, edge environments aren’t just “Node.js in more places.” They’re stripped-down, have limits, and require you to rethink some assumptions.

I’ll walk you through what we changed, what code actually looks like, and the stuff that tripped us up.

What Changed: From Node.js Server to Edge Functions

Server: The Classic Express Setup

Our old API was a typical Express app. Here’s a simplified version:

// index.js (classic Node.js Express server)
const express = require('express');
const app = express();

// Parse JSON bodies
app.use(express.json());

app.post('/api/greet', (req, res) => {
  // Access body directly
  const { name } = req.body;
  res.json({ message: `Hello, ${name}!` });
});

app.listen(3000, () => console.log('Server running on 3000'));

Why it worked:

• Easy local development
• Access to full Node.js APIs (file system, sockets, etc.)
• Middleware like express.json() made parsing a breeze

The catch:

• All requests hit our central server, so users far away waited longer.

Edge Functions: What’s Actually Different

When you switch to edge functions (like Vercel, Netlify, or Cloudflare Workers), you get a new runtime. That means:

• No express
• No access to Node.js APIs like fs or process
• Requests come as Request objects (Web Standard)
• Limited compute and memory

Here’s what our edge version looks like:

// greet.js (Edge Function, e.g. for Vercel or Cloudflare Workers)
/**
 * Edge functions use the Web API Request object.
 * No Express, no Node.js-specific features.
 */
export default async function handler(request) {
  // Parse JSON body (async, since Body is a stream)
  const body = await request.json();
  const name = body.name;

  // Return a Response (Web API)
  return new Response(
    JSON.stringify({ message: `Hello, ${name}!` }),
    {
      headers: { 'Content-Type': 'application/json' }
    }
  );
}

Key differences:

• You parse the body with await request.json() (no middleware)
• You return a Response object, not res.json()
• No access to process.env or fs unless your platform allows it

Did it work?

Yes—users in Europe and Asia saw much lower latency. The API felt snappier. But we ran into a bunch of unexpected pitfalls.

Authentication: Re-thinking Sessions

On the server, we used sessions (stored in Redis) for auth. Edge functions don’t have persistent connections, so sessions are trickier.

Example: Edge JWT Auth

We switched to stateless JWTs. Here’s how we verify tokens at the edge:

// verify.js (Edge Function JWT Auth)
// Note: Use a library that supports Web Crypto API, not Node.js 'crypto'
export default async function handler(request) {
  const authHeader = request.headers.get('Authorization');
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return new Response('Unauthorized', { status: 401 });
  }

  const token = authHeader.split(' ')[1];

  // Example: verify JWT using Web Crypto
  // (Pseudo-code, since actual JWT verification needs a library supporting Web Crypto)
  const isValid = await verifyJWT(token); // Custom function using Web Crypto

  if (!isValid) {
    return new Response('Unauthorized', { status: 401 });
  }

  // If valid, proceed
  return new Response('OK');
}

// Comments:
// - 'verifyJWT' needs to use Web Crypto API, not Node.js 'crypto'
// - Edge runtimes don't include Node.js libraries, so you need compatible libraries

Lesson learned:

We had to pick JWT libraries that work with edge runtimes (like Jose). Most Node.js JWT libraries just don’t work at the edge.

Database Access: The Big Gotcha

This was our biggest struggle. Edge functions spin up everywhere, but your database is still centralized (unless you use edge-capable DBs like PlanetScale or D1). Connecting from a distant edge location to a US-based database can actually increase latency.

What we did:

We cached responses aggressively and moved some data to edge-friendly stores (like KV). For real-time writes, we still hit the main DB, but only from nearby regions.

Example: Edge Caching with KV

// kv.js (Edge Function with KV caching)
// Example using Cloudflare KV (pseudo-code)
export default async function handler(request, env) {
  const cacheKey = 'greet:' + request.url;
  let cached = await env.MY_KV.get(cacheKey);

  if (cached) {
    // Serve from cache
    return new Response(cached, { headers: { 'Content-Type': 'application/json' } });
  }

  // Not cached, generate response
  const body = await request.json();
  const name = body.name;
  const response = JSON.stringify({ message: `Hello, ${name}!` });

  // Store in KV (for future requests)
  await env.MY_KV.put(cacheKey, response);

  return new Response(response, { headers: { 'Content-Type': 'application/json' } });
}

// Comments:
// - 'env.MY_KV' is injected by Cloudflare Workers platform
// - KV is eventually consistent; not for real-time data

Takeaway:

Edge storage is fast for reads, but you have to be careful with consistency. For data that needs to be instantly up-to-date, stick to your main DB.

Common Mistakes When Building Edge APIs

Honestly, we learned these the hard way. If you’re moving to edge functions, watch out for:

1. Assuming Node.js APIs Are Always Available

I spent a weekend debugging a feature that needed crypto.randomUUID(). Turns out, some edge runtimes only support Web Crypto, not Node.js crypto. Always check what’s actually supported.

2. Not Handling Cold Starts Properly

Edge functions spin up on demand. If you initialize expensive resources (like DB connections) at the top level, you might hit errors. Keep your code stateless, and initialize things inside the handler.

3. Ignoring Database Latency

Just because your function runs everywhere doesn’t mean your DB does. If you don’t cache or use edge-friendly storage, you might make latency worse for some users. We saw this firsthand—Asia users hitting our US database through an edge function were actually slower than before.

Key Takeaways

• Edge functions can make APIs much faster for global users, but only if your data is nearby or cached.
• You have to re-think authentication, middleware, and storage—classic Node.js tools don’t always work.
• Choose libraries that support Web API standards, not Node.js-specific features.
• Watch out for cold starts and keep your functions stateless.
• Edge storage is great for caching, but not always for real-time data.

Closing Thoughts

Moving our API to the edge wasn’t just a technical upgrade—it forced us to rethink how we build and serve data. It’s not a magic fix, but for the right workloads, it’s a game-changer. If you’re tired of apologizing for latency, it might be worth a shot.

---

If you found this helpful, check out more programming tutorials on our blog. We cover Python, JavaScript, Java, Data Science, and more.