 Two, Origin Edge Client, where to do the work? We're gonna go ahead and get started here. Thank you all for coming out at noon. I know a lot of you are probably hungry and ready for lunch, so I appreciate you making the effort to come out here. My name is Matt Davis. I'm a lead Drupal architect with Media Current. This is a picture of me in the Game of Thrones tour I did Sunday in Northern Ireland, which I would highly recommend. I got to see a lot of the cool filming locations. The highlight for me was getting to meet a couple of the actual direwolves, so I would definitely recommend check that out if you have time while you're here. And like I said, I work for Media Current. It's a Drupal shop based in Atlanta, Georgia. A bunch of very talented people, and they are definitely hiring, so if you're interested, come see me afterwards. So today I am largely gonna be talking about something called Edge Side Includes, but I'll be going over a lot of how we make webpages scalable and performant in general and how Edge Side Includes can fit in to your performance strategy. And specifically, I'll be talking about some of the projects I've used it on and showing some real world examples as well, how you can use it. So we'll start with a few introductions. First and foremost, weather.com, it's a site most of you are probably familiar with, and many of you probably also know that it is a Drupal site. It launched on Drupal in November of 2014, so it's been Drupal for almost two years now. And I was one of the lead developers on the project. Weather.com has a lot of things that make it a really unique site. At the time of its launch, it was the highest traffic Drupal site in the world. I don't know if that's still the case or not. These are some of the metrics they brought to us from their legacy platform that they were using before they converted to Drupal. And as you can see, they didn't have much of a caching strategy at all. They had an average of about 50 million page views per day and about half of those were going all the way to their origin servers. So they were using 144 origin servers in three different data centers, which on an average day was okay, but one of the other things that makes weather.com really unique is not just that it has high traffic, but it has high variability in traffic. So an average day may be 50 million page views, but when a major weather event occurs, like a big hurricane or something, that can spike up to 800 million. And so even the 144 origin servers they had during major weather events couldn't keep up with the traffic they were receiving. The other thing that makes the site really unique is that they have a lot of hyper localized data. At the time of the launch, they had about 2.9 million locations that they were serving weather data for. Now they're using sub zip codes and it's actually over a billion different locations. So we have to be very, very careful about how and where we use the resources that we have available to us to make this site performant. Next introduction is weather underground or wonderground.com, which is actually owned by the weather company as well. So it's a sister site of weather.com. And just this year, it has been being migrated on to the Drupal platform that we built for weather.com. And I'll show you a little bit about what makes it unique a little later on. Some of the unique ways we use ESI there as well. And final introduction is this thing called edge site includes, which I'll be telling you a lot about, but if you've never seen it, here's your first little view of what an ESI include. Looks like it's just a little bit of markup syntax that we see here that lets you pull in a fragment of markup into a page. But before we go deep into the ESI land, let's take a brief look back and take kind of a broad overview of how the web has evolved since the first pages came out. So here you'll see what is literally the first web page ever in history. Super, super simple, pure markup with some hrefs in there. And this entire page would be generated at an origin server and sent directly to your browser. Not a big deal because there's not a whole lot going on here. But obviously, very quickly, people wanted to do much more complex things with their sites and needed ways to make those fast, especially in the dial up days. So who here ever built a website with frames? Yeah, me too, me too. Some of my first sites as a kid, and I thought they were so neat because I could have my header and all my navigation bar stay. And as you navigate it through pages, just the bottom frame would load again. So part of what makes that really useful is sharing content and not having to re-download pieces of the page that you're gonna share across pages. So that was kind of a game changer. In the mid-90s it was introduced with Netscape 2.0. Also introduced with Netscape 2.0 was the idea of JavaScript, which was a game changer as well because it allowed you to do some logic and processing on the client itself. So in the browser now, you could actually react to behavior from the end user. JavaScript 1.0 was very limited in what you could actually do with it. There was no ability to make HTTP requests, so really you were limited to just what you had available to you in the browser. And mainly at that point it was used for basic types of form validation. For example, if you had like a telephone field in a form you could validate that it had the correct number, the correct amount of numbers in it. More complex validation like unique username, for example, you couldn't do because like I said, you couldn't make a request back to the server to check against the database or anything like that. So at that point it was very limited. Streaming was an idea introduced with HTTP 1.1 in the late 90s and this allowed you to really improve perceived performance for your users. What streaming lets you do is with one single request you can actually flush pieces of markup out to the client without closing the request. And so you can send part of your markup, continue to do logic and keep sending more markup as you process the page. So the total time spent delivering the page may be exactly the same, but it increased perceived performance because users could engage with your page sooner. And then a few years after that we had the idea of Ajax. Now Ajax was another huge shift that allowed you to fill that gap I mentioned before where now if you're doing form validation, for example, you can actually send a request back to the server, get some new data like has this username been used before and then pull that data back into your markup and either append or replace pieces of your page with the response data that you've gotten. So these are all a few of the ways that we've made pages more performant and scalable over time. Where does ESI fit into all of that? Well, first and foremost, ESI is not a new technology at all, it was actually a spec submitted to the W3C way back in 2001. So it's been around quite a while and Occamai's most recent manual developer guide here, this is a screenshot of, came out in 2004 and has not been updated since. So there's not a whole lot changing in ESI land and in a lot of ways, if you start digging into ESI you may find there's not a whole lot out there about it. So it can be kind of an esoteric thing to engage with. So you really want to consider your use case carefully if you're considering going down this road but as you'll see the benefits can be tremendous. So what is it exactly? Well, ESI allows us to improve end user performance and how does it do that? The big one that we're gonna see a lot of today and focus on is the way that it allows us to reduce processing overhead at origin. So we can actually do repetitive tasks just once as a fragment and include them on multiple pages and we can break pages apart based on how cacheable they are. So we reduce duplicate processing and enhance availability. And there are four main things that we can do with ESI. The ESI include is the most basic and the most widely supported as you see here and this would just make an additional request that pulls in the markup from helloworld.html and replaces this syntax here with the markup that it receives. You can also set variables. This is I think only, these other pieces are I think only supported by Akamai but you're gonna see how we use them on weather.com in a little while. You can also do conditional statements. So basically if else kind of things, the syntax here you see ESI choose and ESI win. So this would anything, if it found that there was the no redirect variable then it would use whatever was inside of that win statement. And then you can also include error handling and here you see the ESI otherwise that would be the last piece of your ESI choose and here we're throwing a 404 if we haven't gotten any of the other wins to work. What ESI is not? Well, ESI is not streaming like BigPipe for example which we'll talk a little bit more about later. This is not a streaming technology so what that means is that as far as your end user is concerned the page is still gonna render all at once. All of what you're gonna see here is still happening server side and it is actually multiple requests. So technically they are asynchronous requests but again that's kind of invisible to your end user because those asynchronous requests are happening at your CDN or at your varnish layer. Can you use it? Yes, absolutely. Like I said, Akamai supports a very robust form of ESI and varnish and Fastly also support basic ESI includes as well and there is an ESI module for Drupal 7 that supports turning your blocks or your panels or your context into ESI fragments. So you can use this today. Now let's dive in to how we actually use this in the wild on weather.com and why it has been so important to our architecture. So this is a forecast page for weather.com for Holman, Wisconsin for some reason and as you can imagine most people who visit the weather.com site are there to visit one of these forecast pages. So they are by far the most highly trafficked pages and we have a few different versions of them as well that you can see. This is just the today page but we also have hourly forecast, five day, 10 day weekend, these that you see here on the page. Now in a kind of idealized version here I'm gonna switch back and forth between two different locations and what you can see is that there are parts of the page that are actually pretty much exactly the same and so we have different parts of the page that have very different needs in terms of cashability and time to live. So our approach when architecting all of this was to break these pages apart and kind of examine each section of the page individually in terms of what it needed to be the most performant. And as we begin breaking this apart we architected something that we call the presentation framework. This presentation framework I've talked pretty extensively about in the past more focused on the JavaScript and decoupling side of what it does and if you're interested in that piece of it I'd encourage you to go look at the media current blog where I've blogged a lot about it or I spoke about it in LA a couple years ago and also a little bit in New Orleans this year at Drupal Cons. But at its core what the presentation framework is is it's a mechanism for putting components onto pages. So there's been a lot of hype in the Drupal community recently about component-driven theming. The presentation framework in a way is sort of a predecessor to that and what it does is each section of the page that I showed you before is encapsulated as its own component. So here we see an example of what one component looks like in the file structure, the 24 hour forecast and it has everything it needs to be fully rendered here. So it has all the CSS, the HTML templates and the JavaScript that it needs to be rendered. And down at the very bottom there you will see the info file much like a module info file. This is just a file that holds some metadata describing everything about this particular component. And each component in the presentation framework has three different ways that it can actually be presented. Through Angular, through static HTML or through PHP. And in each of those cases you can choose whether to deliver that through Drupal as part of the initial wrapper page or as an ESI fragment. So this is an example of what one of those info files looks like. As you see it's JSON formatted and the pieces here I would draw your attention to is the presentation, which this one is set to present as an ESI fragment and that you can set time to live individually for each component as well, based on how catchable it is. And then you can say what assets it needs, what JavaScript, what contextual information it needs from the page and shared is where we actually can build dependency trees if it is dependent on other sub-components. So what the presentation framework module actually does is it walks through all the directories where these components live, finds those info files and takes each one of those components and turns it into a panel's pane. So if you're not familiar with this this is the panel's UI and each one of these panel's panes you see here is one of those components defined independently in its own directory as we saw. So I'm gonna briefly go through how each one of the presentations works. Static presentations pretty obvious. You could just have an HTML template with some CSS and that will be rendered by Drupal inline as part of the page wrapper. So that would be used for highly catchable content. Angular presentation, Drupal will render a simple Angular placeholder and then once Angular bootstraps it'll inject on that and put whatever template markup it needs in its place. So this is for highly localized and uncashable content. And ESI somewhere in the middle, Drupal will again render a placeholder but this placeholder will be replaced by a server at the edge using Akamai. Now the way we do this in code is we have if you choose the ESI presentation we have a hook menu here that you can see that takes the actual C tools instance ID of that pane the UUID and as an argument and when you hit that menu link with a working UUID it will deliver the fully rendered pane. So that's how the fragments work. But how do we decide which of these presentations to use on a case by case? Well this is straight from our actual internal documentation and I guess I'll go through each one a little bit. Dynamic server side as I already kind of alluded to this is for the most catchable stuff that we have with the things that we want to be server side rendered and included in the page wrapper itself. AngularJS is used for very localized and uncashable data that may be reused but is highly variable. So all of the actual forecast data that you see is gonna be rendered by Angular. And ESI fills that middle gap things that are not individualized but may be regionalized. So things that can be reused for a specific group of users and we don't wanna push all of that processing to every individual user's computer but we also don't wanna do it at origin. And here's my overly complex architectural diagram. So what you see there on the left is what Drupal actually renders as the page wrapper. And what you'll notice there is so Drupal's rendering the entire head Drupal's rendering the basic stuff like header footer but also where you see those news items in the bottom left that is a presentation framework component that is being rendered as static HTML. So that is the most highly catchable content being rendered by Drupal. And that would be pushed to Akamai and what you see the lateral communication here is between Akamai and our services layer which is MongoDB also had a CDN and then Angular fills in the most localized stuff. Now where ESI plays into all of this is what I'm about to show you. So what actually happens when you make a request? This is an example URL for a today forecast page for Dublin. And what we do using Akamai rules is everything after that slash L slash we chop off and we preserve it as an ESI variable and redirect everyone to the same request weather slash today slash L slash ESI. So no matter where in the world you're making a request from there's only one hit to origin that's coming down. After that ESI uses that location slug that we preserved as a variable to make a services layer call. Now that's a lateral call as I mentioned because our MongoDB services layer also lives in CDN. So that's not going back to origin. The service layer returns takes that slug of the location and returns the full location context object. So it takes a zip code for example and gives you latitude and longitude and city name and state and all of that kind of information that we're gonna use to fill in what Angular takes over later on. And from all of that we make one more request that does go all the way back to origin for the actual template and wrapper of the page and everything else is filled in with ESI and Angular. So this is what that actually looks like in code. Just pieces out of here I'll show you. This is us building out our API call and then making an ESI a vowel which you haven't seen before. A vowel is very similar to an ESI include. The only real difference is that an a vowel if you set variables in an a vowel you can continue to use them later on in your ESI which you can't do in an include. So that's why what we're doing here the services call actually returns ESI variable with the full location object inside of it. And after that which you'll see the loc object is the variable returned by the services layer. And as long as we have that then we go ahead and render the template, the wrapper of the page and we have that variable to feed into that template. Otherwise we go to a 404. Now as I mentioned earlier there's a bunch of different kinds of forecast pages. We do the same behavior for every single one. So for no matter what kind of forecast you are requesting or where in the world you are when you request it we are lopping off everything and sending you to that same ESI task handler. One request back to origin regardless of type of forecast or place in the world. And then the template is the same for each type. So you have one request for all the ESI, a lateral services call and then one request for the specific type of forecast template page. And this is an example of what the actual Akamai rule set looks like where we have all these different kinds of pages. If the path matches any one of those we're sending you to just that one path for today's slash l slash ESI. So all told where did that get us? Well, we have an over 99% origin cache offload and we went from the 144 origin servers before the system down to eight today and most of those sit idle. And that is a cause for celebration. So moving on to the weather underground story. They do some cool things and a couple of things that are unique about them they're actually using Angular 2. So they have this full screen weather app that we adapted to Angular 2. And one of the things we had to do when we adapted this was the original legacy version of this used a bunch of query strings. And in the legacy version, each combination of query strings was going all the way to origin and building everything separately at origin. Well, we didn't wanna do that. We wanted to preserve our origin offload but we did wanna support those query strings and also allow people to bookmark their state. So we wrote a little snippet of ESI, very simple that checks if there is a query string in the request and if there is because all of the actual behavior changes are happening client side, we set a global window object with the key and value of those query strings for use by Angular 2. Very simple stuff, but this allowed us to preserve our cache offloading from origin and to continue to preserve the functionality of the legacy stuff. Now, something that's really exciting is the Akamai EdgeScape implementation that we use where EdgeScape is an Akamai service but other vendors have similar things that I've been told, I don't know that much about them. But basically, EdgeScape allows you at the edge to detect bandwidth, device, or location of your users. And using ESI then, you can do all kinds of cool things with that. So this is an example of some code where, and you see some other syntax I haven't shown you before. The basic syntax we see here is the top part is if there is ESI available to us, we're going to render that code. If there's not ESI, this is default behavior just as a fallback. And what this is doing is if we have ESI, we're getting the lat long and the country code from EdgeScape and feeding those into window objects so that Angular 2 can react to them. Now, what that gives us, I'm sure many of you have seen this little popup thing, this little alert come up on your browser where some site wants to know your location. We don't have to do that anymore. This is JavaScript behavior and that means your full page has to render and JavaScript has to do all its stuff before this even kicks off. Instead of that, we're using EdgeScape to get your location information, feed it straight out and it's there ready. So no prompt thrown. It's not quite as accurate, but it has been a huge improvement for us. Bandwidth variants. Now this we haven't actually implemented yet but I'm really excited about the potential here because like I said, using EdgeScape, you can detect your bandwidth at the edge and that means you could choose ESI statements to deliver different includes and pull in different fragments based on your end users bandwidth. This is really important for weather.com as they're trying to make a move towards being more global and going into countries where 3G and 4G connections are not as widely available. So this allows us to support many more users by delivering a much more lightweight experience to those with lower connection speeds. And we are actually hot underway with development of a next-gen version of this entire architecture that I can't say too much about at this point. Check back in six to nine months. But what I can say that I'm excited about is that we're actually gonna be using multiple kinds of stacks in the future to render pages so it won't only be Drupal. We will also have some areas of the site using Node.js stacks. And we're using ESI as part of that architecture to share common pieces like menu items that you want to be consistent across all stacks. So whether you're using Drupal or Node you'll have the same ESI include to pull in your menu. So it's always the same. And that allows editorial teams as well if they change that menu through one Drupal editorial interface, it populates everywhere throughout the site, regardless of what stack is rendering the page. What about Drupal 8 and ESI? Well, I don't know if any of you were in Fabian's excellent talk yesterday. He covered some of this. The ESI module that I mentioned for Drupal 7 has not been upgraded yet. There is a potentially new HDP kernel integration point, but I don't know if anyone's even actively digging into this. So if people are interested in Drupal 8 integration that would be a great place to jump in and help. Something else that I'm really excited about is ESI and big pipe integration. Big pipe is a streaming service that I think is in a beta state now with 8.2. And it allows you to really speed up perceived performance by delivering parts of your page as soon as they're ready. Combining that with ESI would be incredible. And similar, this is something that Fabian talked about yesterday, very similar to the hook menu way that we deliver ESI fragments for those components. You could have a defined hashed route for an ESI fragment and have the initial response sent straight away so you get initial page to engage with and then more dynamic things come in through ESI fragments as you continue. Supposedly there is some fastly support for this coming very soon and a varnish patch available. I have not played with either yet, but I'm very excited for the potential there. And that's it. Thank you. If there are any questions, I think we've got plenty of time, so there's a mic right there. And I would encourage you to evaluate this session also. Any questions? I know some of you have questions. Feel free to come up to me afterwards as well if you wanna ask questions personally. Oh, maybe we got one. Thanks very much for the talk, very interesting. Could you talk about the suitability of Drupal when it comes to ESI? If you don't have the services layer that you talked about, that's obviously an extra component of the architecture. If you only had Drupal to deliver your content, would ESI still be a good fit or does that change the situation? I don't think it changes the situation that much. It really depends on your specific use case. I mean, one of the key pieces here to consider is do different parts of your page have very different needs in terms of cashability and are those pieces reusable? Because the key thing we're trying to consider here is cutting down on overall processing, right? And offloading as much of that from origin as possible. So the services piece, like I said, all that's really doing is taking the slug from the URL of the location and expanding that out into a location object. So you could accomplish a lot of this without needing that services later at all. No, good question. I don't wanna be stupid, but I probably have to. So on which layer these ESI execute on which layer? So ESI is actually executing on the server at Akamai. So one of the advantages that gives you, Akamai is a CDN, a content delivery network, right? So we have origin servers only in one region right now, US East, but Akamai expands the entire globe. So what Akamai does is it caches very close to the end user, so that reduces latency, but it also lets you do this region-specific kind of processing. So it's gonna be very close to the end user without having to make the extra hop all the way back to origin. So it's at the edge is where that all happens. So how exactly the process goes? So user requests the URL, who first drops this request? So it Apache, right, on the first step. It goes so the request initially will go all the way to origin, right? Origin delivers the full markup and that markup delivered from origin includes ESI in it and the ESI is processed by Akamai and that all the ESI logic is done at the edge. So there's, in a cold cache situation, it is going all the way to origin to get all of that markup in the first place. But then the markup is processed and all the ESI pieces are done at that edge. Does that answer your question? Yes, thank you. Thanks. One important thing to note that I don't think I mentioned there is that in a cold cache situation, because you're actually making additional requests with this kind of thing, it can actually be slower. So if you're considering going this kind of route, you might wanna, depending on your situation, you might wanna consider a cache warming strategy as well. You talked a little bit about how these features are really only supported by Akamai and so it seems like you're really in bed with Akamai. You're married for 100 years. Was there any kind of talk with the client or in your team about that vendor lock-in, about the dangers of that? And my second question is when you said you went from 144 origin servers down to eight, it seems like you're just shifting the cost to other locations and I'm wondering by how much? Yes, both great questions. Answering your first one first about vendor lock-in, it is actually a huge concern. And I don't know, some of you may know that weather.com was recently acquired by IBM and vendor lock-in has become an increasing concern, so we are certainly looking at other ways to accomplish some of this as well. And what was your second question again? About the cost savings. The cost savings is substantial actually and a lot of it's a management savings because we don't have to deal with all that, the origin server offload. Now, it really depends on your situation, whether that makes sense or not, but the other big part of that is the latency gain as well. And for a site like weather that's really trying to gain users all over the world, having more happen closer to them, especially for low bandwidth users is a big concern. Anybody else? All right, well thank you very much.