Library discovery

You Might Not Need UUID V4 for Generating Random Identifiers

For every decision be sure to understand why you are taking it as you have maybe another smart way to achieve the same goal.

For many applications you might need to generate some kind of unique identifier to be able to get a reference to specific content.

It can be for various scenarios, a frontend listing, a backend database row identifier, or whatever, you just need some random hash…

For achieving this goal, we have two techniques and kinds of developers:

1. The beginner. It just tries a self-made algorithm that picks letters and numbers based on some pseudorandom function results such as Math.random or maybe using a hexadecimal representation of a timestamp.
2. The average developer. Which uses some kind of battle-tested ID algorithm, such as the famous UUID v4, which allows generating a string of 36 characters (including 4 dash chars).

Here is a random UUID I just generated 123e4567-e89b-12d3-a456–556642440000

Well, while the first one can work well on small apps. It has many cons that can result in collisions of ID due to the simplicity of the algorithm.

The second on the other hand is well secured about collision but is damn long: 36 characters!

The next parts of the article are going to make you think about the central question of that article: What is your use case and why do you need an identifier?

What are the requirements for a good identifier?

• Being Fast to generate, that way you can generate tons of ID at a small cost.
• Being Uniform, to prevent brute-forcing in case of sensitive data such as voucher token or prepaid token.
• Being Secure, to avoid collisions that would remove the “unique” character of the identifier.
• Being Unpredictable, in case of security again. But sometimes you want it to be… Like for data integrity check.
• It could also be URL-friendly, to use it such as an email validation…