181–190 of 199 posts
IMO, a good middleground is using schemes like TypeID[0], ulid[1], or KSUID[2] that provides a more compact and readable (base32) representation and provides better database locality (K-sortable). [0] https://github.com/jetpack-io/typeid [1] https://github.com/ulid/spec [2] https://github.com/segmentio/ksuid
IMO, a good middleground is using schemes like TypeID[0], ulid[1], or KSUID[2] that provides a more compact and readable (base32) representation and provides better database locality (K-sortable). [0] https://github.com/jetpack-io/typeid [1] https://github.com/ulid/spec [2] https://github.com/segmentio/ksuid
I'm recently finding Cuid2 to be the best of these alternative GUIDs. They seem to have all of the benefits for what you would want to use a GUID for, but none of the drawbacks of existing implementations.[1] [1]: https://github.com/paralleldrive/cuid2#comparisons
> A simple ID like 3c6n63N is more than enough to represent any product while keeping it readable and making communication easier. A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from a user’s perspective. I would challenge the premise we appear to be starting from, that the average end user cares to be dealing with any random string of numbers and digits. GUIDs work well, they’re implem…
https://en.wikipedia.org/wiki/Snowflake_ID
They fit within 64 bits, allow for more than enough processes to handle 10k+ transactions per second, give enough of a timestamp headroom for decades into the future, and where ID generation can be made isolated to each process.
They don't work well for anything related to archival work, but you might as well use a regular ID for that anyway, unless you're also actively scraping terabytes of data off of the Internet every second, in which case UUIDv5's good enough for your extreme edge case.
...But at that point you might as well just roll your own 128-bit version of a Snowflake ID.
Earlier quoted context omitted.
I see bad url design for other reasons but nothing wrong with UUIDs, so no it doesn’t help me see the argument.
What do you mean by bad url design? Because it's using UUIDs? That was my point.
> A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from an user’s perspective. The argumentation in this article is pretty poor from my experience. A UUID isn’t meant to be handled by the non-technical end user. The end user usually doesn’t and shouldn’t care about the URL. I can assure there are bigger architectural problems in your design if your user has to care about accessible intern…
Does this help see what's wrong with UUIDs in URLs? A GitHub issue URL in a parallel universe: https://github.com/a73ba12d-1d8b-2516-3aee-4b15e563a835/e16957bf-7d7f-41f1-97f4-98c93a6c3540/issues/4e4e9133-bcdb-45b9-8dfe-9e951846e3c6
https://github.com/4e4e9133-bcdb-45b9-8dfe-9e951846e3c6
urn:uuid:4e4e9133-bcdb-45b9-8dfe-9e951846e3c6
Earlier quoted context omitted.
Does this help see what's wrong with UUIDs in URLs? A GitHub issue URL in a parallel universe: https://github.com/a73ba12d-1d8b-2516-3aee-4b15e563a835/e16957bf-7d7f-41f1-97f4-98c93a6c3540/issues/4e4e9133-bcdb-45b9-8dfe-9e951846e3c6
A fairer comparison would be that in that universe the url would be: https://github.com/4e4e9133-bcdb-45b9-8dfe-9e951846e3c6 or even urn:uuid:4e4e9133-bcdb-45b9-8dfe-9e951846e3c6 with the right infrastructure.