Hacker News Reader

Comment by alexandernst | Hacker News Reader

Hi, I'm mister UUID and I have been living in your favourite framework since 2001. Use me.

UUID are the way, GUID for those in Microsoft's lands.

Not only will you never run out but you don't need a round trip to the keymaster, horizontal scaling, clustering and vertical sharding even are all way easier due to that. This removes a single point of failure entirely when the keymaster is no longer needed.

Using ints for keys for profiles/users and many other things were needed way back when processing/db/disk/memory and performance from that were a problem, no longer.

Do your part, join the UUID revolution. Also, if you were a piece of data, would you not want to be unique across all the databases, storage and services? You've heard of Roko's Basilisk right? Do not disappoint.

I’ve often wondered where the tipping point is where you do start having to worry about collisions. Is frantic “fix all the uuid breaking code” the jobs boost for programmers 20 years from now? 100?

It seems unthinkable now but who knows...

We'll be good until at least sentient AI takes over and they can solve it for us, or them.

We've had multiple collisions with uuid v4. I'm not overly familiar with the examples, but in one case, the collision was found because the collision happened in the same account! Customer: "Why do these two events have the same id?" Us: "Wow." I think we determined that it was a limitation in the random number generator in the Perl lib we were using. To avoid that, I believe the solution was to go with uuid v1 plus a nonce of some sort.

If you have collisions with UUID v4, something is really broken with your UUID generator. It's not a "limitation", it's a critical bug.

GUIDs are expensive to compute. They are based on your MAC address, that is read every time from your registry.

You are describing a particular way of creating a UUID ("Version 1").

Another method, "Version 4", is simply a 122-bit random number.

Holy schmolies, yes. And if you use them as your access keys for, say, a webservice, people aren't really going to be able to fish around the same way they can if you use auto-increment integers.

If your url looks like https://awesomeunicorn.com/userProfile/123, it's pretty obvious that I could start poking around and trying to get user 122 or 124. If that url is https://awesomeunicorn.com/userProfile/123456-dead-beef-abba..., I don't really have any idea what the ID of the next user might be.

The downside is that your urls are long, ugly and incomprehensible.

The upside is that your business is not totally transparent to outsiders who can figure out how many users, carts, products and messages you are adding each month.

There must be some other way. I can often figure out the direct url to a software project in bitbucket, but office365 urls are pages long. I somehow doubt atlassian is as transparent as you say.

Disclaimer: not a web dev

This is a massive issue with pastes on GitLab.

Unlisted, private, public snippets all get links such as https://gitlab.com/snippets/1712835

If you have an instance with few users, you can just create a new snippet and then auto-decrement.

e.g. I just found https://gitlab.com/snippets/17128 this way.

If trying more or less random URLs of your service is an issue for you, you have an issue.

True, you absolutely should have security and authorization setup. But if the server replies to the request with a 401 or 403, rather than a 404, you at least know that there is something there.

Other advantages of UUIDs:

- client can generate the UUID, allowing eventual consistency and retrying using distributed DBs (other DB is on phone for example)

- merging of DBs is easy

- allows capability based access control (you can’t guess the UUID, you don’t have access)

- can use a bit or teo to encode production vs development IDs, so cross contamination of systems is less likely

This post discusses using UUIDs as primary keys (but never exposing them), and an additional integer key on each table as the public facing ID.

https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html

HN discussion: https://news.ycombinator.com/item?id=16050047

Reply on news.ycombinator.com