How to begin your middle-end

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!.

Page 1 of 2 | Next page