HoloDB
HoloDB is a kind of "metadatabase"—a compiler & collection of heuristics to allow a user to describe their data schema in the most OO way possible, but generate a series of optimised Durable Objects & caching layers.
The goal isn't to compete with hand-crafted Durable Objects or traditional relational DBs in high-throughput or specialised cases, but rather to make general-purpose relational data systems simpler to define & faster to access than a traditional DB running in a single location.
Why 'HoloDB'?
The holographic principle states that the information in a volume of space can be thought of as being encoded in the surface of the region.
For HoloDB, that means the data contained in the global swarm of Durable Objects (like virtual particles, popping into and out of existence when active) is preserved at the "surface"—cached on the edge nodes nearest to the users that are generating the traffic.
It also works as a backronym: Heuristically-Optimised Linked (durable) Objects.
Principles
There are 3 primary design goals of the project:
- The user should describe the Classes' schema, their interrelations & any domain-specific logic that their app requires. HoloDB will automate the creation, deployment & migration of the underlying DOs & any additional infrastructure (like Caches).
- We strive for all reads to be served from Cache. We do this with extremely granular caching logic across multiple tiers, and by eagerly replacing cached values rather than relying on invalidation.
- All writes will instantly propagate changes to any "active watchers". This means that UIs built with HoloDB should always receive a stream of updates, rather than needing to re-query.
Schema Definition
Note: just pseudocode for now. Have a few options.
We want the User to define classes like this:
class User {
name: string
avatar: string
posts: Holo.OrderedList<Post, 'createdAt DESC'>
get latestPost() {
return this.posts.at(0)
}
}
class Post {
title: string
body: string
author: Holo.Ref<User>
createdAt: Date
}