trpc relies still on strings: No proper refactoring (ie F2 in VS Code) which makes refactoring as slow and error-prone as with REST and GraphQL. Should change with v10 but its API hasn't been finalized yet and ETA is far in 2023 if at all. Also overall API design has missed opportunities.
Telefunc should support zod, why shouldn't it? Just pass them as native zod types and all good. You could also convert them before with z.infer but you don't need to.
> It seems like this library has its own bespoke syntax for types
Only for stacks which don't transpile server-side code. You can use normal TS types with something like Next, Nuxt, Svelte, Vite, etc. So, these bespoke types aren't relevant for the majority.
I believe this is only the case with routes, and they're still statically typed. E.g. if you only define `/getUser` and try to invoke `/gteUsre`, it will yell at you.
> Telefunc should support zod, why shouldn't it? Just pass them as native zod types and all good. You could also convert them before with z.infer but you don't need to.
Can you elaborate on this? AFAIK it only supports the types listed here https://telefunc.com/shield#all-types So my understanding is that you can't pass native zod types.
Zod allows for more complex validation like "input cannot exceed 256 chars", "number must be positive", or even arbitrary "refinements". I could, of course, simply write a function that will `Abort` instead, but tRPC+Zod handles that automatically - zero boilerplate. My current understanding is that I'll need to invoke Abort manually if the Zod.parse fails.
Importantly Zod philosophically follows "parse, don't validate" https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... which means that once validation is done, you get a type - a parsed value. This means you can validate clientside and serverside using the same types. Again, sure you could do the same with Telefunc, but you still need to invoke Abort manually and every single RPC definition you have needs to be followed by Zod.parse. A small cost to be sure, but what are the advantages of Telefunc over tRPC? I'm not seeing any right now.
tRPC also isn't strongly tied to Zod, it also works with yup, superstruct, and custom validators.
I still don't see a concrete use case that would justify using Zod in favor of `shield()`. Both "input cannot exceed 256 chars" and "number must be positive" are one-liners in JavaScript.
I'm more than open to support Zod & co, but I'd like to see a concrete use case for it.
Fair enough. Still, this makes your original comment regarding "less boilerplate" kinda ironic... and I'm still not seeing any mention of advantages over tRPC. I'm more than willing to have my mind changed but you aren't giving me much material.
It is ironic because AFAICT Zod is actually more boilerplate than `shield()` :-). Although, the Zod familiarity is a clear argument in favor of Zod.
Speaking of boilerplate, one Telefunc feature I'm particularly excited about is its capability to automatically generate runtime type safety, so you don't even need `shield()` nor Zod then. But it's an experimental feature, let's see how it works out at scale.
The main problem with Telefunc right now is the lack of clear documentation which I'm going to work on in the next weeks/months. Hopefully, it will then become clear why Telefunc is simpler and less boilerplate. Stay tuned.
In the meantime feel free to check out the `examples/` and feel free to hit me up on Discord.
v10 is in beta and will go into RC fairly soon. I'd put my money on a 2022 final release. I'm already using it in production and it's rock solid. Only complaint is still having to restart the TS server in your editor occasionally due to all the inference magic it does.
Less boierlplate.
> so far, I'm preferring trpc, because it has support for zod
What's your use case for wanting zod instead of https://telefunc.com/shield#all-types?