API should switch to UUIDs for entity Identification

[from-nibly]

A binary ID is cumbersome and nonstandard on the web. From looking through the other issues this seems to be a leaky abstraction of the implementation detail; the ID's in the database are encoded into binary values to increase indexing speed. While fine to use such an optimization on the database side of things it seems unwise to leak that to the API. Much more easily the API can consume UUID values and convert them to whatever you want.

UUIDs are the only type of IDs, that I know of, which are expected for an external user to generate before creating. It is not really possible for a user to keep track of an index of IDs outside of the database in order to create an ID other than generating it randomly anyway.

So if UUIDs are the expected id type then the API should explain that with it's contract not with it's documentation.

[pnagurny]

Thanks for checking out the project and giving feedback @from-nibly .

So here was my thinking regarding id's:

1. I didn't want an autogenerated incrementing integer provided by the database. It leaks information on how many other objects there are in the database.

2. That leaves some sort of universally unique identifier.

3. I could have had the server generate an id when an object is created, but I decided to have the user generate them since it allows for some convenience. For example, you can locally create a whole tree of accounts and upload them all in one POST. This wouldn't be possibly if the server assigned id's.

4. I looked into client generated UUID's. According to the wiki article, they are 128 bit keys. There are 5 different versions: 4 of them based on date / time / mac address / namespace. One of them based on random data. I only saw utility in the randomly generated version. The others include unnecessary data.

5. Instead of using the more complex UUID format, I decided to use a simpler format. Generate a random 128 bit number and encode it into a hex string. It's easy to consume and generate in the API. The database can get a performance boost by storing them as BINARY(16).

Do you see any advantage to using the traditional UUID format as opposed to the simpler 128 bit hex string?

[inmanturbo]

Do you see any advantage to using the traditional UUID format as opposed to the simpler 128 bit hex string?

@pnagurny
Perhaps the only advantage is in the established convention. UUID's are a fairly common practice and may be easier for client libraries to support. Also if someone were attempting to export/import data from another system which already uses UUID's it could greatly simplify things.

The logic and methodology behing the 128 bit hex string is sound, however UUID's is already an accepted practice with guidelines, tools and support systems in place, such as from a 5 second google search:

https://www.guidgenerator.com/online-guid-generator.aspx

The common practice in UUID generation is for backend models to optionally accept a UUID as an argument, otherwise generate them so that the UUID is guaranteed to be established prior to the creation event.

[trasherdk]

I kinda like server generated, by a singleton, id's. Something like 😃

(+new Date()).toString(36)
"lbukw9cb"

Easy to generate combined keys:

tx = {
  key: `${user}:${debit}:${credit}`,
  value: 12345
}