What exactly is the “middle-end”?

Those who follow me on twitter or have heard me speaking at tech conferences this year have heard me repeatedly clamoring on about something I call the “middle-end”, or alternately, “UI Architecture”. In fact, I just finished up a 3-part article series for JSMag on “The Rise of the Middle-End”. If you want some real meaty discussion of this topic and even code related to it, I encourage you highly to go get a subscription, or at least buy the May/June/July issues for this series.

But for the rest of you, I felt it was time that I distill the topic down into a very short and simple explanation, defining the topic as I see it. This post then will be the foundation for several more to come where I describe practical implementation details for the “middle-end” in web applications.


Let’s jump right in. What sits between the front-end of a web application and the back-end of an application? The “middle-end”, naturally! What’s responsible for packaging up all pieces of the UI and delivering them efficiently to the client, and then facilitating two-way communication between server and client? The “middle-end” UI Architecture. Sure, “middle-end” is sort of a contrived term to describe a concept that’s been around a lot longer than the term itself. But “middleware” is a bit more common, and describes attempts to address “middle-end” needs, so that shouldn’t be too foreign to you.

“I don’t think I have a middle-end in my web application.” Oh yes, you do. Trust me, you do. Every single web-application on the planet has a middle-end, whether it is well-defined and visible, or muddled and hidden. The question is not “Do I have a middle-end?” — the question is “where is my middle-end, and do I control it?”

To better answer that question, let’s get very specific about what parts of the application and stack are part of the middle-end. First, how do I qualify some task as either part of, or not part of, the “middle-end”?

  1. if the task can (and is commonly) done, or at least is useful in, both the front-end and the back-end of an application
    • Templating (static and dynamic)
    • Data Validation (form field rules, etc)
    • Data Formatting (internationalization, encoding/entities, escaping, etc)
  2. if the task is directly related to supporting or facilitating the front-end, or adapting the front-end and back-end
    • URL Routing (deciding which controllers handle which actions, etc)
    • Header management (request & response)
    • Cookies, Sessions
    • Ajax data transport (receiving, transmitting)
    • Caching (server-side)
    • Packaging (file concatenation, minification, etc)

I could go into every one of these in detail, but that would take far too long for one post. However, if a task is a candidate (and often duplicated in) both the front-end and the back-end, it should be an obvious fit to label that task a middle-end task. In fact, it’s even better if the exact same middle-end code for a certain task can be reused in both front-end and back-end contexts (more on that in a later post).

Similarly, if a task is specifically dedicated to helping transition between front-end and back-end (and vice versa) or to service the nitty-gritty details of supporting the front-end, it also makes sense to call this “middle-end”.

Just Fluff

It’s tempting to think that since all web applications have most or all of these tasks built into the guts of the framework in one form or another, calling them out and giving them a specific name and definition is kind of unnecessary and just “trying to hard.”

To that, I respond: only by calling these tasks out and defining them and talking about how they are implemented can we ever truly hope to control them enough to optimize or scale or improve. Just because they’ve always been done in the underbelly of our application stack without us ever thinking about them doesn’t make that the right or most successful approach. Maybe it’s time to re-think them a little bit?

If you’re simply content with letting your one platform-of-choice make all these decisions for you, and handle all these tasks without you knowing or caring, then fine. Enjoy your blissful existence. Move along, nothing more to see here.

More Meat

Page 1 of 3 | Next page