Live data from Hacker News

We chose NanoIDs for PlanetScale’s API

planetscale.com

21–30 of 54 posts

Re: We chose NanoIDs for PlanetScale’s API

#21
post #19

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…

Aren't INTs cumbersome in a distributed database? For example If I have two servers running one database, now I have to keep the autoincrement in sync between both before I generate a new one. That's why UUIDs are generally used here if I understand correctly.

Re: We chose NanoIDs for PlanetScale’s API

#22
Can 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 what he's alluding to? Thanks in advance.

Re: We chose NanoIDs for PlanetScale’s API

#23
post #17

Don't expose your internal IDs, expose some identifier specifically made to be exposed.

The post covers this:

> 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

#24

Can 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…

Yes, you must match your RNG values to an integer multiple of your alphabet size, or there will be bias on modulo. Filter, smear bits, etc.

More explanation here: https://stackoverflow.com/questions/10984974/why-do-people-s...

Re: We chose NanoIDs for PlanetScale’s API

#26
post #17

Don't expose your internal IDs, expose some identifier specifically made to be exposed.

I assume you mean internal IDs == primary keys in your database. If that's the case, and if your primary keys are UUIDv4's, ULIDs, KSUIDs, Cuids or similar... then why not? There are a lot of benefits, such as simpler SQL queries in your backend. You can also merge data from different databases into one as collissions are highly unlikely, which is not possible with numeric IDs.

Re: We chose NanoIDs for PlanetScale’s API

#28
post #2

the 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)

Re: We chose NanoIDs for PlanetScale’s API

#29
post #28
post #2

the 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)

I deeply appreciate the seemingly limitless amount of help you provide here, and hope you and yours are happy and healthy
Post reply on HN