In the previous post, I distilled down into a simple definition what I call the “middle-end” of web applications and also my arguments for why it’s so vitally important that it be a separate and distinct layer rather than an assumed and forgotten tag-along as it is in many common frameworks/platforms.

But upon further discussion and reflection, I realize that it’s tempting to read the ideas I have presented and assume that I’m suggesting a more comprehensive and wide-spread re-architecture effort than I really am. The last thing I would want to do is leave you with the impression that this is an intimidating and complex task to undertake. The tasks I’m advocating for are quite the opposite: they are small, independent, modular, and intended to be rolled into your application in manageable, evolutionary chunks.

So this is just a short follow-up to that post to explain how I feel most web applications could begin the task of redefining their “middle-end” in a more well-formed way, with minimal impact to existing architecture.

The task of re-architecting your middle-end begins with a couple of very simple, incremental steps, not a wide-spread rewrite as it may seem.

Color by numbers

Let’s take data validation for example. First let me define what I mean by data validation: the set of stateless rules which are applied to one or more pieces of data to ensure that the input into the application is safe, reliable, and appropriate.

The most common scenario this is seen in would be form validation. Consider a contact form that requests a visitor’s first and last name, email address, favorite color, and any additional comments. The first and last name fields are text input, and are required. They must both be between 5 and 25 characters. The email field is also text input, must be 8 to 100 characters, and must additionally “look” like a valid email (passing some arbitrarily complex regular expression matcher). The color field is a drop-down, which by virtue of the UI paradigm is constrained to a pre-defined set of options. The additional comments are optional, but if present must not contain any HTML.

Stateless Data Validation

Data validation in this context would entail all of these aforementioned rules. It could also entail data integrity checks, like for instance asking something (totally contrived for this discussion) like “if the first name is John, the last name cannot be Brown”.

However, something like enforcing that the email address was “unique” in our database (meaning we’ve never heard from this person before), or that the email was not already on a blocked “black list” as a spammer — those tasks would not be stateless data validation checks, but would instead require stateful back-end business logic. That would not be something we’d want to do wholly in the UI layer (maybe via a round-trip Ajax request, etc).

The point is that stateless data validation/integrity checks are agnostic of the environment or the state of the application. The check is blindly applied to a piece of data, and the result is binary true or false — either it passed or it didn’t. This means that such code can be written to act upon a data structure (like JSON) and be completely ignorant of where the data came from. This is very important.

Because we know that data validation is important to User Experience, we often write those rules in JavaScript, and run them in the browser while the user is interacting with the UI/form. But because as good Computer Scientists we know that no UI can be trusted, we also know that the same rules need to run on the server on any inbound data.

This is where trouble usually starts happening. We re-write all our validation rules a second time, this time in another language like PHP or Java. We’ve made a second copy of that code/logic, and we’ve forever cursed ourselves with more complicated code maintenance.

Another way?

What if, however, we could write the stateless data validation rules in JavaScript, to operate on a JSON data structure with one or all fields present/populated, and we could run the exact same code in both the browser and on the server? That would achieve an unprecedented level of DRY (don’t repeat yourself) coding in this context!

Is there any reason why our application, regardless of what language/platform it is, couldn’t entrust the tasks of stateless data validation to a server-side JavaScript module? I’d say, plainly, no!.

If the data validation logic ran on the server, in a trusted environment, what difference would it make if it was JavaScript or PHP doing the checking? The difference (for the better) is that this code logic would be write-once-and-reuse, and that’s a huge improvement in maintenance.

In the browser, you would have controller logic that would take one or more data fields from the <form> and stuff them into a data structure (JavaScript object and properties). Then, you would pass that data into a set of JavaScript code logic that ran the rules against the appropriate properties, and spit out true/false answers.

On the server, you would take inbound data, either already formatted as JSON (preferably) or in key-value pairs that you could easily serialize to JSON, and then pass that inbound data directly into the same code.

This still seems complex

All you really need to accomplish this is to be able to execute some very basic JavaScript on your existing application server. There are a number of options available, ranging in complexity and scope from Node.js to Narwhal, etc. Another, much more stripped down option is my environment, BikechainJS. BikechainJS is a single executable file environment wrapped around the V8 JavaScript engine. It’s designed to be run in “CGI mode” — in other words, per-request, on-demand — in existing web application frameworks.

So, using something very simple like BikechainJS, you could easily set up your existing web application to run a BikechainJS execution to do the data validation tasks I just mentioned. You’d simply take a single data input endpoint in your existing application (like the action that responds to your contact form submit), and instead of running your own PHP or Java rules on the incoming data, simply package and hand the data off to your server-side JavaScript validation routine.

If you get a “true” back, the data validation passed, and your application can continue as necessary. If “false” (or some other specific error messaging, if you prefer), then immediately respond back to the request with the error and don’t let the application continue.

I’d recommend to start off with you pick one application server touch-point, and even just one field in that inbound data, and ferry only that off to your server-side JavaScript validation. Do you see how much simpler and easier that stripped down approach is compared to a wide-spread complete re-architecture?

As you get comfortable with this approach, and you feel ready, you can extend your data validation to encompass more and more of your inbound data, in more and more of the application’s server touch-points, until you have all your data validation tasks written in DRY and maintainable JavaScript.

The rabbit hole

Data validation is only one of the dozen or so tasks that the “middle-end” entails. Your next step might be to start tackling DRY approaches to templating. Again, you should go little-by-little into that world.

Regardless of how you proceed, I hope it’s clear now that I advocate a pattern rather than particular implementation details, and that I advocate little baby steps along the path, rather than complex and comprehensive re-writes. That I believe is the right path to beginning your middle-end.

This entry was written by getify , posted on Tuesday July 13 2010at 10:07 am , filed under JavaScript, UI Architecture and tagged , , . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

Leave a Reply

Consider Registering or Logging in before commenting.

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.