05.02 · Concept
Static and Edge
Say what belongs at the edge and what cannot go there because it needs your data.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Static output belongs on a CDN when many users can receive the same bytes, while edge code suits small request-local decisions such as redirects, headers, cookies or geography. Fresh private data, database reads, secrets and full Node.js assumptions usually belong at the origin, not in globally cached or constrained edge runtimes.
What this lesson answers
- what should run at the edge
- when should static pages not be cached
- why not query a database from edge functions
Notes
Static and Edge — Static and edge execution exist to serve cacheable files and request-local logic close to users, because putting database-dependent or secret-heavy work there causes stale data, high latency back to origin, or unsupported runtime failures.
Key Concepts: - Static content is prebuilt once, e.g. `GET /pricing.html` served from a CDN cache with no per-request compute and often `Cache-Control: public, max-age=31536000, immutable`. - Edge code runs near the user but should depend only on request data, headers, cookies, geolocation, or cached values, e.g.
References
Common questions
- What is the difference between static and edge deployment?
- Static deployment serves prebuilt files without per-request application code. Edge deployment runs small pieces of code near the user before the request reaches the origin. Static is best when the response is shared across users. Edge is best when the decision depends only on the incoming request and does not need fresh private data.
- Can personalised pages be served from the edge?
- Only limited personalisation belongs at the edge. Choosing a locale, currency, redirect or cache key from headers, cookies or geography is a good fit. Showing account data, invoices, balances or anything requiring authorisation checks against application state should run on the server that can safely access the database.
- Why do Node.js libraries sometimes fail in edge runtimes?
- Many edge runtimes are not ordinary Node.js processes. They often expose Web APIs and omit filesystem access, native drivers or other server features. Code built around an ORM, local files or Node-specific modules can fail there, even if the same code works in a serverless function or long-running server.
Short definition: what is Static and Edge?