Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more! Learn more →
Nanoid Alternatives
Similar projects and alternatives to nanoid
-
-
snowflake
Snowflake is a network service for generating unique ID numbers at high scale with some simple guarantees.
-
Appwrite
Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!
-
typedorm
Strongly typed ORM for DynamoDB - Built with the single-table-design pattern in mind.
-
-
-
-
-
Klotho
AWS Cloud-aware infrastructure-from-code toolbox [NEW]. Build cloud backends with Infrastructure-from-Code (IfC), a revolutionary technique for generating and updating cloud infrastructure. Try IfC with AWS and Klotho now (Now open-source)
-
-
-
nanostores
A tiny (258 bytes) state manager for React/RN/Preact/Vue/Svelte with many atomic tree-shakable stores
-
-
-
-
Nodemon.io
Monitor for any changes in your node.js application and automatically restart the server - perfect for development
-
-
-
Electron
:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS
-
-
-
InfluxDB
Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.
nanoid reviews and mentions
-
Logging - correlationId - headers - how?
In middleware.ts I can generate a cookie very easily - doing a check to see if the correlationId cookie is set - if it is, use it, if not, use something like nanoid to generated a unique ID.
-
Build a URL shortener using React and Node/Express in Typescript
Every time /shorten-url is called, nanoid generates a URL-friendly key. Then, the key and a long URL are stored in the mapping for URL redirection. And, the key is stored in a SET object to check if the generated key is duplicated. If the key is duplicated, the error will be thrown.
-
We Chose NanoIDs for PlanetScale’s API
Just look out for this issue:
The seed for an LFSR is just the starting value for its cycle; it can be any value in the cycle, and it's public anyway in that you can think of each output of an LFSR as the "seed" for the next output.
But in the case of the "taps", yes, you would want to treat those as a secret if you didn't want someone to predict the next value in the cycle. An LFSR by itself might not be a complete solution for IDs for public consumption, but it does neatly solve the need for pseudo-random non-colliding IDs. Whereas NanoIDs are able to generate values with a ~1% probability of collision over some time period, LFSRs can generate values with a 0% probability of collision over their entire bit space. (And they're composable!)
It looks like NanoIDs are entirely random values reduced to a specific alphabet (https://github.com/ai/nanoid/blob/main/index.js) -- which is approximately similar to:
tr -dc _A-Z-a-z-0-9 < /dev/urandom | tr -d '/+oO0lLiI1\n\r' | head -c $num_chars
We should consider the following properties when evaluating ID formats and generation algorithms:
1. Private: you shouldn’t be able to gain information about the system using the IDs from an ID alone. E.g. document enumeration attacks like what happened with Parker (https://www.wired.com/story/parler-hack-data-public-posts-im...)
2. B-tree/cache friendly: newly created IDs should all exist in a narrow range of values. This is helpful for databases.
3. Stateless: ideally you shouldn’t need to know the current state of the system to create a new ID.
4. Human-friendly: IDs should be easily dictated, copied, pasted, etc. This means they should be encodable as text that is short and does not include ambiguous characters.
Some of the these properties are in conflict. Statelessness is achieved by randomly generating long IDs, but people don’t like reading or typing long IDs.
Different use cases will need these properties in varying amounts. If you don’t intend to expose the IDs to users, (4) doesn’t matter. Just use long, randomly generated byte strings prepended with the date. Most databases have a UUID type that fits the bill.
If users are going to be working with IDs, that’s more complicated. If not every document has a user-facing ID, just go with the non-user-facing ID like before, and generate a shorter, random, stateful ID as needed.
I don’t think NanoID prepends the date, which means it won’t be efficient when inserting large numbers of IDs into a large index. They also default to using ambiguous characters like 1 and I and l. Also no error code. But they are shorter than UUIDs. So it doesn’t meet property (2), and it only kind of meets property (4). NanoIDs are random, so you’re probably safe from enumeration attacks (1). NanoIDs mostly leave Statelessness as a decision for the user. They have a nice tool that helps estimate how long the IDs should be (https://zelark.github.io/nano-id-cc/) for a given collision resistance.
I think we can do better overall. Bitcoin uses a good encoding scheme called base58check. It generates fairly short IDs and uses an error code at the end. I think it could be refined for non-bitcoin purposes, but it’s already pretty good.
A 128-bit value like the ASCII string “hackernewstestid” is encoded as “Dtajqjz5pptWcmGrNcwBx7”. It’s about 2/3 the size of the equivalent UUID, even with the (unnecessarily long for this use case) error checking code.
I’d like to see a small ID standard that meets the above requirements and has a choice for either stateless and long or stateful and short. Maybe another choice for secure random or insecure. But all options would have binary form and a text form. The text form would use something similar to base58check, but probably with a smaller (or user-determined) length for the error code.
-
Creating Image Optimizer With Rio
Rio Docs Zod Github Nanoid Github Sharp Github
-
Moving Away from UUIDs
I really like https://github.com/ai/nanoid which is available for a wide range of programming languages. It creates short, random, and URL-safe IDs.
-
I've cloned a simple VScode using Tauri and ReactJS
nanoid - unique string ID generator
-
rs-nanoid: efficient NanoID generation in Rust
NanoID is originally a JS project.
-
A note from our sponsor - Appwrite
appwrite.io | 31 Jan 2023
Stats
ai/nanoid is an open source project licensed under MIT License which is an OSI approved license.