#trpc seems like a reasonable alternative
1 messages · Page 1 of 1 (latest)
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.
i didn't read the entirety of this so i may miss some key details but
server actions (which only work on forms)
this is wrong. well it depends on the definition of "server actions"; butuse serverfunctions are RPC'd server-side functions that can be called on the client just like trpc mutations
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
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
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?
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
is there something else like zact? i swear i saw something similar like a month ago
i dont remember the name
i think its this: https://www.npmjs.com/package/next-safe-action
seems like its actively maintained