validation-as-a-service

Validation as a Service

title: Validation as a Service

So this idea would be to do validation and anomaly detection as a service. Celebration was an issue for On-Site, and it's a recurring issue for a lot of folks. Especially reinventing the wheel for duplicating validations between the server and the client. There is usually a lot of issues with keeping those two in sync. Most people believe that used to have a good user experience you should validate on the client before the request ever goes to the server. And others believe that you should no matter what, regardless of whether it's in the client or not validate on the backend. That way there is absolutely no way that data could accidentally get into the back and that is invalid. There are a lot of different ways to implement validations technologically. The methodology and frameworks are a little bit different from language to language. And there hasn't been any particular client library that has been able to break through on the side of validation.

I would recommend taking a Prisma like approach. So the user could define validations in either a shacks or a shackle format and then we could have a purser reflect on the validations and it could then supply a lot of different kinds of services. So it could validate the data against the database and it could also validate the data against even say a graph database. It could also validate the data at the controller or API level. It could also provide a dynamically generated a library that gives you validation enforcement code in either react native react or angular or Vue or whatever else. The main problem with validation library's is there usually a pain and there really isn't a good reason to use them because you still have the problem of having to define your validations on the backend and elsewhere. But this would create the validations for you so you would just have to tell the validation library which field it is, then it would reflect on the validations that it has four shocks or shackle, and then he could supply validation errors on the backend. And we should probably enforce his validation errors as a data first approach, so not tied to strongly into the how the user interface is presented. But instead just provide validation errors at a data level, maybe using the react keys and then if we wanted more customization we could allow different kinds of hooks into the trigger for the validation. So one that would be as you type another that would be on submission, and another that would be on exit or what have you. That way they can control how they want to display the effects or what have you but we do not we're not concerned about the presentation.

The other benefit of this is this could be cross language so you define your validations one saying you don't have to worry about it for all the languages and then you can make sure that you were validated across

So another way of looking at this would be kind of like viewing it as a open API/swagger service but for validation.

Another thing we could do is have the validations tied directly into GraphQL. There isn't a predefined standard for how data and errors come back in GraphQL. So we could really make a lot of progress in the space.

For an example of the business size. Prisma has raised over $20 million in the past two years