---
term: 'Edge Computing & Serverless Edge Functions'
seoTitle: 'Edge Computing & Edge Functions: Isolates, Latency, Limits'
headline: 'What are Edge Computing & Serverless Edge Functions?'
slug: edge-computing-edge-functions
category: backend-compute
shortDefinition: 'Edge computing is a model that runs compute near users or data sources; edge functions are serverless code executing at CDN locations.'
relatedTerms:
  - cdn-content-delivery-network
  - cloud-code-serverless-functions
  - serverless-architecture
  - serverless-cold-starts
contrastsWith:
  - serverless-architecture
aboutTerms:
  - 'Edge Functions'
  - 'V8 Isolates'
  - 'Points of Presence (POPs)'
faq:
  - question: 'What is edge computing in simple terms?'
    answer: 'Running computation close to where data is created or where users are, instead of in one distant data center. Less distance means fewer milliseconds and less bandwidth — the whole idea is geography. The term spans IoT sensors, telecom infrastructure, and, for web developers, code running at CDN locations.'
  - question: 'What is an edge function?'
    answer: 'A small serverless function deployed to a CDN''s global points of presence and executed at whichever location is closest to each request — typically intercepting HTTP traffic to redirect, personalize, or authenticate before it reaches the origin backend.'
  - question: 'What is the difference between edge functions and serverless functions?'
    answer: 'Both are functions-as-a-service; they differ in where (hundreds of locations vs. one region), runtime (lightweight isolates with web-standard APIs vs. full containerized runtimes), cold starts (near zero vs. hundreds of milliseconds), and limits (tight CPU and size caps vs. minutes and gigabytes).'
  - question: 'Why is the edge faster?'
    answer: 'Physics. Round-trip time is bounded by distance through fiber — a cross-ocean round trip costs 100–300 ms before any computation happens, while a point of presence twenty kilometers away costs single digits. Isolate runtimes add near-zero startup on top.'
  - question: 'What are V8 isolates?'
    answer: 'Lightweight sandboxed JavaScript contexts — the same mechanism that separates browser tabs — running by the thousands inside one long-lived process. Each gets its own heap and globals, starts in under five milliseconds with megabytes of overhead, and needs no container or VM boot: the reason edge platforms report effectively zero cold starts.'
  - question: 'What are the limitations of edge runtimes?'
    answer: 'A web-standard API subset — fetch, Request/Response, streams, WebCrypto — with no filesystem, no native modules, and no dynamic code evaluation; tight CPU-time caps (tens of milliseconds is common) and small bundle limits. Many popular packages, from ORMs with native bindings to image libraries, simply don''t run there.'
  - question: 'What belongs at the edge, and what belongs at the origin?'
    answer: 'Edge: stateless gateway logic near the user — token checks, redirects, geo-routing, A/B bucketing, header rewrites, rate limiting. Origin: everything stateful and transactional — database reads and writes, business logic, heavy processing. The rule of thumb: compute near the user, data work near the data.'
  - question: 'Does my database ruin edge latency?'
    answer: 'Often, yes — moving compute to the edge doesn''t move the data. An edge function in Tokyo querying a database in Virginia pays a full trans-Pacific round trip per query; five sequential queries turn a five-millisecond function into a 750-millisecond one. Fixes: run near the data, batch to one round trip, or cache reads at the edge.'
  - question: 'Is a CDN the same as edge computing?'
    answer: 'A CDN caches and serves static content at points of presence; edge computing runs your code at those same locations. Edge functions are the programmable evolution of the CDN — same geography, active logic instead of passive caching.'
  - question: 'Do edge functions have cold starts?'
    answer: 'Effectively no on isolate-based platforms — context creation costs single-digit milliseconds, imperceptible next to network time. That is their headline advantage over container-based serverless, bought at the price of the restricted runtime.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Shi et al. — Edge Computing: Vision and Challenges (IEEE IoT Journal)'
    url: 'https://doi.org/10.1109/JIOT.2016.2579198'
  - name: 'ETSI — Multi-access Edge Computing (MEC)'
    url: 'https://www.etsi.org/technologies/multi-access-edge-computing'
  - name: 'WinterTC — Minimum Common Web Platform API'
    url: 'https://min-common-api.proposal.wintertc.org/'
  - name: 'V8 documentation'
    url: 'https://v8.dev/'
  - name: 'Edge computing — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Edge_computing'
