We Chose NanoIDs for PlanetScale's API

#1

Post by maltee » Wed, Mar 30, 2022, 3:41 PM UTC

We Chose NanoIDs for PlanetScale's API
planetscale.com

Re: We Chose NanoIDs for PlanetScale's API

#2

Post by HippoBaro » Wed, Mar 30, 2022, 4:48 PM UTC

So UUIDs were the perfect solution except that, if a user double-click a url with a UUID in it, it won’t select all of it.

Can’t you just… remove the hyphens? UUIDs are just arrays of bytes, the hyphens are not part of the data.

Instead, they use a less popular, less supported, more collision-prone ID format.

Re: We Chose NanoIDs for PlanetScale's API

#3

Post by jamesboehmer » Wed, Mar 30, 2022, 4:59 PM UTC

HippoBaro wrote: post #2

So UUIDs were the perfect solution except that, if a user double-click a url with a UUID in it, it won’t select all of it. Can’t you just… remove the hyphens? UUIDs are just arrays of bytes, the hyphens are not part of the data. Instead, they use a less popular, less supported, more collision-prone ID format.

You can also base62-encode the UUID's underlying integer and you get a short, URL-friendly identifier, while maintaining the power and uniformity of UUID. The claim with nanoID is that it's twice as fast as UUID, but I'm not sure how impactful that is given my services all spent orders of magnitude more time in I/O wait for a database after any UUID functionality.

Re: We Chose NanoIDs for PlanetScale's API

#4

Post by [deleted] » Wed, Mar 30, 2022, 5:10 PM UTC

[deleted]

Re: We Chose NanoIDs for PlanetScale's API

#5

Post by maxekman » Wed, Mar 30, 2022, 5:58 PM UTC

HippoBaro wrote: post #2

So UUIDs were the perfect solution except that, if a user double-click a url with a UUID in it, it won’t select all of it. Can’t you just… remove the hyphens? UUIDs are just arrays of bytes, the hyphens are not part of the data. Instead, they use a less popular, less supported, more collision-prone ID format.

Exactly, I’m surprised this would gain traction. UUIDs are much smaller when packed into bytes.

Notion seems to use UUIDs without hyphens in their links, and it works just fine.

Re: We Chose NanoIDs for PlanetScale's API

#6

Post by greatgib » Wed, Mar 30, 2022, 11:25 PM UTC

HippoBaro wrote: post #2

So UUIDs were the perfect solution except that, if a user double-click a url with a UUID in it, it won’t select all of it. Can’t you just… remove the hyphens? UUIDs are just arrays of bytes, the hyphens are not part of the data. Instead, they use a less popular, less supported, more collision-prone ID format.

Nanoid are really great. It is a smarter uuid4 with variable size and alphabet. It is also a lot faster to generate.

See that: https://blog.bitsrc.io/why-is-nanoid-replacing-uuid-1b5100e6...

By definition, if you base62 or base64 your uuid4 it will be longer (30%?).

This generate directly in the final encoding so it is a lot shorter. Based on the simulator calculation, you just need 24 chars to be equivalent to an uuid4 that is 35 chars.

But being able to determine the length of the resulting id is one of the greatest feature. Did it never happened to you the case that you would like a shorter uuid4 and think that you can just truncate it? Not realizing that some parts of the uuid have a special meaning and are not random...

Re: We Chose NanoIDs for PlanetScale's API

#7

Post by atonse » Thu, Mar 31, 2022, 12:08 AM UTC

We use crypto.strong_rand_bytes in elixir and Base.encode32, strip padding.

It works like a charm. Length decided by setting number of random bytes.

Re: We Chose NanoIDs for PlanetScale's API

#8

Post by jmillikin » Thu, Mar 31, 2022, 1:34 AM UTC

The post dismisses UUIDs because their default formatting uses hyphens and hex encoding (base16), but as other comments mention you can get UUIDs to be much shorter by encoding them in a different base. If you want to guarantee URL-safety and selection via double-click, use base62 (26 lower-case, 26 upper-case, 10 digits).

  uuid  : c5831108-6f95-442a-b2b0-3c62dc0abdd1
  base62: 60hNvkHrZykznfLaESuDBp

This format also lets you attach a prefix with '_' so you can keep track of the semantic type of each ID. This pattern is widely used by the Stripe API, and I've grown quite fond of it (so much easier to grep).

  url: api.planetscale.com/v1/deploy-requests/deploy_60hNvkHrZykznfLaESuDBp

Additionally, within an in-memory value or a database, you probably want to store the decoded form of any ID. The value "deploy_60hNvkHrZykznfLaESuDBp" is 29 bytes long, but could be represented by `type DeployID byte[16]` for ~50% space savings and stronger type validation.