Use `uuid` datatype for Drizzle/Postgres `user_id`

[akoskovacs]

:tada: First of all, thanks for trying to bring Ruby on Rails DX to the JavaScript ecosystem!

Why

Currently, for some reason Auth.js prescribes text for the user id, while they are using them as uuid. This is a bit of a problem from a DB standpoint.

What

This change is scoped only on the Postgres / Drizzle parts, since that's what I am familiar with. The best would be to change every DB datatype to UUIDs or big integers (Auth.js doesn't like that, unfortunately) for the user id.

Drizzle will transparently convert the values to string, so no change is required on the other sides.

Other DB recommenedations out of scope

These are out-of-scope for this PR, but I think we should think about it in the long term...

Timestamps for all models

It is best to have created_at / updated_at for all models, since they are pretty hard to add after the fact. Users can later remove them. created_at can be always auto-generated at insert (at least for Postgres).

Consolidate naming scheme

Auth.js people has weird naming schemes:

• All Auth.js tables use the singular form, like user, account, etc. in the database. The code still references them in the plural form. A good framework has to be consistent. This behaviour is overrideable, but not easy.
• They also mix snake_case and camelBack in the DB depending on whether the column is an oauth data or Auth.js's own. Users don't care, they need cleanliness. This is also not trivial to fix.

Use bigger ids

bigserial would be better to use in the long-run for database primary keys, engines can cope with them and aren't that big of deal for storage. A must have for large tables.

Linked accounts

It would be great to explicitly include information about the linked account. user.name can actually mean multiple things depending which provider did the user use first. Usually, it's the full name, but it can also mean the login name. It would be far better to save the github_login_name, etc. explicitly, so it can be used later for integrations.

Alternatively, this could be saved into a different table, too.

Template-based generation

As I created the PR, I have noticed that the file generation is basically done as string concatenation. Although, this is trivial, it is error prone. It would be far easier to create templates, in a templating language, where the substitutions can occur.

Idempotent generation

Based on the previous point, right now running the generation will append a new configuration to the generated files. Rails actually will ask the user what to do in a situation like this.

Reduce options

Just looking through the code, it was hard to follow which thing generated what. There are already too many options. It would be far better to start with a smaller subset of technologies first. Make those few well-tested and feature complete (like tRPC + Drizzle + Postgres). And only then include more things. The ecosystem needs a lot of consolidation already.

Sorry, for making this too long, just some toughts. :smile: I hope, this project will succeed! :1st_place_medal: