 Alright, good afternoon folks. I'd like to welcome you all to Drupal is Not Your Website. I'm going to be giving you a talk about developing Drupal for high-stale fragmented websites. When I was putting together this presentation, I was trying to come up with a really cool clever hashtag for this. Sorry, everybody, I couldn't come up with anything. The initials are B-I-N-Y-W-S, which, at best, that bounces out as the newest. And that turned into, like, a princess bride, you know, thrones, crossover. That really needs to be another thought. Just a couple of presumptions and expectations. To give you an idea of what to expect during the session, this is technically an intermediate DevOps session. So I expect you to kind of be at least experienced with site-building in Drupal and some basic DevOps concepts. It doesn't necessarily mean anybody has to be well versed in it, but it's a good idea to have some happen familiarity. I'll give you an overview of some concepts. I'll introduce you to maybe some new concepts or apply new names to old concepts. And then hopefully be able to give you some suggested modules and resources that you can use for your own implementation. So today I'll try to cover what a website really is. I'm going to talk a lot about the edge, the origin, the client side. These are different locations that content can come from. And I'll go about quite a bit of detail about those. How does Drupal fit into your overall stack? If Drupal's not your website, what is? Some other elements of a website to consider outside of Drupal. We'll talk about removing things from Drupal, offloading things for other services for overall performance. And then finally some real-time and custom content updates on your website. So just to start off with a brief analogy. Does anybody know the origin of the Mississippi? Lake Ithaca? Close. So technically the origin of the Mississippi is Harpers Ferry in Iowa. But it's a little confusing because at this point it's already a pretty wide river. It's already a pretty active river. Technically it does begin in Harpers Ferry, Iowa. But even before that, runoff and lakes and streams and rivers and other tributaries all the way up into Canada even have contributed to the Mississippi to give a good start. At this point it's already a mighty river. In fact the name Mississippi actually means mighty river. So it's the mighty mighty river. But it's the ADM machine of rivers. But it's important to note that even though it's already a mighty river at the beginning at its origin it does become something even more powerful than the origin gives it. So this is a starting point we refer to often as the origin. And so then we talk about content inclusion from the origin. The waters at the origin of Mississippi are virtually the same as what flows out into the Gulf of Mexico as its output. But more waters contribute along the way. The Colorado River, the Arkansas River, which is the best river. Arkansas is already the best fan. I'm going to get that dig in. So other rivers and tributaries contribute along the way changing the volume, the flow, the ed, the overall composition of the very waters themselves of the mighty Mississippi. So how does the mighty Mississippi have to do with your website? So let's take a step back just a moment to define what a website truly is. In a very technical sense, a user makes through his browser or her browser an HTTP request to a web server. The web server parses the request, hands it off to other special handlers, maybe PHP or even Drupal. The web server sends back an HTML document or other content that doesn't have to be HTML. And the browser parses the response for rendering. So the browser executes JavaScript that it finds and any other content that is instructed to add. So going back to the very beginning, this is the official CERN website. When the web was launched, the very first website was recently, as of about a year and a half ago, uncovered in some sort of social archeology. And I can't imagine the number of doors worn while excavating this website. It was just a simple collection of hypertext documents that could be requested one at a time from a web server. There was no CMS, files were edited directly on the server using Emax. This was CERN's website. Nothing else was added to it. So the HTML document that was served from the website is actually what the end-user received. And so this is an interesting and very first website in existence wasn't found. CERN was really looking ahead. So editing files on a server directly through Emax, or if you want to be easy on yourself through Vi or, you know, honestly, let's face it now. That's that I need to work up here for my purpose. So that's all well and good for the first website, but you want to make changes, you want revisions, you want all the other things that offers. The website grows over time, and it's kind of unmanageable to edit text files. So there became, over the course of history, lots of different ways to assemble pages. So I'm going to talk about a few of these. Server site includes was a great step in the way of organizing your content. CTI or scripting languages like PHP gave way to the advent of CMSs, such as Drupal. There's other things, though, that can help build your page, and that includes client-side assembly. In fact, Drupal mentioned a lot about the importance of Drupal Lake in the future, allowing for big pipe, for instance. In fact, nothing new. Facebook makes any of it in some school, but it's been around for a very long time. It's just got a good time. So to start off with, show of hands. I'm just kind of curious who was around back in the day when SSI was the biggest way to, yeah. So it's a great component management system. It must protect files on a server that you edit, and you make the change once, and they figure it out where it's great. Server-side includes, for those that don't know, that the concept is simple. You have what looks like HTML tags. We'll put the vein in there to indicate that, or I'll have to say, I guess, to indicate that this is an include or some sort of get-conditional. It used to be a very common practice. It's now very infrequently used. But in short, it lets you take fragments of pages, including the HTML pages, and to build the whole page. So conceptually, it's actually still a very common practice. So employing the server-side includes pages might look something like this. Even though the technology behind it is somewhat outmoded and not really used in service anymore, the pattern should actually be very familiar to most people. The Drupal region block template system is really fundamentally no different than server-side includes. You've got the overall HTML page, the page template file. You have your region template file, maybe you have block template files, and so on. It's just a little bit more advanced implementation of SSI, in a lot of ways. So after a request was made, for instance, Drupal takes that request, builds a response paper going through the bootstrap process, and returns a full HTML document. In this particular instance, Drupal is what we would refer to as the origin, just like Carbous Ferry back then. So as far as the web browser's concerned, the HTML could have been dynamically generated on the fly. It could be served from a flat HTML file. It could be served out of memory, kind of. It doesn't really matter. In the end, what the web browser displays, it doesn't matter. So what's more is what's delivered to the user browser may be further changed by client-side activities, like AJAX calls, adding more content. JavaScript can show a high content on the page. There's also client-side assembly for JavaScript, and web sockets can work together to pull in additional customized page fragments. This is kind of what's referred to as a big pipeline. So then, what really is distinction? Why is Drupal not your website? So in a typical Drupal implementation, let's take a look. So notes containing articles, blogs, et cetera. Blocks can provide additional content on the page. Panels arranges content on the page. And this is kind of what we refer to as a typical Drupal website. Kind of probably the Drupal website, even though the thing that users are interacting with, which is the website, is not always directly Drupal. So it starts to sound like, well, is Drupal really my website? So just to make everything absolutely clear, so Drupal sends an HTML document. The browser receives the same HTML. That doesn't mean that something in the middle can't potentially change it, right? So if nothing changes at post render, then it seems like Drupal's page is your website. So in this, in the mathematical equation that I used for my theorem or whatever, what happens if X never changes? Drupal for all intents and purposes is your website. If X never changes, the equation seems like a constant, right? So what happens if the equation becomes variable changes? For starters, let's take a look at some of the different variables that might actually affect your website. Forens of scale are some big variables that frequently change what Drupal generates, and the final HTML document that the end user sees. Every method of page assembly has its costs. Because of this, you kind of have to think about how we want to architect the overall page or the overall website or a section of your website or whatever in which the end user interacts in order to make it as efficient as possible and build and maintain. Sometimes that means breaking things apart in components, which I'll talk about fragmentation momentarily. But, you know, every single thing seems to have a payoff with resource cost and resource retention is always a problem when you're dealing with limits or anything like that. So PHP execution is costly. It's just kind of the simple, you know, so we had PHP 7, you know, which gets really close to the machine code. It's going to be kind of costly to parse and turn PHP into something executable. And not to mention, Drupal has a lot of PHP models and, you know, millions of lines of code. So it does combat some of these performance issues with caching and other methods. So this slide here is our profile of the bootstrap process. Single page load. This is taken directly from Drupal out of work. I know this slide is very hard to read. The complexity should be pretty obvious. There's a lot going on under the hood. We're just a single page load in Drupal. So when we talk about scaling, Drupal, there's actually several things that we do just kind of commonly out of habit. It doesn't help. We put multiple web servers behind a single load balancer. We use cache layers like varnish. You can use Memcache or Redis for a lot of internal caches. All of these things sort of act like defensive linemen or bodyguards or kind of stand between an aggressive squad of users to protect the limited resources of the origin server. So here's the diagram of a very simple enterprise level stack. The final HTML document that you see there, that's the thing that's passed off to the vn user. The browser renders that. It might do some things to it later. I'm going to go down the road. Did this particular case, that final HTML document actually come from varnish or from a CDN? The varnish or a CDN originally pulled that in the load balancer going back to its origin to get the original content. In varnish, varnish or caching, it just says, hey, I reckon I have that request. This is what I got back last time I rendered that page. And I'm just going to give it back. It's a whole lot faster, and it protects resources on the server. So varnish caches is really typically the thing your users are interacting with. Not Drupal, varnish in this case. So really the request only goes to Drupal if the cache is invalid out of date or just simply not present. So in this case, the load balancer pixel web head is next called phpfzm or apache spawns a PHP thread through, you know, Mossegi or whatever power root setup is. And then Drupal renders the appropriate page. So in this case, Drupal is really back end. And this is the distinguish between back end development and front end development. This is truly back end of your DevOps step. And I say that it's the back end because Drupal is not always the last thing that affects or modifies the page. It is important to note that in the case of varnish configuration or CDNs, a lot of these requests can't be modified by Drupal because Drupal never actually recedes the response. So I kind of alluded to fragmentation as a way to sort of offload some of the performance of your Drupal CMS. And so I want to talk a little bit more about fragmentation. So Drupal does a lot of things, right? It's a content management system. It's a content management framework. Drupal manages users. It manages your primary content. It even manages the look and feel of your site. But it doesn't need to do everything for your website, nor should it. There's a lot of different ways to assemble fragments. And I'll go into some of these in detail. But this here is sort of the two most common methods of post-drupal render with fragmented pages as you've got inside where JavaScript is executing from the browser to go fetch additional content or change or manipulate content on the page. First is something like varnish and CDN which uses edge-side includes the simple things on the edge. Now I'm going to talk a little bit about the edge. I don't really have a good illustration for this. But if you think about the origin of the server the sort of the core of your content the edge is out here somewhere literally on the edge as sort of the last zane your content passes through on its way to the user before it leaves the the step. A lot of times this is varnish. Or CDN such as CloudFront and Opera. So there's a lot of content that might not actually originate at Drupal at all in fact other than just a simple reference to it at the presentation layer. It's actually very common to integrate pretty far your content on the client side. In some cases you might have a news website where you have breaking news. A reporter might be able to actually talk to a breaking news interface through his cell phone and how that is just a text box sitting somewhere that they could fold in either by varnish or CDN to insert that into the topic page. Another story I'd like to tell is for those of you that may remember several years back the client house was launched on Drupal 6 and then sometime later the way that the petitioner's website was built and that was built on Drupal 7 and these were actually disparate sites and an interesting thing about that is if you were logged in, let's say you logged in to the petition's website and you go to whitehouse.gov there was a little bar to kind of follow you around the site you didn't see that if you were logged in. Now ironically the actual web page that you were visiting for all intents and purposes as far as Drupal was concerned it wasn't an anonymous page the interesting thing is there was a tiny little edge side reference at the very bottom of the HTML that would include other content fragments from this Drupal 7 site and so what's neat about that is Occamon I front-ended the White House it would serve these anonymous pages that had absolutely no customer's content whatsoever and then if you were logged in and you didn't see that little blue bar following you around from page to page using edge side includes it would look, it would use ESI conditionals to look at your session cookie if you had a valid session cookie what it would do is make a request to a Drupal 7 callback some other menu book registers callback callback pulls up that session out of your cookie and it says Drupal 8 so interestingly enough those ESI fragments could also be further cached by Occamon and so what's happening is you're building a completely custom page for the end user using nothing but cached anonymous pages straight out of Occamon memory so that's kind of an illustration of how you can really gain a lot of performance by using edge side includes actual things actually at the edge so the content assembly is not actually done you know Drupal's done its thing it's just paged out and it's not complete it's going in fragments from other websites from other sources and it assembles these things on the edge and then delivers the fully-formed HTML document onto the user this is actually pretty common with a lot of other things too if you think about it user comments for instance is a great example Facebook social discuss there's a few others every website now likes to have the Twitter blog in the right realm of their site another great example is real-time scores if you've got a lot of sports websites breaking news alerts but if you think about it analytics and advertising these are all things that are part of your site's content that are assembled after they've worked so just a couple of examples of externally posted comments you actually have quite a bit of control over how they look up here Drupal comments require that the user is authenticated being able to offload comments to using a third-party system means that authenticated users aren't hitting your website every now and then it's kind of a constant performance right so if you can offload that to some other service you don't have to worry about it anymore if you don't have an anonymous content every single time you'll still get a lot of user interaction that you do with the commenting system so Drupal might correct the placeholder on the page for comments but it's not actually aware of any of the content contained in the final web page so this is part of your website but not part of Drupal so I've talked a little bit about the client-side assembly in fact Drew's mentioned this in his keynote yesterday morning when he talked about big pipe and some of the things that is exciting and new about Drupal Lake a lot of folks have been talking about headless Drupal and some of the benefits that that offers but quite honestly you could do that now even without Drupal Lake so it does go by a lot of different names depending on how much the page architecture relies on this strategy some people refer to this as single page applications some people call it big pipe you know just depending on how much of the page is actually a simple client-side so a couple of neat things that you can do to a simple page client-side when you want to talk about implementing real-time updates and by real-time I don't mean every second a piece of JavaScript just pulling some server that's not real-time it's close you have delay of one second you know that's kind of okay in a lot of circumstances but if you're watching if you're watching a sport you want to see the score update real-time so a thing that was introduced in HTML5 it's several years old now the WebSocket specification and there's a lot of tools and frameworks that actually implement good versions of WebSocket but essentially what a WebSocket is for those who don't know is an HTTP request it's open it gets open to the server and in normal cases you think of your web page it makes the request, the server, and the response back and closes the connection immediately in this case what happens is the response actually stays open so your browser is talking to some Node.js based scoring system constantly and it's just a pipeline that stays open and it uses virtually no bandwidth other than it usually may change that connection is still open but you can have something like half a million users connected through WebSockets and have virtually no resources going on at all then what happens is another Clipper score and somebody increments the score in this Node.js service and that pushes out to all half a million of your connected users simultaneously the updated score that gets picked up in a minute and immediately changes the page it's also very nice for those who do new websites especially on election nights you're not having to constantly pull some service because if you're constantly making a request to get nothing back and closing that request you still have a lot of HTTP overhead and hopefully somebody can help me out I forget the flow, I forget the author but essentially the request is the one I never made so WebSockets allows you to not make more requests for real-time content so in the past I've worked on a lot of support sites so live scoring is always a business rule that comes up it's very difficult to work with in the content of the group pool real-time is essential and I'm a joke that one second is not real-time a one second poll is not real-time there's a big concern between real-time and one second platforms so HTTP connection is possible like I said and this supplies to lots of other registers so WebSockets a very common framework is Socket.io this is just a little piece of JavaScript to show you Drupal may have a block that contains a piece of JavaScript that looks like this there's nothing in here that Drupal knows anything about other than it just it says to print this to the Web browser Web browser executes this JavaScript it makes a connection to Socket somewhere and that takes over from there Drupal never actually knows what's going on here in terms of content so I'm talking a lot about live scoring because that's such an obvious edge case so this is one more thing that you can offload to another server you have an API that exposes a score on we offload the fetch and the display of the scores to the client side that never has to get rendered in Drupal and never gets rendered in the page and never actually even gets rendered to the point where that's in varnish cache the worst thing you can do on a sports website by the way is cache any page that has scores all again you have some frustrated users going to so this lets the browser keep the user up to date but quickly offloads all the elements work where it actually belongs so I did talk a little bit about edge setting and I want to come back around to that so ESI is very similar the cache layer parses the content and assembles the full page based on the content of the reference fragments and ESI fragments are a very key feature of being able to make a performance on a website where the origin is Drupal so Drupal can actually generate these fragments for you so Drupal can generate the anonymous, the unauthenticated page that gets stored in cache and then all that Drupal really has to handle for authenticated users is generating these fragments so just like we do with other pages or other pieces of content whether that's HTML, whether it's JSON whether it's CSV, exports these paths can all be cached by varnish by the way you can also make references to external sites and external services as well so external ESI you can actually have users manage in a completely different space this means you can actually have multiple Drupal installs managing your one complex website so we talked a little bit about authenticated versus unauthenticated users so it's important authenticated traffic bypasses a lot of the caching layer that we've built up to protect all the resources that we have on the server so you can use ESI to provide a lot of customized service in an otherwise unauthenticated cache page unauthenticated page is heavily cached ESI lets you customize all the things that users are accustomed to be welcome to use your name here's a list of all your blog posts all of these individual fragments on the page can now be cached for that specific user no one else ever sees it the nice thing is if you're ever concerned by the way about the security of that because any action such as creating content, editing content removing, etc. would still have to go to origin it would still have to authenticate again so just because somebody somehow manages to get a cached page that says well, you're not Toby they click on that link and it's not going to give them access and think because this is just HTML it's not actually interacting with Rupal so here's a good example of that you can substitute varnish for Akamai, for Cloudfront any number of CCNs in order to manage the edge status and in fact, ESI has a standard that's put together by over a dozen different CCNs but varnish does have a basic implementation of it so it's very reasonable in this particular case, Rupal receives the request by varnish by an unauthenticated user and caches that page in varnish everybody gets a copy of the page no matter who you are then Rupal also gets a request at a specific callback path that says welcome to your name and varnish assembles this page and delivers the HTML document so I just wanted to kind of end with a couple of different modules and resources that might be valuable the CDN project is great it handles also a lot of moving of content to use the ESI project is a thing that lets you basically say I want this particular block to be served as an edge setting it also handles the callback for generating that fragment socket IO that's the name of the framework there's a web address and then there's the ESI that's in general there's the varnish cache website has some great documentation of ESI offline has a great full, very robust implementation I kind of watched two things a little bit so at this time I'd like to go ahead and open up the questions if anybody has any questions and we would talk implementation strategies it can be a kind of technical if you want to go over a particular thing and I think probably the best thing to do is there's no microphone in the middle there yeah, I'm using the microphone I'll turn the top really loud so how to actually implement that or is it something we want to do so the question is a lot of talk with Drupal 8 and maybe some of the headless Drupal and how to implement big pipe so there's a lot of ways to do it so one of the things in Drupal 8 obviously that everybody is excited about is headless Drupal being able to decouple the presentation from the content management framework entirely one way that you might go about this is using something like route subscriptions or the router system in Drupal 8 you can actually register a service through the symphony service you can register a service to handle building a lot of the different components that get included on the page so what you have is essentially I don't know let's talk about the user page for instance you go to your user page and it has a lot of placeholders in the user template file in that quick file with a lot of JavaScript it goes and makes references to all of these other fragments so the interesting thing is you can actually be looking at a page that's not generated by Drupal at all it's just a piece of HTML like a static HTML file for instance or something that's generated by a NodeJS that has JavaScript references to Drupal and so your event subscriptions for instance or your route subscriptions can actually have a callback that says alright this user is authenticated here's a list of his last five blog posts here's some profile information here's a list of people that he follows here's a list of people that follow him and fill that sort of page on the slide you could probably allow people to customize that in what powers you get to pull down so that's sort of a very top level approach of how you would go ahead and implement big pipe there's also some JavaScript frameworks that are coming out I think Facebook is releasing one that's kind of related to how Facebook is handling big pipe so just like years ago when CSS Frameworks started coming out to help handle grid systems there's going to be a lot of competing frameworks for big pipe as well yeah the question was were Okamai and Varnature applied to DSI? yeah so they applied to DSI so in the case of what I also gave you earlier Okamai front ends the entire collection of websites and in this case you visit a page you're not locked in and you get this page so there's actually DSI fragments contained in that page and so the page that gets sent you never actually see the page that gets sent that goes to Okamai processes that page DSI fragments in there there's some conditionals based on hey does this person have a session cookie what's the value of that session cookie and then it makes a request to a different people site like I believe the people site and that request is very specific to your sessions so it will be something like slash DSI slash user slash the session number so the very we need cash that we need cash so that fragments cash the output of that the output of that call back to people generates is just a welcome user link to the profile and maybe a list of what the last competition is on and so what Okamai does in this particular case is it has an DSI conditional but do we have a valid session cookie if yes go and make a request with that fragment if it already has that fragment and it's on cash then it loads it out of cash it doesn't go back to people to be working in generative and then insert that all so you're assembling this page column head the people site doesn't know that you're logged in and set that over here does that make sense ok so are you saying that then the session cookie becomes part of the cash key the content is cached with the URL and the session cookie so the question is does the session cookie have a rolling in that so the the value of the session cookie is just the hash and it's not even actually the session value per se that request is actually part of the session value the session cookie value so what happens is it'll reach the generic callback that paper session and it's not actually the paper session they've actually got a custom hash value that corresponds to a particular user just so that they're not it loses a chance of session hijacking but what happens is it's got this session value and it does a couple of things like is this user actually authenticated are they an active account etc etc does that go back to both to check whether it goes back but it goes back to the people website and not the actual live white house site so optimize front-ending the group as well it front-ends the white house site and then goes and pulls, makes a request to this other with the people site over here for that little fragment to insert so that fragment is not actually a hash so interestingly enough it's not nice to put time but after the request was made because it's such a unique ID and it is tied to a user in that that token gets destroyed and we'll use a lot of that the results of that ESI fragment request are actually hashed so what happens is it's already generated how it goes on a hash you're all making a wrong request for that session it's just like with any other session channeling it was a way to kind of unify that path since most varnish and cdn caching a couple instances of running Acquia servers and sharing environments and we're using varnish through SSL we also have a combination in one instance of SSL sites SSL and so on one same server we have to be able to really find any clear documentation in terms of if pentash is an issue in that kind of situation in terms of caching information we wouldn't want to have cached do you know of anything like that? so you're on a shared hosting setup with multiple sites some are HTTPS and some are HTTPS and so the question is do you have problems with pentash caching things you don't necessarily want to I'm not entirely sure which things you've written what cached but pentash is going to be agnostic to whether the site is over SSL or not and in fact I think probably what's happening is I'm guessing it's a load balancer SSL permanates there and all requests that we go through to Drupal either all HTTPS or HTTPS and it just happens to know that it's behind a proxy so it generates everything accordingly probably it's passing on an SSL header to make a request so in that case Memcache is not going to be aware of how the request was made what gets cached in Memcache is likely going to be just like it was over you could probably like in Drupal 8 you can control a lot of that with cached tags and things like that in Drupal 6 or 7 you're going to have to manipulate the cached ends you'll probably create a custom bin and kind of pick and choose and cherry pick what goes in there based on the sensitivity of the content that's going to be sort of irrespective of how the request was actually made second so a lot of discussion about headless Drupal the approach taken is the scope of SPDI and liver content that will make sense to me if you're receiving that in-ponent browser and it's going to be rendering in some way a lot of it so so you're asking about how headless Drupal and how some of these other page assembly techniques interact I'm just going to ask you that how does Drupal interpret that as the rest of SPDI that's the sort of line exactly with these tools ok so the question is so headless Drupal is designed to deliver its primary access content is something other than this html document it might be manipulated on the edge to actually include it to reverse our analysis so that's a very good question it's going to be a slightly different technique so what you may actually have is in this case Drupal is definitely not the website you may have the thing that you kind of concept to think of is the origin of your website it's not actually Drupal at all but it might be something like NodeJS which is using j to generate templates so the actual markup begins here and not over here in Drupal so you have something like a NodeJS service where you're actually managing your primary content and you may be using Drupal for things like user authentication and for other auxiliary content or you may have a massive selection of services and Drupal is just handling things like statistics or other like any really good example about my head but so this other thing over here might actually be the origin of your HTML document that's delivered to users and then it makes a lot of requests to this headless Drupal over here and it says hey I want JSON export of all of your of all the content you have related to this particular this particular taxonomy term and something that gets generated via JavaScript and maybe pulls some of that stuff over to AJAX or whatever and builds that on the edge into the page so definitely definitely in that case Drupal is not going to be the origin of the HTML document but it might actually be the origin of all your fragments to get included into something else that's building your HTML document does that help her? Yeah, we're used to we're also on this content offering system in which the content gets created with markup right there's new things being launched there's markup in it gets reassembled and we'll create that content with some template and can you make it work? Yeah, so in your content management system in Drupal you've got a lot of marked up content already like the body of no for instance maybe marked up already it's going to have a lot of HTML but by itself that body is really just a fragment of an HTML page so in that case you may use Drupal as a way you may use the Drupal 8 LizzyWig to mark up the body content and then you may use HeadlessDrupal to transport that and a bunch of disparate fields via JSON to some other service that gets assembled either client side through a big pipe or maybe it has individual fragments of that article that you're interested in displaying as ESI fragments that get built on the edge but I think for your interesting line are probably going to be a little bit more client side assembly rather than edge side assembly JavaScript would let you be able to kind of pick and choose a little bit more granularity customized to a particular user because you can actually go to HeadlessDrupal, get a request of all that user's preferences in JSON and that's sort of the page level bootstrap so you're actually maybe looking at something like a single page application where that page is loading pieces of the page based on user activity you click on something and it doesn't actually reload the page it actually just rebuilds the page to mark out their requests from your drippling space