Typeid Alternatives

typeid reviews and mentions

• Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs
  1 project | news.ycombinator.com | 26 Aug 2024
  1 project | news.ycombinator.com | 12 Apr 2024
• TypeID: Type-safe, K-sortable, globally unique identifiers
  1 project | news.ycombinator.com | 28 Jul 2024
• ULID: Like UUID but Sortable
  8 projects | news.ycombinator.com | 13 Jul 2024

  I went to add your UUID variant to my notes and found https://github.com/jetify-com/typeid

  The main differences:

  - typeid allows up to a 63 byte prefix

• TypeID-JS: Type Safe, K-Sortable Unique IDs for Javascript
  4 projects | dev.to | 9 Jul 2024

  Since we first announced TypeID last year, we've seen significant adoption and interest from the community, with 23 different language clients contributed by the community and 90,000 weekly NPM downloads of our Typescript Implementation.

• You'll regret using natural keys
  5 projects | news.ycombinator.com | 5 Jun 2024

  I'd recommend using Crockford base 32 [0] to encode the bytes. It makes the text more human friendly by eliminating case sensitivity, removing similar/ambiguous letters, and preventing accidental profanity.

  And in most cases I think you're also better off just using a uuid and encoding its bytes as base 32, in which case you're basically doing type id's [1]. If the "slug" portion of the id actually encodes a uuid, then it gives you the option to store it in your database using an appropriate uuid type. This will make your database much happier than using long string PK's.

  0: https://www.crockford.com/base32.html

  1: https://github.com/jetify-com/typeid

• ULIDs and Primary Keys
  1 project | news.ycombinator.com | 12 Apr 2024

  I’ve seen this sort of design referred to as “typed IDs”: https://github.com/jetify-com/typeid

  Doesn’t use the crockford encoding, but does is another one that minimises confusables.

• The UX of UUIDs
  10 projects | news.ycombinator.com | 11 Apr 2024

  https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d...

  But there is always TypeID in the meantime which uses UUIDv7 under the hood: https://github.com/jetify-com/typeid

  Either way, I am in favor of prefixing and using alternative encodings, but it will need some time to figure out the best route. In the mean time, there are so many alternatives. TypeID, NanoID, ULID, etc. I even made my own quick one just for giggles: https://github.com/daegalus/snowflakes

• Adding type safety to object IDs in TypeScript
  3 projects | news.ycombinator.com | 30 Jan 2024

  If you want a type-prefixed UUIDv7 type, I can wholeheartedly recommend TypeID-JS: https://github.com/jetpack-io/typeid-js

  Also available for a whole bunch of other languages: https://github.com/jetpack-io/typeid

  UUIDv7 is UUIDv4-compatible (i.e. you can put a v7 UUID anywhere a v4 UUID would go, like in Postgres's UUID datatype) and is time-series sortable, so you don't lose that nice lil' benefit of auto-incrementing IDs.

  And if you use something like TypeORM to define your entities, you can use a Transformer to save as plain UUIDv7 in the DB (so you can use UUID datatypes, not strings), but deal with them as type-prefixed strings everywhere else:

  ```

• You Don't Need UUID
  13 projects | news.ycombinator.com | 11 Sep 2023

  IMO, a good middleground is using schemes like TypeID[0], ulid[1], or KSUID[2] that provides a more compact and readable (base32) representation and provides better database locality (K-sortable).

  [0] https://github.com/jetpack-io/typeid

• A note from our sponsor - InfluxDB
  www.influxdata.com | 9 Sep 2024

  InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards. Learn more →