The Middle End

[00:00:00]
>> Kyle Simpson: I'm not suggesting that what you do on the back-end is wrong. And I don't wanna suggest that what we do on the front end is wrong. But they're very different worlds, and they don't play very well together. And so we need some sort of buffer zone, a demilitarized zone, if you will, a DMZ between these two.

[00:00:16]
And I formulated these thoughts into something that I called, the middle end. What sits between the front-end and the back-end? It's the middle end. And essentially those are a collection of behaviors that basically every web app, even web apps today, every web app does. Things like routing, things like templating, things like data formatting and data validation, things like bundling and packaging a resources, responding to API request.

[00:00:41]
These are things that every single web application in existence do. And what they all share in common is that they all bridge the gap between the browser and the server. As opposed to something like your database rights, which is clearly back-end, it's clearly business logic, we have all these pieces that touch the front-end.

[00:01:01]
So I just started defining these as middle-end. And as I started to think about the middle-end, I say, well, if I wanna build a nice clean middle-end and essentially turn the back-end of any application into a black box API a state full API that I can send at some JSON and get some JSON back.

[00:01:21]
And I don't care what that back-end is, it could be .NET today and it could be Python tomorrow but there's an API that I send that data. And then I decide in the middle-end how to make things ready and how to adapt things for the front end. And the middle end gets to design, I'm talking to a mobile app, or I'm talking to a web browser, or I'm talking to a robot, or a smart watch, or whatever.

[00:01:43]
But the back-end doesn't have to concern itself with any of those things. The back-end people don't like the front-end anyway. So let's just tell them, just delete all that code, just stop dealing with any of that stuff. Let the middle end handle it. These are the thoughts I had in late 2008 and early 2009.

[00:02:00]
And so I began surveying, what could I do to write middle-end code, and write it in JAVA script, and run it. The same code in the browser and also on the server, to handle these things, to talk to each other. At the time, there were a couple of options for putting JavaScript on a server, but none of them were suitable.

[00:02:21]
One of them was Rhino, which was Java's JavaScript engine. And I happen to be working at a PHP shop at the time, and there was definitely no way that a PHP shop was gonna allow me to install [LAUGH] a Java stack, just so I could run Rhino to run JavaScript, that's a bridge too far.

[00:02:43]
So I wasn't gonna be able to do that. And there were a couple of other options, but they had similar problems. Actually, most of them seemed to require Java. Because that was the way to do platform independence at the time, it was to make it built on top of Java.

[00:02:59]
And so essentially, after serving those I realized, this isn't gonna work. None of these options are sufficient. And it was around that same period of time, I think it had been 2008, if my history remembers. But it was around that same period of time that Google had launched Chrome with their own JavaScript engine, V8.

[00:03:16]
And I had remembered, just randomly reading a blog post somewhere V8 was a C++ program that you could literally write your own bindings to. And I hadn't done C++ in a decade. But I thought, I could probably dust off some C++ skills. So I began to formulate this idea.

[00:03:35]
What I wanna build is a server side JavaScript environment that's totally not based on Java or something like that. It's gonna use the V8 engine. It's gonna run JavaScript on the server. And I'm gonna run these middle-end tasks in this engine. So I set out to start building that, I'd begin doing conference talks about it.

[00:03:51]
And that project, nobody should use this anymore it's completely deformed, but if you are curious it's still in my GitHub. It's called bite chain. I wrote a server side JavaScript environment, this is all pre node. I wrote a server side JavaScript environment called bite chain. And I actually launched a number of sites for employers and myself using this idea of middle-end, where it treated the back-end agnostically as just an API that it talked to.

[00:04:16]
And the middle-end handled all those middle-end tasks, like formatting and presenting of materials, templating, all that other stuff. Well, I'd been working on this for probably a good six to eight months. So I was pretty deeply invested in it. A little beyond proof of concept. It's more like alpha to beta stage at that point.

[00:04:38]
I was using it in production at a couple of the jobs that I had been at. And then I get to JS coffe and Ryan stands up and says, hey, I've been building this thing for a while. It's amazing, It's called node. And we all lost our minds because we all thought, wow, that's incredible, like what we're going to be able to do?

[00:04:57]
Where we're going to be able to put JavaScript? And I think a lot of people at the time and maybe even still today, ten years later, the message they took was, that's the answer for putting JavaScript on the server. But that's not really what captured my attention. Captured my interest in node.

[00:05:14]
In fact I was a little bit of a slow adopter to it. I was excited about the fact that it was going to exist. But I was pretty heavily invested in bite chain at the time and they were very different models. Bite chain was a synchronous environment and node was an asynchronous environment.

[00:05:28]
I was building it so that you could call it directly from a PHP script. And you can't really, at least at the time, you can really do something asynchronous from PHP like that. So