101–110 of 199 posts
Earlier quoted context omitted.
The hazard of base64 is the use of '+', '/', and '=' characters, which most HTTP engines treat as special.
Luckily the spec provides for a url safe variant (sometimes called base64url): https://datatracker.ietf.org/doc/html/rfc4648#section-5
Earlier quoted context omitted.
There is the rub. Readable for what purpose? Aesthetics? And why? It is meaningless in their example. And what do they mean with communication? Reading it aloud? If the URL is too long to stick in a tweet or message, there are plenty of URL shorteners out there.
Copying very long URL’s into a Markdown document or a social media post is pretty annoying. URL shorteners are opaque and add a point of failure. On link-sharing sites like this one, we care about the URL’s we share and will often strip off the tracking stuff.
I completely agree. UUIDs are almost always evidence of overengineering, especially when user-facing. 64-bits is "enough" of an address space for almost any purpose, even global. And while it seems like speaking an ID over the phone or having to scan it manually is something you'd never have to do, in practice it happens all the time. Cut-and-paste is not always an option on all platforms.
But besides human friendly slugs, which usually have an ID mapping behind the scenes in my experience, it seems like there might be more work than value for startups in many cases.
Earlier quoted context omitted.
You only really need this part: https://amazon.com/dp/B09V3HZ8B5
Yes but that's irrelevant, I used a real URL that you will receive in your texts. It's real life, it happens and it sucks. Let's not normalize it.
As you have been told apple.com/iphone = www.amazon.com/dp/B09V3HZ8B5
The rest of what you posted on the Amazon link is tracking bullshit. Now, THAT is irrelevant !
Isn't auto generating UUIDs "fast enough" in most situations that its negligible? In particular databases (where UUIDs taking space was a big concern) they have largely switched to a packed binary format that makes the size of UUIDs over time a non issue for all practical purposes.
UUIDs are packed in DBs. But they tend to get misused as PKs. In common relational DBs, your PK for every table should probably be bigserial.
There are so many nuances and edge cases not mentioned in the article. The author needs to do several projects in real life before making global pronouncements like this.
The lack of humbleness and respect for devs who have came before you and solved all these problems is coming through strong. But I myself was that way 15 years ago. It takes a lot of hard lessons to realize everything new is old and we truly stand on the shoulders of 7000 giants all standing on each others’ shoulders.