xid VS uuid

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

I use Google's UUID package a lot. But every time I refer to it in a new package, the language server picks up https://github.com/gofrs/uuid instead of https://github.com/google/uuid and then complains that the gofrs package isn't in go.mod. I assume because it's the first alphabetically (though this seems like a huge supply chain security loophole).

Just store one single UUID as a token in a client's cookie (use https://github.com/google/uuid for ex), and associate that to a user ID (or anything else relevant in your case), and an expiry date for example

Depends on your needs I think, I generally just use github.com/google/uuid like /u/wowsux mentioned it supports v1 through v5 of the UUID spec.

And we are also going to use google/uuid to generate random uuids.

If you are using "github.com/google/uuid", try the following codes

You can see the same naming dilemma in many Go library implementations, i.e., where a package is used to organize functions related to a single a type (https://github.com/google/uuid) vs organizing code of related functionality (https://github.com/golang/go/tree/master/src/math).

Type inference is not perfect yet (especially for functional options). Also not being able to add type parameters to methods is a bit annoying (can be worked around using package-level functions) but besides that generics fit quite nicely into the library. If type inference gets better then I think I can even remove the hard dependency on github.com/google/uuid and let users use custom types for ids.

Learn how to create UUIDs: https://github.com/google/uuid