Can I switch ORM's?

Get Help and Help Others
1

I’m getting quite frustrated with Prisma…

If I wanted to switch ORMs, maybe to TypeORM ?

Would this be a suicide mission, or is the choice of ORM not as important as the usage of an ORM ?

Thanks for Redwood - the only place to start

Al;

TypeORM’s list of features is substantial - foremost in my feelings right now is migration up() & down() and no mention of reset() whenever it feels like it…

2

You’re a brave soul! But services (currently the only things that use Prisma within an app) are JS files like any other, so if you import a different lib at the top there’s nothing stopping you from using that instead!

You may have surprises with some of the CLI tools (starting the dev server will usually generate the Prisma client libraries) but I believe we have a couple of checks in there to make sure we don’t blow up if something is missing.

Let us know how it goes!

3

It definitely will work, the question is whether it’s going to be worth the time to make it work and how much technical debt it will add over time.

When I tried switching out Postgres and Prisma for Fauna it ended up working but translating from FQL to something that made sense to a Redwood project ended up being more trouble than it was worth.

If you stick with Postgres that should help. I’m not sure what TypeORM’s support for GraphQL is like, but if there’s already a lot of TypeORM projects using GraphQL it might turn out okay.

Some examples:

1 Like
4

Yeah for sure the main question will be of drifting away from the reference standard.

I’ve worked around my current issues w/Prisma so I’m ok for now…

thanks for answering, it was more a question of frustration than a real change of course

5

What issues have you experienced with prisma?

6

#1 - cross schema keys were halting any prisma commands

#2 - no up & down in migrations, one way only - with always the fear of a reset

I removed the cross schema keys and create new public.users records when auth.users creation is done and I have the new record id

I drink a little more to calm the fear :smiley:

7

Mirroring only the user data you need in public via a trigger that uses the auth schema in Supabase is the preferred and better approach.

You don’t need to accidentally expose the hashed password or raw metadata or last login from auth.users. You would need to have some logic and rules in the User graphql resolves to protect against accidentally leaking that. So, this is far better.

As for:

#2 - no up & down in migrations, one way only - with always the fear of a reset

I agree, a rollback would be nice. But even in the Rails world where migrations have been used for a long time, the down case isn’t always programmatically reversible.

You have to write up and down steps.

This is the same for GitHub - amacneil/dbmate: 🚀 A lightweight, framework-agnostic database migration tool..

So, while I also would like that feature, I do know if I make a mistake – and of course I am always just running migrations in dev (and using the deploys or pushes to staging or prod), then I can in fact delete the migration files and do a proper reset.

8

" Mirroring only the user data you need in public via a trigger that uses the auth schema in Supabase is the preferred and better approach."

Yes, and that is what I started with - based on the suggestions on the supabase site – but they added a cross-schema foreign key from the public.users into the auth.users and that is where Prisma errored and quits whatever it’s doing