: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:
:tada: First of all, thanks for trying to bring Ruby on Rails DX to the JavaScript ecosystem!
Why
Currently, for some reason
Auth.jsprescribestextfor the user id, while they are using them asuuid. This is a bit of a problem from a DB standpoint.What
This change is scoped only on the
Postgres/Drizzleparts, since that's what I am familiar with. The best would be to change every DB datatype to UUIDs or big integers (Auth.jsdoesn'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
Timestamps for all models
It is best to have
created_at/updated_atfor all models, since they are pretty hard to add after the fact. Users can later remove them.created_atcan be always auto-generated at insert (at least for Postgres).Consolidate naming scheme
Auth.jspeople has weird naming schemes:Auth.jstables use the singular form, likeuser,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.snake_caseandcamelBackin the DB depending on whether the column is anoauthdata orAuth.js's own. Users don't care, they need cleanliness. This is also not trivial to fix.Use bigger ids
bigserialwould 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.namecan 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 thegithub_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.
Railsactually 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: