Our great sponsors
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
In another comment I mentioned I use nanoid in my projects now. It has a default space of 64^21 and has an a page where you can play with key lengths and alphabet sizes and see the probability of collisions :
https://zelark.github.io/nano-id-cc/
At the default 64 character alphabet with a 21 character key length it would take ~41 million years in order to have a 1% probability of at least one collision if you generated 1000 ids per second.
See also: https://github.com/vladmihalcea/hypersistence-tsid (shorter than UUID)
ULIDs, https://github.com/ulid/spec, are also already in widespread use and are essentially the same idea as v7 UUIDs.
The spec as written on that page is confusing on that point, but the incrementing-counter-within-the-same-millisecond-behavior only happens if you explicitly specify a "monotonicFactory", https://github.com/ulid/javascript#monotonic-ulids. The default behavior (just using the ulid() function) doesn't do that, it generates a completely random value regardless of the millisecond value.