换掉UUID,NanoID更快更安全!
往期热门文章:
1、新来的后端整的接口文档看着真不优雅! 2、如何优雅的写 Controller 层代码? 3、SpringBoot+Nacos+Kafka简单实现微服务流编排 4、几行代码,搞定 SpringBoot 接口恶意刷新和暴力请求! 5、程序员坐牢了,会被安排写代码吗?
文章来源:https://c1n.cn/WcAl0
前言
了解 NanoID 及其用法
局限性和未来重点
在将来……
前言
UUID 是软件开发中最常用的通用标识符之一。然而,在过去的几年里,其他的竞品挑战了它的存在。
其中,NanoID 是 UUID 的主要竞争对手之一。
因此,在本文中,我们将展开讨论 NanoID 的功能、它的亮点以及它的局限性,以便让我们更好地了解何时使用它。
了解 NanoID 及其用法
对于 JavaScript,生成 UUID 或 NanoID 都非常简单。它们都有对应的 NPM 包来帮助我们实现生成。
import { nanoid } from 'nanoid';
model.id = nanoid();
你是否知道 NanoID 每周的 NPM 下载量超过 1175.4 万,并且运行起来比 UUID 快 60%?
此外,NanoID 比 UUID 年轻了将近 7 年,而且它的 GitHub 星数已经比 UUID 多。
![](https://filescdn.proginn.com/114b3e70be5c097c6f072230be398707/35467405d8cdf1389ab3235880b7b9a5.webp)
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。
我们创建了一个高质量的技术交流群,与优秀的人在一起,自己也会优秀起来,赶紧点击加群,享受一起成长的快乐。
| 它既快速又紧凑
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 等库。
![](https://filescdn.proginn.com/7c785fd8a6c8ea419a9c54bfaff3488d/05baa22e497de62ba896e097eaa01f57.webp)
import { nanoid } from ‘@reduxjs/toolkit’
console.log(nanoid()) //‘dgPXxUz_6fWIQBD8XmiSy’
| 自定义字母
如下所示:
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://filescdn.proginn.com/a41ef428a36f2f65363cf9940f1f36a3/a89f5ad85afea1ddc6c8d2badbf523dd.webp)
https://www.npmjs.com/package/nanoid
上述基准测试显示了 NanoID 与其他主要 id 生成器相比的性能:使用默认字母表每秒可生成超过 220 万个唯一 ID,使用自定义字母表每秒可生成超过 180 万个唯一 ID。
根据我使用 UUID 和 NanoID 的经验,考虑到它的小尺寸、URL 友好性、安全性和速度,我建议在任何未来的项目中使用 NanoID 而不是 UUID。
因此,我邀请您在下一个项目中试用 NanoID,并在评论部分与其他人分享您的想法。
往期热门文章:
1、MySQL 暴跌! 2、超越 Xshell!号称下一代 Terminal 终端神器,用完爱不释手! 3、IDEA 官宣全新默认 UI,太震撼了!! 4、让你直呼「卧槽」的 GitHub 项目! 5、Kafka又笨又重,为啥不选Redis? 6、50多个高频免费 API 接口分享 7、IDEA公司再发新神器!超越 VS Code 骚操作! 8、我怀疑这是 IDEA 的 BUG,但是我翻遍全网没找到证据! 9、Spring MVC 中的 Controller 是线程安全的吗? 10、Gitee 倒下了???