mirror of
https://github.com/hanzoai/papers.git
synced 2026-10-29 01:14:44 +00:00
zeekayandHanzo Dev
34ba5b1cee
The prior-work section describes the 2022 backend by category, and the comparison table and production section cover the systems Base is measured against. hanzo-stack-comparison and hanzo-datastore drop one reference each. hanzo-base.pdf had no source in the repo and is superseded by hanzo-base-runtime. Committed PDFs rebuilt with make. Co-authored-by: Hanzo Dev <[email protected]>
14 lines
1.3 KiB
TeX
14 lines
1.3 KiB
TeX
\section{Prior Work: Base (2022)}
|
|
\label{sec:prior-work}
|
|
|
|
The 2026 Hanzo Base runtime succeeds the 2022 \emph{Base} backend, which extended an existing single-binary embedded backend with a JavaScript plugin system, embedded authentication hooks, and SQLite-backed real-time collections. That earlier system demonstrated that a single-binary backend with a hooks API could replace a typical microservices stack for teams of up to a few dozen engineers.
|
|
|
|
The 2022 architecture had three core design ideas that carry forward:
|
|
\begin{enumerate}
|
|
\item \textbf{Embedded data + runtime}: database and HTTP server in the same process, eliminating a network hop for the common case.
|
|
\item \textbf{JavaScript plugins via Goja}: server-side customization without a separate language runtime or redeploy cycle.
|
|
\item \textbf{Content-addressable file store}: uploads indexed by SHA-256, with automatic deduplication.
|
|
\end{enumerate}
|
|
|
|
The 2026 runtime departs from the 2022 design in three ways: (1) native CRDT collections via Automerge, replacing the eventual-consistency patterns of the 2022 server; (2) SQLCipher-backed storage with KMS-managed keys, instead of plain SQLite; and (3) Lux Network integration for multi-node sync, replacing the per-instance model of the 2022 deployment. The plugin system and content-addressable file store remain compatible.
|