Hashids - What Are They, And Why Should We Use Them?

[HttpGet]
public IActionResult Get([FromRoute] string id)
{
    int[] intId = _hashids.Decode(id);
    if (intId.Length == 0) return NotFound();
    User user = _userService.GetUser(intId[0]);
    if (user is null) return NotFound();
    return Ok(user);
}

The API method above accepts an argument ID of type string. The Hashids library provides a ready-to-use implementation with a Decode function that converts a string identifier back to its original sequential ID/number, derived from the Encode function. You can now efficiently retrieve the record from your data warehouse where the data is still stored using its' original sequential identifier.

Suppose your dataset is a list of users from the database, represented by the following list structure in C#:

private List<User> Users = new List<User>{
    new User { Id = 1, FullName = "Stefan Djokic" },
    new User { Id = 2, FullName = "Ricky Sellers"},
    new User { Id = 3, FullName = "Tasnim Shaffer"}
};

If you call the example API above in Postman with a hashid (string ID) of "W8ZwkZY" (derived from Id:1 in this case), the result is the user with ID = 1. To recap, this is because the Hashid derives from, and can be converted back to, its original sequential identifier.

This has enabled you to simultaneously take advantage of the best features of Sequential IDs and GUIDs. You've minimized your security risk by exposing opaque identifiers to the public (which cannot be easily guessed due to the hashing algorithm) while maintaining performance when storing and searching in the database.

How does it work?

As far as performance is concerned, the general best practice is that these IDs should not be persisted anywhere but should be calculated every time. One of the main reasons for this is that it enables you to change/rotate the SALT key.

Therefore, most uses of Hashids will require the calculation to be done two times for each request; one calculation is encoding (int is converted to string), and the other is decoding (string is converted back to int). The encoding and decoding execution times (for a 7 characters id) are shown in the following figure (using the venerable BenchmarkDotNet project).

You can see that the encoding function takes approximately 850ns per execution, which is quite fast. The decoding time is a bit longer (not unexpected), taking approximately 1400ns (i.e., 0.0014ms).

Note
Functions do not return a single value of a particular type, but return a string - encoding returns int []. There is a lot of room for optimization here if someone really needs it.

Another note
Purely out of curiosity, it is tested on 1 million values, although this is far from a realistic or practical use case, and the total duration of the process was slightly less than 900ms.

Conclusion

Hashids are an effective approach for small to medium-scale applications that don't require more complicated strategies like Snowflake IDs (e.g., combining different metadata such as timestamps, shard IDs, etc.). And many industry solutions such as GraphQL have embraced it due to the benefits outlined here.

Fun fact: YouTube uses 11 characters to generate an ID for each of the videos. This number of characters allows the existence of 73,786,976,293,838,206,464 video clips, which is equivalent to every human being on the planet uploading video every minute for the next 18,000 years. Just WOW.

Github repository of the entire code: https://github.com/StefanTheCode/HashIds

HashIds library used in the text is hashids.net.