cta:
  title: 'Origin done right, edge where it earns it'
  text: 'Back4app is the origin layer of the three-tier picture: database, auth, and business logic served over a CDN-fronted API — so edge functions, where you need them, stay thin gateway logic instead of a second backend.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-30'
translationKey: edge-computing-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.](https://doi.org/10.1109/JIOT.2016.2579198) as computation placed close to the sources of data — spans factory-floor IoT and telecom [MEC](https://www.etsi.org/technologies/multi-access-edge-computing) infrastructure. For backend developers it means something specific: small functions deployed to the same global points of presence a [CDN](/glossary/cdn-content-delivery-network/) uses, running at whichever POP is nearest each request — the CDN's evolution from caching content to executing code.

## Key takeaways

| Question | Answer |
| --- | --- |
| Why edge is fast | Physics — RTT is distance; a nearby POP is ~5 ms, an ocean is ~150 ms |
| The runtime trick | V8 isolates: browser-tab sandboxes, ~ms startup, no container boot |
| What belongs there | Stateless gateway logic — auth checks, redirects, personalization |
| What doesn't | Data work — the database is still in one place |
| The honest caveat | Edge moves the round trip; only data strategy removes it |

## An edge function, and the layer it lives in

**JavaScript:**

```javascript
// 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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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

| | V8 isolates (edge) | Containers / micro-VMs (regional FaaS) |
| --- | --- | --- |
| Startup | **under 5 ms** — create a JS context | 100–1,000 ms — boot runtime, [cold start](/glossary/serverless-cold-starts/) |
| Memory per tenant | ~2 MB | 30–50 MB+ |
| Isolation boundary | In-process sandbox (browser-tab tech) | OS/hypervisor — stronger |
| API surface | Web-standard subset | Full language runtime |
| Execution caps | CPU-tens-of-ms, small bundles | Minutes, gigabytes |
| Fits | Per-request gateway logic | Real application workloads |

Thousands of isolates share one long-running process per machine — the [same mechanism](https://v8.dev/) 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](https://min-common-api.proposal.wintertc.org/).

## Edge vs. origin: the workload split

| Workload | Runs at | Why |
| --- | --- | --- |
| Token/session checks, bot blocking | **Edge** | Reject bad traffic before it crosses an ocean |
| Redirects, geo-routing, A/B bucketing | **Edge** | Per-request, stateless, latency-visible |
| Header/cookie rewrites, cache logic | **Edge** | The CDN's native habitat |
| Database reads and writes | **Origin** | The data is there; RTT per query otherwise |
| Business logic, transactions | **Origin** | Stateful, multi-step, needs the [full runtime](/glossary/cloud-code-serverless-functions/) |
| Media processing, long tasks | **Origin** | CPU caps forbid it at the edge |

## 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.

```mermaid
flowchart LR
  accTitle: Edge functions in front of a central origin and database
  accDescr: Users connect to their nearest point of presence, where edge functions handle gateway logic like redirects and auth checks in milliseconds. Requests needing data continue to the central origin backend and database, paying the geographic round trip once, while static assets are served from the CDN cache at the same points of presence.
  U1["User (Tokyo)"] --> P1["Nearest POP<br/>edge fn: auth, redirect ~5 ms"]
  U2["User (Berlin)"] --> P2["Nearest POP<br/>edge fn + CDN cache"]
  P1 -->|"data work: one<br/>round trip, batched"| O["Origin backend<br/>+ database (one region)"]
  P2 -->|"static: served<br/>from cache"| P2
  P2 --> O
```

## 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](/glossary/json-web-token-jwt/) 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

| Situation | Lean |
| --- | --- |
| Global users, latency-visible gateway logic | Edge — its home game |
| Logic that completes at the edge (no DB) | Edge |
| Chatty database access per request | Origin — every time |
| Regional user base, standard CRUD app | Origin + CDN; edge adds nothing |
| Heavy dependencies, native modules, long CPU | Origin — the runtime forbids edge |
| Static assets | The [CDN cache](/glossary/cdn-content-delivery-network/) — no function needed |

## 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](/glossary/cloud-code-serverless-functions/) 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](/glossary/access-control-lists-acl/) 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.