Part I: Foundations
I think it's worth spending a few minutes understanding what Adama is and why it exists before you start writing code. Not because I enjoy preamble, but because Adama makes weird choices that only make sense once you see the thinking behind them.
Three Things to Understand
1. What is Adama?
I explain Adama through three mental models because no single analogy captures it:
- The Spreadsheet Analogy - How formulas auto-update like Excel
- The Database-Code Fusion - Why code and data live together
- The Real-time Webserver - How every document becomes accessible
I also cover who should use Adama and -- more importantly -- what it's not suited for. Knowing the limits matters as much as knowing the strengths.
2. Design Philosophy
Where Adama came from and why it works the way it does:
- Origins in Board Games - The problem domain that birthed the language
- Living Documents - State machines that run forever
- Privacy First - Access control as a language primitive
- Affordability - Designed for sustainable economics
- Laziness as Virtue - Let the runtime do the heavy lifting
3. How It Works
The architecture under the hood:
- Document-Centric Model - The atomic unit of state
- The Delta Protocol - Efficient JSON change propagation
- Actor Model - Isolated, message-driven documents
- Dungeon Master Pattern - Server-controlled workflows
- Scaling Strategy - How Adama handles growth
The Core Insight
The fundamental insight behind Adama: bring compute to the data, not data to the compute.
Traditional web architectures separate databases from application servers, which means you spend your life marshalling data back and forth -- queries, ORMs, connection pools, cache invalidation. Adama combines state and logic into a single "living document." This eliminates entire categories of bugs that I got very, very tired of writing.
Ready to Begin?
Start with What is Adama?