3 ms·

This is absolutely right. I suspect some people do this because Twitter went out of their way to get 64-bit ids[0] -- but Twitter did this in large part because

by bkirwi 12y ago

This is absolutely right. I suspect some people do this because Twitter went out of their way to get 64-bit ids[0] -- but Twitter did this in large part because they made the mistake of baking that bit-length into the protocol back when they were tiny, and since they don't control all clients, it's very difficult to change. For comparison, here's an eager.io URL: https://eager.io/app/ZYBle8qUhKFJ https://eager.io/app/ZYBle8qUhKFJ And here's an equivalent with UUID in base-64: https://eager.io/app/b8tRS7h4TJ2Vt43Dp85v2A https://eager.io/app/b8tRS7h4TJ2Vt43Dp85v2A It's a rare application for which those differences matter. (NB: I don't know anything about eager.io... it might be important for them!) [0] https://blog.twitter.com/2010/announcing-snowflake https://blog.twitter.com/2010/announcing-snowflake

zackbloom 12y ago
It becomes a stylistic choice, but I can say we weren't happy with the experience the longer ids gave users. It made most of the url a random hash of characters, not anything significant. The URL is as much a part of the UX as anything else.
- al2o3cr 12y ago
  "The URL is as much a part of the UX as anything else." Given what we've seen from the browser vendors lately (hiding bits of the address bar, etc), I'd say there's a lot of momentum to disagree with that statement.
  - xahrepap 12y ago
    I think it depends on who your customer is / what your product is. When I'm developing against an api, I end up writing API calls in my terminal to test things. I prefer cleaner URLs for APIs.
- lmm 12y ago
  Is the difference between bkirwi's two examples really significant? The eager.io URL is still a mash of random characters. (FWIW I like seeing UUIDs in my URLs, because it tells me that the company on the other end has its shit together. That might be a bit programmer-specific though)
curun1r 12y ago
There's also impact at the data layer. Larger IDs make indexes get a lot bigger. Also, any article on UUIDs that mentions locality without even mentioning using type-1 UUIDs should be taken with a grain of salt. We looked at using UUIDs last year for a project in MySQL since we had good use cases for handling ID generation outside of the data tier. We originally prototyped using type-4 UUIDs, but found the locality problem made that a non-starter (updating indexes seemed to get exponentially slower when tables went over 10m rows). But switching to type-1 UUIDs made that problem go away. Still, we eventually chose not to use UUIDs since 128 bits made our indexes too large. At the DB level, we represented them as BINARY(16), but even with the pain that caused, our indexes were still too large. Perhaps it's just a MySQL thing (I didn't make that choice) but, from our testing, I'd be very wary of using 128-bit IDs and would probably choose something like Snowflake or other centralized ID generation service.
- ademarre 12y ago
  Sometimes you don't need to index all 16 bytes, and can get by with a prefix index.

by bkirwi 12y ago

zackbloom 12y ago

It becomes a stylistic choice, but I can say we weren't happy with the experience the longer ids gave users. It made most of the url a random hash of characters, not anything significant. The URL is as much a part of the UX as anything else.

al2o3cr 12y ago
"The URL is as much a part of the UX as anything else." Given what we've seen from the browser vendors lately (hiding bits of the address bar, etc), I'd say there's a lot of momentum to disagree with that statement.
- xahrepap 12y ago
  I think it depends on who your customer is / what your product is. When I'm developing against an api, I end up writing API calls in my terminal to test things. I prefer cleaner URLs for APIs.
lmm 12y ago
Is the difference between bkirwi's two examples really significant? The eager.io URL is still a mash of random characters. (FWIW I like seeing UUIDs in my URLs, because it tells me that the company on the other end has its shit together. That might be a bit programmer-specific though)

curun1r 12y ago

There's also impact at the data layer. Larger IDs make indexes get a lot bigger. Also, any article on UUIDs that mentions locality without even mentioning using type-1 UUIDs should be taken with a grain of salt. We looked at using UUIDs last year for a project in MySQL since we had good use cases for handling ID generation outside of the data tier. We originally prototyped using type-4 UUIDs, but found the locality problem made that a non-starter (updating indexes seemed to get exponentially slower when tables went over 10m rows). But switching to type-1 UUIDs made that problem go away. Still, we eventually chose not to use UUIDs since 128 bits made our indexes too large. At the DB level, we represented them as BINARY(16), but even with the pain that caused, our indexes were still too large. Perhaps it's just a MySQL thing (I didn't make that choice) but, from our testing, I'd be very wary of using 128-bit IDs and would probably choose something like Snowflake or other centralized ID generation service.

ademarre 12y ago
Sometimes you don't need to index all 16 bytes, and can get by with a prefix index.