This is the first post in a series of posts on building xdb. xdb is an attempt at creating an abstraction to simplify data storage and retrieval for product engineers.
xdb's job is to provide a consistent interface to store and retrieve domain data in any database - relational, document, key-value, graph, etc. The goal is to abstract away the underlying database tradeoffs, migrations and management so that product engineers can focus on building products, not databases.
xdb is built on 3 simple abstractions - Key, Attribute & Value. These abstractions can represent most domain models. Here are some examples of how these abstractions can be used to represent different entities:
|Post:1||title||This is a post|
|Post:1||content||This is the content of the post|
|Photo:1||caption||Beautiful sunset over the beach 🌅🏖️|
|Photo:1||location||Los Angeles, CA|
|Review:1||comment||The service was great, but the food was a bit too spicy for me.|
and so on...
A Key-Attribute-Value (KAV) model is a simple way to represent both attributes and relations. This is similar to N-quads. The key difference is that xdb uses
Key instead of
Attribute instead of
Borrowing the N-quads structure, allows the possibility of building a graph server on top of xdb. This is something that we will explore in coming posts.
The whole experience of using xdb is as simple as:
ctx := context.Background() // Define a schema schema := xdb.NewSchema("./schema.yaml") // Create a store store := xdb.NewStore(schema, memory.NewStore()) // Populate data key := xdb.NewKey("User", "1") attr := xdb.NewAttr(key, "name", xdb.String("Ravi")) // Store attribute _ = store.Put(ctx, attr) // Get attribute ref := xdb.NewAttr(key, "name") attr, _ = store.Get(ctx, ref)
With xdb, the product/application/service/API only cares about the shape and values of the domain data. The underlying database can be changed, migrated, scaled, etc. without changing the application code.