Hacker News Reader

Comment by emschwartz | Hacker News Reader

The use case is a multi-tenant application where each organization has a set of plugins or integrations. Those integrations have associated config objects and maybe some other properties. Each organization might have some other resources that users create.

It seems somewhat nice to have resources that users create and interact with via an API + CLI to use identifiers that people can type out and remember instead of copying.

Unguessability isn't a big deal because all of these IDs can be namespaced under the organization ID and the auth check can just return a 404 instead of a 401/403 if the person doesn't have access.

View on HN

Why not support both ID versions pointing at a single resource?

Good question.

I'm somewhat inclined to say if we're uniquely identifying resources with a unique, human-readable string, that's the ID you should always use to refer to things. It seems slightly more complicated to explain to users that there are these two ways to refer to things.

There's also the issue (or benefit) of keeping the UUID the same if you are able to change the human-readable ID.

It's not so different from users, ids, and display names

In that case, you're going to run into the same problem that happens with any organizational naming: names aren't stable. Reorgs happen. Buyouts happen. Rebranding happens. Even people's names change. Anyone who has ever worked at a moderately-sized company that got bought or renamed, knows the hell of The Renaming. And there's always things left out. Are you going to go through and change all package names in your code? Or are you going to be left with a fragile bit of tribal knowledge or obscure documentation explaining what "oldname" means everywhere?

And don't even get me started on auth checks and someone spoofing the system because something still accepts the old identifier long after the original owner gave it up and some malicious party grabs it.

This has nothing to do with the user's question. What you describe is at the code level naming patterns, what OP is asking about is database columns, and fairly standard queries at that.

The Naming Problem applies, I just used package names as an example. How many times have you seen a network, computer, project, or whatever named for something that no longer exists? The OP mentioned "Github organization / repo names" specifically. I know of github repos that are less than a year old and already refer to teams that don't exist any more. I presumed that's what was meant by "human readable IDs". Now if the "human readable" just means something like "pronounceable words", well, the only problem is no matter what language is chosen for those words, there will likely be someone who doesn't know what they mean, so they are just gibberish anyway.

Reply on news.ycombinator.com