Managing client-side and server-side validations in one place

Question

I'm 100% on board with the case that one should definitely use both client-side and server-side data validations.

However, in the frameworks and environments I've worked in, the approaches I've seen have never been DRY. Most of the time there's no plan or pattern - validations are written in the model spec, and validations are written in the form on the view. (Note: Most of my first-hand experience is with Rails, Sinatra, and PHP w/ jQuery)

Mulling it over, it seems like it would not be difficult to create a generator which, given a set of validations (e.g. model name, field(s), condition), could produce both the necessary client-side and server-side material. Alternately, such a tool could take the server-side validations (such as the validates code in an ActiveRecord model) and generate client-side validations (such as jQuery plugins, which would then be applied to the form.

Obviously, the above is just a "hey I had this idea" musing, and not a formal proposal. This sort of thing is surely more difficult than it seemed when the idea hit me.

That brings me to the question: How would you approach designing a "write once, run on server and client" technique for data validation?

Related subtopics: Do tools like that exist for any particular frameworks or client-server technologies? What are major gotchas or challenges with trying to maintain only one set of validations?

Answer 1

In my limited experience, the points where validation are required are

1. The presentation level using HTML,
2. at the post-presentation level (i.e., Javascript validation),
3. at the combination level where interactions between multiple fields have to be validated together,
4. at the business logic level and
5. at the database level.

Each of them have different languages, timings, and triggers. For instance, it makes little sense to validate a field before the entire record is in a consistent state, unless you want to validate just one piece. Constraints at the database level have to be applicable only at the end before a commit, and cannot readily be done piece-wise.

A related concept is that representing data varies between each of the levels. A simple example is a web browser represents a piece of text as, perhaps, CP1290, while the database represents it in UTF-8; the lengths of the two strings differ so enforcing length constraints gets awkward.

Answer 2

One consideration that often limits solutions is the network round trip. The client is supposed to validate the user data without sending a message over the network. In other words, when the user hits the submit button, the client is supposed to validate the data locally.

First, let's assume that we do not have this limitation. We could communicate with a network endpoint that is good at articulating validation issues. For example, when you submit your new User record to it, rather than responding with a vanilla HTTP error code, it could return a detailed JSON response itemizing the issues and the client would smartly update the display to reflect the problems it encountered. The endpoint plays the role of a validation gateway.

It's DRY but not without drawbacks. First, it depends on the network roundtrip taxing our server with validations that could have been handled client side. Second, the design anticipates that all CRUD operations will occur via our endpoints, but what about when developers and processes bypass our data access layer by going directly against the database?

Let's revisit our solution to overcome these drawbacks. Instead let's store and communicate our validations as metadata:

{field: 'username', type: 'required'}
{field: 'username', type: 'unique'} //requires a network roundtrip
{field: 'password', type: 'length', min: 10, max: 50}
{field: 'password', type: 'contains', characters: ['upper', 'special', 'letter', 'number']}

Both the client and the server would have some mechanism (e.g. an engine) for interpreting and applying this data. (Some call this the free monad as it separates the declarative portion from its interpreter.) In JavaScript we could map each piece of information to working functions. To boot, we can teach any layer of our architecture, including our database, to enforce validations consistently.

Answer 3

One way would be to use same language / framework on both server and client side.

E.g.

Node.js :: Client / Server in JavaScript GET :: Client / Server in Java

In this case, most of the "Domain Object" code would be common, that would include validation. Framework will invoke the code as required. E.g. Same code would be invoked in browser before "submit" and on server side web service.

EDIT (June/2014) : With Java 8, is now easy to integrate JS validation code in Java Applications as well. Java 8 has a new JS execution engine that is more permanent (E.g: it makes use of invokeDynamic).

Answer 4

I was just thinking about the same problem. I was thinking of using ANTLR to get an abstract syntax tree in both C# and javascript. From there you use tree walkers to apply the actions specified in the language to the objects to be validated.

So then you could store a description of the required validation where ever you like - possibly in the database.

This is how I would approach the problem.