Migrating to Netlify, One Page at a Time

[Music] hello jam statcomp i'm excited to talk to you today about migrating your website to netlify one page at a time my name is taylor mcdonald i am partner and cto at ample we're a jam stack focused digital agency located in downtown cincinnati so by now you're already familiar with the advantages of the jam stack security scale speed and developer experience but if you're dealing with a monolithic application one that's probably been around for a few years migrating your site to this new modern architecture can feel a little overwhelming so today i want to focus on the least painful path off that monolithic app and onto the jam stack something i like to call gradual migration now this strategy simply refers to standing up a new site and selectively moving over pages one by one over time now when i say page i'm referring to any accessible path on your site the benefit of this strategy when compared to other approaches like a big bang cut over for example is that it carries much lower risk for your organization and allows you to ease into the new solution at your own pace while paying down technical debt as you go let me show you how it works so imagine this is an illustration of traffic coming into your website you've got ninj user on the right making connection to the site on the left let's also consider that each page or path on your site is represented by this little html icon now building on this analogy we imagine more users and more pages obviously this is an oversimplification but let's assume that the engine powering the creation of these pages is a monolithic framework like drupal wordpress or magento now the first step towards gradual migration is to stand up a new site and stick it in between the end user and the old site you can see our traffic patterns haven't changed here they're now just being routed through this new system before they get passed off to the old site then starting with the highest priority pages we're going to move those over one by one to the new website now any pages migrated to the new system will be served from there and any pages not yet migrated are going to remain where they are served from the older system now the critical takeaway is that as traffic comes into the new site it's automatically passed through to the old site as necessary so eventually once you've migrated everything over there's no more traffic being routed back to your old system you can dismantle that infrastructure and call it a day now let's take a look at a real world example so let's pretend that we're going to redesign jamstack.org now the first thing i'm going to do is create an index.html file now there's nothing special about this file i'm just going to paste in some markup basically a logo and some links and then i'm going to create a text file called underscore redirects now inside this file i'm going to put a single line of code which will tell netlify how to route traffic relative to the pass-through pattern that we just discussed okay and now i'm going to use the netlify cli tool to link this project up to a nullify site that i've created earlier okay and then i'm going to use the same cli tool to deploy this project directly to the cdn okay it should be done now let's open this up in a web browser okay so you can see my html rendered here now don't judge my design it's just a proof of concept after all obviously there's nothing special here but check out what happens when i start clicking through the navigation the first thing you'll notice is that when i click on links for pages that i haven't created yet i'm not getting four or four responses from the server i'm actually being served content from the site that we specified in our redirects file also notice the hostname didn't change as far as the end user is concerned this is just one big website okay so what just happened by adding the redirect file to our publish directory we told netlify to serve physical pages that were deployed to the cdn first and then for any request it can't handle instead of returning a 404 to the end user we're going to pass that traffic off to jamstack.org now remember the navigation continued to function across both sites the hostname didn't change regardless of whether i was on my new netlife project or i was on jamstack.org now we've got a solution that will allow us to selectively override individual pages at our own pace so how exactly does this work well it's all thanks to this thing called the reverse proxy now not surprisingly a reverse proxy is the opposite of a forward proxy a forward proxy is designed to hide the client's identity if you've ever used a proxy server to access a youtube video from another geographic location for example then you know what i'm talking about so if the forward proxy shields the client from the server the reverse proxy pattern shields the server's identity from the client it's a simple concept but it gives us a ton of control over handling our traffic now i should note that this pattern is not unique to netlify they just happen to create a super elegant solution for the implementation of the same concept now sending users to different applications based on the request is trivial and this approach can even help us defend against things like ddos attacks and since the server side details are hidden the end user has no clue that they're accessing a completely different website the hostname never changed and also we can keep our redirect rules in the repository so we get the benefits of visibility revision control and our team now has access to manipulate traffic patterns right alongside our code and once we got this solution in place we can start talking about even cooler concepts like microfrontends so what the heck is a micro front end well the idea of microphone in architecture really has more to do with how you structure your teams than anything in the interest of time i'm not going to be able to dig too deep into that concept but i would like to illustrate how this plays out architecturally so following our early analogy let's say that this is an illustration of web traffic coming into your website you've got some products for sale a blog maybe a handful of other random marketing pages let's also assume that these pages are driven by one big monolithic application that does everything and now that we know how to proxy web traffic under a single host name we can start applying the same strategy here so instead of one big application we can start thinking about our infrastructure like this where each distinct section of our website is a different application entirely the end user still just sees a single hostname and can traverse the entire site as if it were just one big project but now we have greater flexibility to evolve our infrastructure over time and the cool part is is that since the kpis and ux concerns for a blog are distinctively different than e-commerce for example we can assign ownership of each application to different teams who have the skills to meet those objectives and since these are all individual projects we don't have to worry about teams stepping on each other's toes we can deploy at will or we can use different technologies that may be better suited for the needs of that particular team so this is great especially because now we know we can accomplish this level of flexibility with a single line in a text file but the solution is not without its challenges either so probably the first thing you'll notice is that page speed specifically our time to interactive metric takes a slight hit with this strategy now the severity of this problem will scale depending on the choices you make and how many different frameworks you're using now while some of this is accepted risk there's a few options available to us performance budgets are a great first step particularly when plugged directly into your ci pipeline there's a ton of benchmarking tools that can deliver near real-time feedback for your qa team so you can ensure that any updates keep page speed within an acceptable range if you're using a module bundler like webpack or parcel you're going to get code splitting for free and now that http 2 is a thing this approach dove extreme dovetails extremely well as it encourages smaller bundles delivered to the client on an as needed basis lastly consider vendoring shared libraries or packages together so you get the benefit of cachability while also reducing the footprint of any one endpoint second challenge how do we ensure the products present consistent user experience well we could start by implementing a global style sheet across everything this is a good idea for baseline styles but in practice this approach gets pretty brittle pretty fast there's also this idea of server-side page composition and there's a couple node.js projects to address the need podium and single spa are two such examples now these solutions require a node process to work so while it's not really jam stacky i figured it was worth a mention lastly the solution we found to be the most scalable is this idea of js-based component libraries you can keep your markup style and functionality all in one place and reuse it everywhere there's a lot of benefits to this approach everything from tooling to automation to maintainability it's also a great segue into the concept of design systems which you could think of as a single source of truth for your user interface now lastly you may need to deploy your work to several different environments staging qa production etc as revolutionary as deployment previews are some clients aren't quite ready to make the jump to a true continuous delivery environment and while i love the redirect solution that lfi is engineered it does have some limitations particularly if you need to swap out redirect rules based on your environmental context so one option is to maintain a copy of redirects for each environment and swap them out at build time another idea is to create a simple bash or set script that could rewrite that field file at build time and we found both of these approaches to be a little clunky so we came up with another solution custom build plugins of course this only applies if you're hosting via nullify now meet the newest member of the official netlify plug-in registry netlify plugin replace now this is actually just a glorified string replacement library for environment variables but allows you to swap out these types of values post build before your project is deployed and this example shows the syntax for specifying variables inside a redirects file but it's configurable too if you don't like this format check it out in the netlify admin ui or visit us at apple.co netlifepluginreplace to learn more and that's it thank you so much for your time to learn more about any of the things i've covered today please come visit us at ample.com you

Channel: Jamstack TV

Views: 1,401

Rating: 5 out of 5

Keywords: Jamstack, static site, virtual conference, jamstackconf, headless cos, netlify, web development, conference talk, webdev, monolith, developer experience, legacy application, legacy infrastruction, technology migration

Id: 4K4_5yLLqzM

Length: 9min 56sec (596 seconds)

Published: Tue Oct 06 2020