gen-z-developers.sgit.ai → The graph → Ideas → No server, by design: retire the back end too, and keep only commodity servers

frame candidate goes to: this-edition T town planner

No server, by design: retire the back end too, and keep only commodity servers

After the database, the back end: the newsroom's personas, reading meter, payments, versions and databases all run in the browser, and what is left on the server side is a product someone else runs (static hosting, a vault server that stores only ciphertext, a payment link, DNS, a build pipeline). A constraint did the design: the vault server cannot read anything, so the logic had to go where the key is. It scales without its complexity scaling, ships fast (114 releases in eleven days), and lines up with sovereignty, privacy, explainability and determinism. The one real limit: a secret the reader must not hold cannot live in their browser.

Decided by. Nobody yet: a candidate for Dinis to read, comment on and decide (keep, rewrite, merge, cut, article first, later, not doing it).

Note. Answers the 2018 outline Serverless ('the path to Serverless', 'important to understand the limitations') from the other side: not Lambda, no back end at all. Not a claim that servers are bad: a trading system or a bank's ledger needs shared, live, authoritative state.

Where it comes from

What it answers in the 2018 book

Where it goes

Chapter Serverless, for real, part Build it without a server (drafting); topic Building blocks: cloud, serverless, free models, git and CI.

Other ideas proposed for the same chapter: Building blocks: cloud as Lego, free models with your own key, git as a standard, The file system is the database: load, extract, transform, save, and keep every intermediate as a file, Ship now, and ship your startup serverless: no servers of yours, no database, client side, with privacy by design and control of your agents.

Node idea:no-server-by-design in graph.json; see it in the graph. Source: admin/content/graph/ideas.json.