What are Edge Computing & Serverless Edge Functions?

Edge computing is a model that runs compute near users or data sources; edge functions are serverless code executing at CDN locations. The broad term — canonically defined by Shi et al. as computation placed close to the sources of data — spans factory-floor IoT and telecom MEC infrastructure. For backend developers it means something specific: small functions deployed to the same global points of presence a CDN uses, running at whichever POP is nearest each request — the CDN’s evolution from caching content to executing code.

Key takeaways

An edge function, and the layer it lives in

// JavaScript — an edge function (web-standard APIs, runs at every POP)
// Gateway logic at the edge; the backend stays the source of truth
export default async function handler(request) {
  const url = new URL(request.url);
  const country = request.headers.get('x-user-country') ?? 'US';

  if (url.pathname === '/' && country !== 'US') {
    return Response.redirect(`${url.origin}/${country.toLowerCase()}/`, 302);
  }
  // Verify a session quickly at the edge; data work goes to the origin
  const auth = request.headers.get('Authorization');
  if (!auth) return new Response('Unauthorized', { status: 401 });

  return fetch(request); // pass through to the origin backend
}

// Flutter / Dart — Back4app Flutter SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
final query = QueryBuilder<ParseObject>(ParseObject('Post'))
  ..whereEqualTo('status', 'published')
  ..setLimit(20);
final response = await query.query();
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// iOS / Swift — Back4app Swift SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
let query = Post.query("status" == "published")
  .limit(20)
let posts = try await query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// Android / Kotlin — Back4app Android SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
val query = ParseQuery.getQuery<ParseObject>("Post")
query.whereEqualTo("status", "published")
query.limit = 20
val posts = query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

The JavaScript tab is the edge function itself — web-standard Request/Response, no framework, intercepting traffic before the origin. The client tabs show the other side of the architecture: application data still flows to the origin backend, because that’s where the database lives — the sentence this entire article keeps returning to.

Isolates vs. containers: why edge starts in milliseconds

Thousands of isolates share one long-running process per machine — the same mechanism that keeps browser tabs apart — so “starting” a function means creating a context, not booting a runtime. That architecture, not warm pools, is why edge platforms honestly claim near-zero cold starts. The bill is the third and fourth rows: a weaker isolation boundary (patched with careful mitigations) and a runtime where much of npm doesn’t run — no filesystem, no native modules, no dynamic evaluation, with the portable surface now being standardized as the Minimum Common API.

Edge vs. origin: the workload split

The honest part: your database is still in one place

The section vendor explainers omit. Moving compute to the edge does not move the data — it relocates the round trip from user → server to function → database, and for chatty workloads that’s a downgrade: an edge function 5 ms from the user making five sequential queries to a database 150 ms away spends 750 ms where a regional function co-located with the database would spend ~5. The arithmetic explains the industry’s quiet correction — some major edge platforms now recommend their regional runtimes for most workloads and added options to pin functions near the database, the strongest possible admission that data locality beats compute locality. The partial fixes, in order of practicality: run data-heavy code at the origin (the split table above); batch to one round trip when edge code must touch data; and replicate reads outward via edge key-value caches — eventual-consistency trade-offs included. Edge functions win when they complete at the edge; the moment they phone home per request, geography stops being on your side.

When edge is over-engineering

Most applications are a CRUD backend with a regional user base — for them, a single-region backend plus a CDN for static assets is simpler and often faster end-to-end than an edge tier that round-trips to the same database. Edge functions earn their place when the logic completes at the edge for a globally distributed audience on a latency-visible path — three conditions, all required. The cost model tells the same story from the other side: edge platforms bill per-request plus CPU-milliseconds (cheap for thin gateway logic), while regional functions bill wall-clock duration — including the time your code spends waiting on the database it should have been sitting next to.

Common use cases

• Authentication gates — verify a session token at the POP; unauthenticated requests never cross the ocean.
• Geo-personalization — language, currency, and compliance routing decided milliseconds from the user.
• A/B and feature bucketing — cookie assignment at the edge, consistent before the page even loads.
• Rate limiting and bot defense — absorb abuse at the perimeter, per-POP counters in edge KV.
• Broad edge computing — the IoT/telecom sense: factory sensors and 5G infrastructure processing locally, a different article’s depth acknowledged in one line.

Should you use edge functions? A decision matrix

Limitations and trade-offs

• The runtime is a subset. Web-standard APIs only; ORMs with native bindings, image libraries, and filesystem-dependent code don’t run — check the dependency tree before committing.
• CPU caps are strict. Tens of milliseconds of compute is the budget; edge functions shape traffic, they don’t process it.
• State is elsewhere by design. Every stateful need routes to the origin or an edge KV with eventual-consistency semantics — neither is free.
• Debugging is distributed. Reproducing a bug that only occurs at one POP under one geography is its own discipline; logging centrally from everywhere is the mitigation.
• The pendulum swings. Edge-first defaults have already been walked back once; treat edge as a precise tool for gateway logic, not an architecture identity.

Edge and Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. In the three-layer picture this article draws, Back4app is the origin done well: the database and Cloud Code business logic live together — the co-location that makes data work fast — behind a CDN that serves files and static assets from the same POPs an edge tier would use. Edge functions then slot in front as thin gateway logic where the three conditions hold: a redirect here, a token check there, passing through to an origin that owns the data and enforces ACLs on every request. The architecture lesson the honest section teaches — compute near the user, data work near the data — is exactly this split, with each layer doing the part geography favors.