Consider dropping the shield concept and suggest that developers use validation libraries
bas080 opened this issue · 5 comments
Telefunc seems the most straightforward lib out there for RPC in Javascript; which i find the selling point of telefunc.
Validation is obviously important but I believe it would be worthwhile to point people to projects like AJV(JSON-schema) which are specialized in the validation issue.
In that case telefunc would need something like (validation) middleware or just show examples of function composition to enable validation using a third-party validation library.
Telefunc already automatically runtime checks the telefunction arguments' types.
So the only thing left for the user to do is semantic validation (e.g. isEmail()). I think it's pretty clear then, and I don't think Telefunc needs to recommend anything here. (Feel free to disagree.)
I think the main problem today is that the docs don't reflect the fact that you don't need shield() nor zod, etc.
I'm waiting for #40 to be reviewed to improve the docs.
Just saw this old issue and politely chiming in: I wonder more and more why we'd need the auto runtime checks which costs perf b/c I'd claim that you need always a val lib, why:
- You can run the same val def on the frontend without a server request and doubling code
- You have consistent error management across all RPs and on the FE and BE and stay DRY or write your own lib at the end
- You can derive other data, e.g. form fields, from the val definition at run-time
=> so the most simple form should be validated
Think this is really a missed opportunity (being able to bring your own val instead of the default one).
'
Related to #85 and #84
I ain't categorically against allowing users to use a validation library like zod as a replacement to Telefunc's shield() auto-generation.
But, so far, I actually like the separation of concerns between type validation (TypeScript) and semantic validation (e.g. email).
The vast majority of runtime validation is about types, which TypeScript and therefore shield() already covers.
For semantic validation, it's often cleaner to use tailored solution instead a general-purpose tool such as zod. E.g. there are slightly different requirements on what a valid email is (a correct implementation it's actually quite complex).
By a matter of fact, other than email validation, it seems that only few people use the semantic validations provided by zod (e.g. I don't think many use z.string().emoji()).
Good points. But even if one don't need any semantic val, just having zod (or whatever lib) for unified error management in multiple langs is important Nobody wants to reinvent the wheel and some good error management which knows when to throw or return undefined, which works on the client in notifications, in modals, does redirects or not needs a solid foundation and better, a good ecosystem. Ofc you can try to hack your own and ship 2030.
However, maybe this convo should be rather about generic middlewares with shield as default but where users can do whatever they want and stay DRY. A proper middleware b/c there are many more concerns which run on a request but not on every, e.g. authc, authr, caching, logging, generic error management, throw or redirect and so on.
Check out https://github.com/giuseppelt/httpc which has a nice middleware concept in its kit version. But again, telefunc shines b/c of its simplicity, there's is so much potential and the need for a solution (which isn't trpc).
Also look, integrating any of those solutions incl Telefunc is not a small decision, once you are on it you can't easily migrate away and hence, the solution must satisfy some minimal requirements.
I'm also not against a middleware system, I'm just waiting for a concrete use case for it with a user that actually needs it. If we can keep things simple, then let's keep them simple.