xid VS hord

The goal of babyapi is to be so easy that a baby could do it. As previously mentioned, babyapi.DefaultResource already implements the required interface, so it can be used as a starting point for simple resource types. Besides simply implementing the interface, this default struct implements some validations around the ID and uses rs/xid to create a unique identifer on new resources.

To schedule a job, all we need to do is serialize the payload, create a new JID (we use XID for JIDs), and insert both into the adc_queue table.

XID's are 96 bits. The first 32 bits are the time, which means we get our k-sorting immediately. The next 40 bits are a machine identifier and a process identifier. However, unlike the other systems, these are calculated automatically using the library and don't require us to configure anything ourselves. The final 24 bits are a sequence number, which allows a single process to generate 16,777,216 identifiers per second!

Checkout xid https://github.com/rs/xid and how MongoDB does its id

I've had success using xid for user-visible IDs. What's nice is they're shorter than UUID, will sort in order, hides the amount of rows in the table.

https://github.com/rs/xid

In an effort to provide actual persistent storage out of the box, the babyapi/storage package uses madflojo/hord to support a variety of key-value store backends. Additionally, babyapi/storage provides helper functions for initializing the hord client for Redis or file-based storage.

Determined to implement generics and delete some lines of code, I turned my sights to the storage layer of my application. I designed my storage around key-value pairs since I started by storing resources in YAML files. This eventually evolved to use madflojo/hord to interact with key-value data stores like Redis. The function to read a *pkg.Garden from storage looks like this: