NanoID 比 UUID 更好用
原文地址:Why is NanoID Replacing UUID?原文作者:Charuka Herath
本文永久連結:https://github.com/xitu/gold-miner/blob/master/article/2021/why-is-nanoid-replacing-uuid.md譯者:霜羽 Hoarfroster
UUID 是軟體開發中最常用的通用識別符號之一。然而,在過去的幾年裡,其他的競品挑戰了它的存在。
其中,NanoID 是 UUID 的主要競爭對手之一。
因此,在本文中,我們將展開討論 NanoID 的功能、它的亮點以及它的侷限性,以便讓我們更好地瞭解何時使用它。
# 瞭解 NanoID 及其用法
對於 JavaScript,生成 UUID 或 NanoID 都非常簡單。它們都有對應的 NPM 包來幫助我們實現生成。
我們所需要做的就是執行 npm i nanoid 命令安裝 NanoID NPM 庫 並在我們的專案中使用它:
import { nanoid } from 'nanoid';
model.id = nanoid();
“你是否知道 NanoID 每週的 NPM 下載量超過 1175.4 萬,並且執行起來比 UUID 快 60%?”
此外,NanoID 比 UUID 年輕了將近 7 年,而且它的 GitHub 星數已經比 UUID 多。
下圖顯示了這兩個之間的 npm 趨勢比較,我們可以看到 NanoID 的上升趨勢與 UUID 的平坦進展有強烈的對比。
https://www.npmtrends.com/nanoid-vs-uuid
我希望這些數字已經說服你去嘗試 NanoID。
但是,這兩者之間的主要區別很簡單。它歸結為鍵使用的字母表。
由於 NanoID 使用比 UUID 更大的字母表,因此較短的 ID 可以用於與較長的 UUID 相同的目的。
# NanoID 只有 108 個位元組那麼大
與 UUID 不同,NanoID 的大小要小 4.5 倍,並且沒有任何依賴關係。此外,大小限制已用於將大小從另外 35% 減小。
大小減少直接影響資料的大小。例如,使用 NanoID 的物件小而緊湊,能夠用於資料傳輸和儲存。隨著應用程式的增長,這些數字變得明顯起來。
# 更安全
在大多數隨機生成器中,它們使用不安全的 Math.random()。但是,NanoID 使用 crypto module 和 Web Crypto API,意味著 NanoID 更安全。
此外,NanoID 在 ID 生成器的實現過程中使用了自己的演算法,稱為 統一演算法,而不是使用“隨機 % 字母表” random % alphabet。
我們建立了一個高質量的技術交流群,與優秀的人在一起,自己也會優秀起來,趕緊點選加群,享受一起成長的快樂。
# 它既快速又緊湊
NanoID 比 UUID 快 60%。與 UUID 字母表中的 36 個字元不同,NanoID 只有 21 個字元。
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz-
此外,NanoID 支援 14 種不同的程式語言,它們分別是:
C#、C++、Clojure 和 ClojureScript、Crystal、Dart & Flutter、Deno、Go、Elixir、Haskell、Janet、Java、Nim、Perl、PHP、帶字典的 Python、Ruby、Rust、Swift
# 相容性
它還支援 PouchDB、CouchDB WebWorkers、Rollup 以及 React 和 Reach-Native 等庫。
我們可以使用 npx nanoid 在終端中獲得唯一 ID。在 JavaScript 中使用 NanoID 唯一的要求是要先安裝 NodeJS。
此外,我們還可以在 Redux toolkit 中找到 NanoID,並將其用於其他用例,如下所示;
import { nanoid } from ‘@reduxjs/toolkit’
console.log(nanoid()) //‘dgPXxUz_6fWIQBD8XmiSy’
# 自定義字母
NanoID 的另一個現有功能是它允許開發人員使用自定義字母表。我們可以更改文字或 id 的大小,如下所示:
import { customAlphabet } from 'nanoid';
const nanoid = customAlphabet('ABCDEF1234567890', 12);
model.id = nanoid();
在上面的示例中,我將自定義字母表定義為 ABCDEF1234567890,並將 Id 的大小定義為 12。
# 沒有第三方依賴
由於 NanoID 不依賴任何第三方依賴,隨著時間的推移,它能夠變得更加穩定自治。
從長遠來看,這有利於優化包的大小,並使其不太容易出現依賴項帶來的問題。
# 侷限性和未來重點
根據 StackOverflow 中的許多專家意見,使用 NanoID 沒有明顯的缺點或限制。
非人類可讀是許多開發人員在 NanoID 中看到的主要缺點,因為它使除錯變得更加困難。但是,與 UUID 相比,NanoID 更短且可讀。
另外,如果你使用 NanoID 作為表的主鍵,如果你使用相同的列作為聚集索引也會出現問題。這是因為 NanoID 不是連續的。
# 在將來……
NanoID 正逐漸成為 JavaScript 最受歡迎的唯一 id 生成器,大多數開發人員更喜歡選擇它而不是更喜歡 UUID。
來源:https://www.npmjs.com/package/nanoid
上述基準測試顯示了 NanoID 與其他主要 id 生成器相比的效能。
“使用預設字母表每秒可生成超過 220 萬個唯一 ID,使用自定義字母表每秒可生成超過 180 萬個唯一 ID。”
根據我使用 UUID 和 NanoID 的經驗,考慮到它的小尺寸、URL 友好性、安全性和速度,我建議在任何未來的專案中使用 NanoID 而不是 UUID。
因此,我邀請您在下一個專案中試用 NanoID,並在評論部分與其他人分享您的想法。