Motivations Behind lytedb

I created lytedb to have a simple interface to store, retrieve, and persist Go structs. The idea is to have no friction between saving a struct and returning it from the database. For example, if I want to get a user from my db, it should be this simple:

// add a new user under the key 'user-id'
lytedb.Add("user-id", User{Age: 22, Name: "Andres"})

// our user struct
var user User

// write value assigned to 'user-id' onto our struct
lytedb.Get("user-id", &user)

Before you would have to choose your database, choose how you encode your data, and then retrieve and encode/decode everytime you Set/Get an entry. I wrote this tool because I found myself repeating this data encoding loop in most of my web dev projects. If I am building a hobby project, why not make my data persistence layer seamless?

I wanted to make this tool lean and for that reason the package is small and contains a tight API.

How it works

Lytedb is built on two main tools. The first being bolt a persistent key-value store written purely in Go. This goal of that project is to “is to provide a simple, fast, and reliable database for projects that don’t require a full database server such as Postgres or MySQL”. Perfect! The second tool is the encoding/gob which allows fast serialization between structs and binary values. The gob package is how lytedb serializes data and stores it. When you store a value on disk it is stored in the gob binary format. When you retreive it the package handles the decoding and writes directly onto the struct you initialized.

Why not use encoding/json?

This would make writing to and from REST APIs perhaps a bit easier but I decided that the perfomance gains from encoding/gob are worth it for most cases. JSON adds complexity and perfomance costs that may not be needed in most cases. Keeping storage simple and perfomant is the main goal. You can check out the json vs gob benchmarks here.

Future

For now this package does what I set out for it to do so I do not expect many changes. I am looking to add benchmark tests and maybe a JSON datastore to allow easy writing to/from REST APIs. Feel free to contribute!