Why using tRPC and Drizzle in Spartan stack ?

[alcaidio]

Why use tRPC and Drizzle in the Spartan stack when Supabase already provides type generation through database introspection? Supabase’s introspection feature generates types from the database schema (as shown here), so I'm curious what additional benefits tRPC and Drizzle bring to the table, particularly regarding type safety and development experience.

[alcaidio]

No one has any answers? :)

[goetzrobin]

Hey there! Sorry, this must have slipped through. The idea is that while Supabase is great and what I believe the easiest way to get started with a production ready Postgres DB, I didn't want the stack have vendor lock-in from the beginning. With drizzle and tRPC you can use any DB that drizzle supports, e.g. Postgres or MySQL or Turso,...

Also, if you use the supabase js client directly from your frontend you actually use PostgREST and are "calling" the DB straight from the frontend.

I hope that clarifies the decision a little more

[alcaidio]

So if I understand correctly, there's no point in using Trpc or Drizzle when using supabase?

Trpc or Drizzle are useful when you're managing the calls to your database yourself, in order to have client- and server-side typing.

But supabase could suffice on its own.

[goetzrobin]

So you can run completely on supabase if you want to. tRPC is actually a way to make API calls type safe, e.g. you wanna do logic on your server and not directly interact with supabase. drizzle would be directly replaced with the supabase client