This course contains good reference material, but does not reflect our current quality standards.
Transcript from the "Middle-End Architecture" Lesson
[00:00:29] So, [COUGH] just as a brief little history lesson that no body would care about, but since you're listening to me you have to listen to me anyway, [LAUGH]. Way back in 2009 kind of towards actually the early parts of my speaking career, I was working at a PHP shop.
[00:01:15] My particular pain-point was data validation rules. And I remembered back to my computer science schooling years before that one of the principles, one of the maximums that I learned in my first programming 101 course. Is what we now call the dry principle, but back then what they said in computer science school was anytime there's more than one copy of something, one copy is always wrong.
[00:01:42] Which nowadays we just refer to as dry, we say don't repeat, right? If it's possible to not repeat yourself, it's better to not repeat yourself. It's better to reuse something than to repeat it over and over again. Obviously those are not hard and fast principles, but they're guiding principles in software design.
[00:02:41] And over the years, I worked in a lot of different shops, I saw a lot of different possible solutions to those sorts of problems. I worked in a Java shop, and I saw, I don't even remember the name of it. But there was some framework that probably Java people know right off the bat, but essentially, they expressed their data validation rules in Java.
[00:03:38] Because it was auto generated on the fly and I had no control over the code that they were generating. So we had to work around that by writing a different set of validation rules and reformatting the way the data was coming in. It was sort of the tail wagging the dog problem, like we wanted to fix the problem but we couldn't so we fixed this other entirely different thing so that the problem would go away.
[00:03:57] So as you can tell, I've had lots of different exposures to this in different things, I've seen it in Python shops. I worked in a Python shop one time and a Django and thankfully I didn't have to do a lot of the Python work, but I did have to do a little bit of the Python and Django work.
[00:04:35] It required you to have an individually named thing which is great until you start doing UIs where they want to have a big set of radio buttons, for example, or check boxes or whatever. You don't wanna have to uniquely name those things, that's annoying. You wanna just pass an array of all the check boxes that have been checked with true and false in them.
[00:05:11] And then there were times where I wanted to configure something about the server. I wanted to have some control over something about the server like the way it was putting together the HTTP headers. I wanted to change that to optimize some performance or I wanted to have more control over the way it's packaged up files or whatever.
[00:05:27] And over and over again from Python shops to .NET to Java shops and everything in between Ruby and Rail and everything. I worked at all of them and in every one of those jobs that I worked at, essentially, the back-end ruled, and if you didn't know the back-end language, you just couldn't do what you wanted to do.
[00:06:35] You need to be able to serve those up and that will be the basis for my widget. And so just tell me where to put those files and then I'll go from there, I'm good. Just tell me where in whatever your system is, where do I put these files?
[00:06:46] And I was imagining there was some special folder somewhere in this Grails application, I could just drop a couple of files and bam it magically worked. And he said, yeah, you can't really do that. And he literally handed me this huge book on Grails and he said you're gonna have to read Chapters 4, 5, and 6 of this book.
[00:07:57] Because many of those tasks, the majority of them in fact are things that you need to do in both locations. For example, data validation, data formatting, routing, templating, caching, headers, those sorts of things. Those are all things that every application does, but they're also all things that you end up having to do a lot of on both sides of the fence.
[00:08:35] And so I developed this idea of middle-end architecture, it's a tongue in cheek idea. What comes between the front-end and the back-end, of course, the middle-end. And I defined it as the top 10% of what's happening on the server and the bottom 10% of what was happening in the browser and everything in between.
[00:08:52] And I called that the middle-end and it involved all of those tasks that I was talking about. So at the time there was no such thing as Node.js, we had a couple of things. Like, in the Java world, we had Rhino, which still exists today and it's being rewritten, I think to a different engine or whatever.
[00:09:09] But we had Rhino, which was a way to do it. But that only worked if you happen to be in a Java shop. You wouldn't run a Rhino instance just Java all by itself. So that didn't seem to work out for us, especially since I wa, at the time I had moved onto a job where I was in PHP and they definitely didn't wanna have a Java tool in the stack.
[00:13:29] In other words, I wanna be able to do my front-end completely separate from how I do the back-end. And that middle-end architecture I referred to, the back-end essentially becomes irrelevant to the front-end. The front-end never talks to the back-end, it talks to the middle-end and the back-end never talks to the front-end.
[00:13:43] It has no clue what the front-end is doing. Could be a mobile app, could be a website, could be another API server, it doesn't care. The back-end simply becomes a headless black box state machine. It manages the session, it knows what state it's in, you give it some data, it gives you some data back.
[00:14:01] And that was attractive to me, cuz I didn't wanna have to relearn every single back-end system to figure out how to manage the headers, and the cookies, the HTML files and all that stuff. I just want you to give me some data, I'll figure out the presentation layer, that's the job of the middle-end.
[00:14:16] So even though today I'm not going to espouse specifically this middle-end architecture, I just want you to have that as the backdrop for what I'm talking about when we go into this code.