Should I share my validation schemas of my backend with my client?
Answered
iOS posted this in #help-forum
iOSOP
I realize this is more of a general question, but if I generate an OpenAPI client for my Nest API in my Next.js app using an OpenAPI specification, should I also share the backend validation schemas built with Typebox with the client, or is high-level validation on the client sufficient?
I'm using a monorepo so it's technically possible that I can perform the exact same validation on the client before the request is sent, but it would involve a lot more job + maybe the schemas can be revealing.
I'm using a monorepo so it's technically possible that I can perform the exact same validation on the client before the request is sent, but it would involve a lot more job + maybe the schemas can be revealing.
Answered by B33fb0n3
even if the schemas are revealed then, what would happen? The client can't change these schemas and if they somehow can do it, the server validates with the same schema again.
Some people say, that clientside validation improve the UX. Others say it's just annoying. I personally would validate on both sides even if I expose the schema
Some people say, that clientside validation improve the UX. Others say it's just annoying. I personally would validate on both sides even if I expose the schema
8 Replies
@iOS I realize this is more of a general question, but if I generate an OpenAPI client for my Nest API in my Next.js app using an OpenAPI specification, should I also share the backend validation schemas built with Typebox with the client, or is high-level validation on the client sufficient?
I'm using a monorepo so it's technically possible that I can perform the exact same validation on the client before the request is sent, but it would involve a lot more job + maybe the schemas can be revealing.
even if the schemas are revealed then, what would happen? The client can't change these schemas and if they somehow can do it, the server validates with the same schema again.
Some people say, that clientside validation improve the UX. Others say it's just annoying. I personally would validate on both sides even if I expose the schema
Some people say, that clientside validation improve the UX. Others say it's just annoying. I personally would validate on both sides even if I expose the schema
Answer
@B33fb0n3 even if the schemas are revealed then, what would happen? The client can't change these schemas and if they somehow can do it, the server validates with the same schema again.
Some people say, that clientside validation improve the UX. Others say it's just annoying. I personally would validate on both sides even if I expose the schema
iOSOP
Good point, but im also worried about the implications on bundle size.. especially if im to internationalize them
would a fair middleground not be to 1) generate a typesafe client from the API's OpenAPI specification, use that on the client & perform high-level validation using the built in HTML validation to at least ensure the right type is passed along (type="number", min=...,). And then you can also leverage the browser's built in i18n support
would a fair middleground not be to 1) generate a typesafe client from the API's OpenAPI specification, use that on the client & perform high-level validation using the built in HTML validation to at least ensure the right type is passed along (type="number", min=...,). And then you can also leverage the browser's built in i18n support
@iOS Good point, but im also worried about the implications on bundle size.. especially if im to internationalize them
would a fair middleground not be to 1) generate a typesafe client from the API's OpenAPI specification, use that on the client & perform high-level validation using the built in HTML validation to at least ensure the right type is passed along (type="number", min=...,). And then you can also leverage the browser's built in i18n support
yes, that would also be a good way of thinking. However: keep in mind, that zod (as example validation library) is waaaay more powerful than the browser HTML validation. So, keep that mind
@B33fb0n3 yes, that would also be a good way of thinking. However: keep in mind, that zod (as example validation library) is waaaay more powerful than the browser HTML validation. So, keep that mind
iOSOP
true that, true that! i am using typebox right now since fastify requires json schemas, and i dont even think it has a solution for i18n yet + they are larger in file size than Zod schemas afaik. So i think i'll just start off by not sharing them 
fastify requires json since they compile them ahead of time so the validation is super super quick
otherwise i would use zod since i find it so much easier to work with
@iOS true that, true that! i am using typebox right now since fastify requires json schemas, and i dont even think it has a solution for i18n yet + they are larger in file size than Zod schemas afaik. So i think i'll just start off by not sharing them <:sunglasses_1:767749456648339497>
I guess that suites best for your case 👍
If that's not the solution, feel free to mark another message as solution