A dead-simple simple library for generating prefixed IDs that provide context to consumers and creators alike.
- Distinct, as all unique identifiers are
- Definite: "free of all ambiguity, uncertainty, or obscurity," thanks to prefixes
- Dang... way easier to use than UUIDs
;)
# a valid prefix is required
did, _ := did.New("us")
u := uuid.New()
# a valid prefix is required
did, _ := did.DidFromUuid(u, "us")
did, _ := did.DidFromString("us-526cac357e74429beb4f2ecca56c571f")
Instead of providing a prefix every time, you can use a factory to generate dids. Using a DidFactory is also the easiest way to use a separator other than the default (-
).
df, _ := did.NewDidFactory("tot", "_")
d, _ := df.NewDid()
d.String() // tot_580a6ae69d3643289d83344c5925818c
- Create random did given a prefix
- Create did from UUID or properly-formatted string
- Methods for String, Length
- Validations for prefixes (alpha 2 or 3 characters)
- built-in prefixes for common use-cases (e.g "users", "accounts")
- More UUID interop: (e.g. comparison)
- #Scan, #Value for DB reading + writing
- performance / benchmarking
- sorting?
- other languages/ alphabets beyond English
Prefixed IDs provide context that makes data from APIs or user interfaces far easier to reason about. If you've ever needed to copy or paste an API key, token, or even your account ID, you have likely mixed up one ID with another at some point. To be fair, this is a minor annoyance... but there is a better way. I was first exposed to prefixed IDs when working at Twilio: (What is a SID?), and the approach just made sense. Using the API, users often had to reference their account ID (AC prefix). Or if they wanted to get the status of an SMS (SM prefix), they needed that. Or a phone number (PN prefix). And so on. This would be far more cumbersome with UUID-heavy records or any other approach that ignores the user (developer) experience. Of course, Twilio is not the only company to do this. For example, Stripe also uses prefixed IDs: Designing APIs for humans: Object IDs. And, as it turns out, Github and many others are doing the same: Behind GitHub’s new authentication token formats.
Moving tables from UUIDs or another type of unique ID will typically require adding a new column and "dual-writing" both UUIDs and dids. It's typically best to name the new column id
, since dids are just one implementation of unique IDs. Start with nullable id
columns, then change them to non-nullable after completing backfills on your "pre-did" records. Update your foreign keys to reference dids, then... drop all the old columns! Most importantly, decide on an ID strategy early on to keep the migration simple. Or, better yet, start with prefixed IDs from the onset.