I wonder how this might compare to just storing regular autoincrementing ints in the database, and converting to/from hashids ( https://hashids.org/ ) at the edge. It eliminates the collision concern and stores more compactly at the cost of a tiny amount of encode/decode when processing requests. You’d want to push it down as close to the database layer as possible to avoid inadvertent int ID leaks; I added native ha…
We chose NanoIDs for PlanetScale’s API
21–30 of 54 posts
Re: We chose NanoIDs for PlanetScale’s API
#22If random is picked such that it's in the range of alphabet (i.e. 0 to 25), then the bias should not exist, right? Is that what he's alluding to? Thanks in advance.
Re: We chose NanoIDs for PlanetScale’s API
#23Don't expose your internal IDs, expose some identifier specifically made to be exposed.
> Our API is a Ruby on Rails application. For all public-facing models, we have added a `public_id` column to our database. We still use standard auto-incrementing BigInts for our primary key. The `public_id` is only used as an external identifier.
Re: We chose NanoIDs for PlanetScale’s API
#24Can someone clarify this statement from the original nanoID site ( https://github.com/ai/nanoid ) for me? "random % alphabet is a popular mistake to make when coding an ID generator. The distribution will not be even; there will be a lower chance for some symbols to appear compared to others." If random is picked such that it's in the range of alphabet (i.e. 0 to 25), then the bias should not exist, right? Is that wh…
More explanation here: https://stackoverflow.com/questions/10984974/why-do-people-s...
Re: We chose NanoIDs for PlanetScale’s API
#25Re: We chose NanoIDs for PlanetScale’s API
#26Don't expose your internal IDs, expose some identifier specifically made to be exposed.
Re: We chose NanoIDs for PlanetScale’s API
#27For immutable data, that sort of identifier has an added benefit of deduping data.
For mutable data, just take a hash of a cryptographically secure random function.
Re: We chose NanoIDs for PlanetScale’s API
#28the previous submission had good points: https://news.ycombinator.com/item?id=30856703
We Chose NanoIDs for PlanetScale's API - https://news.ycombinator.com/item?id=30856703 - March 2022 (6 comments)
Related:
Nano ID: A tiny, secure URL-friendly unique string ID generator for JavaScript - https://news.ycombinator.com/item?id=15225158 - Sept 2017 (78 comments)
Re: We chose NanoIDs for PlanetScale’s API
#29the previous submission had good points: https://news.ycombinator.com/item?id=30856703
Thanks! Macroexpanded: We Chose NanoIDs for PlanetScale's API - https://news.ycombinator.com/item?id=30856703 - March 2022 (6 comments) Related: Nano ID: A tiny, secure URL-friendly unique string ID generator for JavaScript - https://news.ycombinator.com/item?id=15225158 - Sept 2017 (78 comments)