#trpc seems like a reasonable alternative

1 messages · Page 1 of 1 (latest)

amber forge
#

my view so far (and i'm still learning) is that, let's say you're using Prisma, you can still get type safety directly from the Prisma client, adding tRPC to the mix adds various benefits.

For example, you might be interacting with data from different sources and using multiple ORM's, Prisma just being one of them. tRPC provides a nice way to make one type-safe unified API.

You can also validate your inputs per tRPC function using something like zod.

I find the ability to pass authentication requirements pretty valuable. So when using something like NextAuth, tRPC allows for an easy way to validate the session for each request with private procedures.

There's also the middleware it exposes so you can modify a request at various stages of the request.

I haven't used server actions yet, but it seems like it would make sense to use a tRPC endpoint inside of a server action, so I'm not sure I view it as an alternative. It appears that server actions (which only work on forms) are providing a server-side alternative to form submitting, because without it you'd need to have your forms in a client component (because the onSubmit event handler is client side only).

So I think they just serve different purposes.

fierce ivy
#

server component can call native database functions and get full type safety; no need of a type layer in between such as trpc. trpc's typesafety shines when it's used as a way for the browser to fetch data, since typesafety is lost in the network boundary, so if you use client-side fetching in the app router you should still use trpc (or an equivalent rpc such as server actions). but that's not the recommended approach to data fetching in the app router

amber forge
#

Ah thanks, that's good to know.

#

@fierce ivy what does "RPC'd" mean?

fierce ivy
# amber forge <@484037068239142956> what does "RPC'd" mean?

basically that means "use server" functions run on the server, but can be called programmatically on the client without the developer explicitly writing http request logic (like trpc mutation). such functions are very likely type-safe, like "use server" functions.

"use server";

async function printHello() {
  console.log("hello");
  return 0;
}
onClick={async () => {
  const data = await printHello();
}}

in the above example the hello is run and logged on the server and data has the TS type number

#

validation for server actions is also a solved problem with zact

#

but i actually like to just make a thin server action zod HOF wrapper instead

#

because all the http request logic is handled natively by react already, we only need a thin wrapper for server-side validation

amber forge
#

very cool, that all makes sense

#

So RPC'ing is sort of the process of running server side functions or procedures, but with the "feel" as though they're client-side?

fierce ivy
#

yeah

#

it's the same RPC in the tRPC; you can call tRPC mutation functions on the client side and it will trigger server functions, but the whole process is seamless and you feel as if the function is run on the browser

last tangle
#

i dont remember the name

#

seems like its actively maintained