Tuesday, April 29, 2014

A Brief History of Web Validation

So in the beginning of web development your code ran on the server. A user typed in data to some fields then hit some sort of submit button. A form was POSTed to the server. The server then validated the code and if the code did not pass validation it would reconstruct the page with some added nasty messages hopefully explaining why you did it wrong.

This was a horrible user experience and incredibly inefficient. So along came JavaScript. Using JavaScript you could assess whether a POST would fail before it was submitted. This allowed you to give fast feedback and even prevent a submit that you know would fail. So this both gave a better user experience AND made your server resources go farther! The amount of win is intense!

But that isn't the whole story... Because in the client server model of the web the browser is pretty much untrusted so you can't really rely on it to always do the validation because a user might subvert your client code. So to maintain some guarantee of data integrity you have to do the validation on the server also. So now you have duplicated code... Duplicated code is bad. Hey, but this duplicated code is probably in two different languages right? Does that make it better or worse?

So you had systems that helped you make validation easier. They would be canned "thingies" that would do validation on both client and server while only adding the "thingie". So that is currently where we are at for non-SPA programs. But what about single page applications? These applications redraw the line between client and server so magically "thingies" that span those two worlds don't fit in anymore. So does that bring us back to the idea that we write all our validation twice. One in the language or the server and once in the language of the client? Or do we just use node.js so we can write validation once and they just run it on both the client and server?

Here is another idea. Abandon the ideas of the past. Don't do validation on the client. Madness! But think about it. Go to a search engine. Put a letter into a search box. A request is done. Another letter. Another request. SPA is the shift from big page reloads to rapidly delivered small JSON messages. You can run validation against user input every second and give responsive feedback. Your servers can rapidly process these requests because the are pure logic and not based on data. They do not need to run against any database that would make the request slow.

This is just an idea and  may not be the best solution, but I recently watched a presentation by a Shannon DiOrio where she presented a web app that did all the paging client side. This shift from conventional wisdom (paging must be done server side all the done in the database) surprised me, and made me think about things a little more. Where you put various pieces of your application either on the client or the server will probably shift based on the tools and the performance of those tools so old practices should constantly be re-evaluated.

No comments:

Post a Comment