Proposal: replace NanoID with UUID

[yunge]

Hi,

Would you please consider replacing NanoID with UUID?

There are some points worth considering:

• Postgres & CockroachDB have native UUID type, so UUID columns can be processed in binary form and may be faster than text columns in some scenarios.
• For UUID, users can choose either time-based UUIDv7 or random-based UUIDv4, but NanoID is always randomly distributed.
• UUID PK can be easily integrated with different systems, such as financial system/CRM, etc. These systems are more likely to use UUID rather than NanoID.
• Many old systems already use UUID, if Cella uses UUID, there will be less resistance for people to adopt it.
• We don't need any libs to use UUID, even frontend can use window.crypto.randomUUID().
• Some libraries (short-uuid) can shorten the UUID, NanoID doesn't really have an advantage in this regard.

I believe that in the long run, compared with NanoID, Cella should adopt industrial standards such as UUID, which is more beneficial to its future development. After all, its target group is enterprise users.

Anyway, Cella's tech stack shows great taste, I sincerely hope it will be widely adopted, thanks.

[flipvh]

Thanks for the proposal @yunge ! Lets see if we can find some time to discuss this. I like the argument that its more of an industrial standard and also the native support sounds interesting to me.

@yunge I would love to know, would you be interested in using cella for a project if it uses UUID, and if so, what kind of project? We are still in prerelease so big breaking changes will still happen, but I hope to be ready for a first release soon. We are actively looking for contributors to help us get there faster.

[yunge]

Hi @flipvh ,

Now I'm trying to use Cella to develop a web site (app) about animation.

I chose it because I think Next.js is overly complex, too difficult to debug, and Next.js is not suitable for independent backend web services. As for SEO, I plan to prerender some pages, it would be great if Cella can help in this regard (SSR & SSG).

I have modified Cella's primary key code and changed varchar to UUID or bigint. But if you use UUIDs instead, it will save me a lot of trouble. For my new project, adjusting schema PK is relatively easy, so this is just a small problem for me. In fact, I'm more concerned about the overall development status of Cella.

But as I said above, UUID is more easily accepted by enterprise-level users. Because they have to consider the upgrade of various old systems, the collaboration of various systems, importing from various data sources to databases, and may need to switch the database to CockroachDB/YugabyteDB in the future. In these cases, UUID is a safer choice.

The only advantage of NanoId is that it is shorter, but UUID can also be shortened easily.

BTW, UUIDv7 has many advantages compared to UUIDv4 & NanoID, and Postgres will support it natively. Here is an interesting article: https://ardentperf.com/2024/02/03/uuid-benchmark-war/.

[flipvh]

I got it, great, thnks! Concerning SSR and SSG, we are waiting a bit for tanstack router, vite, hono to progress here. Each one of them is making big steps into improving SSR and SSG options, but I haven't had time to put it all together because it requires a deep dive. We are working on a blog section that will be built with honox: https://github.com/cellajs/cella/pull/11 You have explored honox already? Also, if we want to migrate to UUID, would you be interested in helping us with a PR or get involved in another way, for example to build support for SSR and/or SSG?

[yunge]

I'd love to try to make a UUID PR. But please note that I haven't tried converting varchar PK to UUID, maybe I can’t finish a full PR.

Another thing is how should UUID be generated? Postgres or JS. If UUID is generated by Postgres, it's easier to change to new version UUID without introducing any libraries. The price is that sometimes developers need to get the inserted id first then they can continue other operations. Generating UUID by JS will give developers more freedom in programming, but node & bun may not support the new version UUID for a long time, and Cella needs 3rd lib to support new version UUID.

As for SSR & SSG, since I am mainly developing the admin app at this stage, I have not thought too much about it. If I have new ideas in the future, I will open new issues, thanks.

[flipvh]

Ok thnks, before we continue, let me discuss it with the others first ok?

[yunge]

Got it, thanks.

[yunge]

Hi @flipvh ,

I've almost done a preliminary PR.

Besides, I have some new ideas on how the PK is generated, and I suggest that the UUID PK should be generated by Postgres as much as possible. This way is easier to use UUIDv7 in the future, and it's more suitable for Cella to cooperate with other systems and other languages.

For example, I believe that most IT systems will have AI services, and many services will be developed by Python, so it is a simpler and more consistent solution for Postgres to generate PK for all languages.

Anyway, we can discuss it again after I submit the PR.

[flipvh]

Hi @yunge we have come to conclusion that we will stay with nanoid for now. Uuid has some compatibility issues and its own complexities. I do still agree on your argumentation but for now i will close this issue. Thnks!

[sergeyprokhorenko]

@flipvh

Uuid has some compatibility issues and its own complexities.

What compatibility issues and complexities do you mean? Your answer can help eliminate it