blog.somewhatabstract.comsomewhat abstract – but mostly…

somewhat abstract but mostly… Menu and widgets Somewhat Abstract About Me Disclaimer Terms of Service Privacy Policy About Our Cookies Short Stories Hell and Hot Chocolate Pie and Pirates GitHub LinkedIn Trello StackOverflow RSS Soundcloud Spotify LastFM Mastodon Twitter Instagram Facebook Page YouTube Recent ??‍? Render Gateway: A Multi-use Render Server ? React Hydration Error Indicator ? Debugging and fixing hydration issues ? Setting up Dependabot with GitHub actions to approve and merge ? Hydration and Server-side Rendering Search Search Tags .NET AngularJS Ann Arbor Blogging C# C#6 C#7 CodeMash Conference Debugging DIY Exceptions Family Friends Gardening Git GitHub Gratitude HTML Jasmine JavaScript KalamazooX LINQ LinqPad Love mstest Music NodeJS Poem Poetry Productivity React Server-side Rendering SSR StackOverflow Syntax Testing Tools Unit Testing Unit Tests Visual Studio Windows Work Writing xunit Copyright © 2023 Jeff Yates. All rights reserved. This is my personal blog. Any opinions presented here do not necessarily represent those of my employer or any other entity. ??‍? Render Gateway: A Multi-use Render Server Photo by Nikola Knezevic on Unsplash This is part 11 of my series on server-side rendering (SSR): ??‍♂️ What is server-side rendering (SSR)? ✨ Creating A React App ? Architecting a privacy-aware render server ? Creating An Express Server ? Our first server-side render ? Combining React Client and Render Server for SSR ⚡️ Static Router, Static Assets, Serving A Server-side Rendered Site ? Hydration and Server-side Rendering ? Debugging and fixing hydration issues ? React Hydration Error Indicator [You are here] ??‍? Render Gateway: A Multi-use Render Server Way back in January 2020, I started blogging about server-side rendering (SSR) React. I intended it to be a short, four post series that would go into the details of what SSR is, how to do it, and the pitfalls that lie within. This is post eleven of the four post series, and perhaps the last (at least for now). Over the course of the last ten posts, we have created a simple React app that server-side renders and successfully hydrates. Along the way, we have learned about the complexities of server-side rendering and hydration, and from this we can identify some important lessons. The initial render of client and server renders must be the same for hydration to be successful Maintaining a server-side rendering solution can become complex, especially as the app itself becomes more complex (and it doesn’t help that React only reports hydration problems in its development build until React 18) Reasoning about an app to ensure we consider both the server-side and client-side behavior can be a pain We cannot change the first point. In order for the hydration to be successful, we need our initial render to be the same on both client and server. To achieve this, we need to understand how our code will render in both contexts. However, with some clever components (and hooks, in some cases), we can simplify things to reduce the impact of the other two points. There are frameworks available such as NextJS that provide these features for us. However, I find great value in understanding the complexities of something to grasp exactly what tradeoffs third-party solutions are incurring, and at the time I was working on the SSR solution for Khan Academy, moving to NextJS was far too great a lift. So, in this series we have rolled our own solution. First, by using components like WithSSRPlaceholder in Wonder Blocks Core, we abstract away the general complexity of understanding the process of server-side rendering to ensure our result hydrates properly. Second, by testing our code in development in diverse browser environments we can check for things that often cause hydration errors (such as browser feature detection being used to change what gets rendered – remember, the server has no idea what the user has configured in their browser, what their screen size is, etc.). Finally, by changing the server-side rendering solution from one that knows lots about our frontend code to one that knows as little as possible, we can build a server-side rendering approach that will work without needing to be redeployed every time we change our frontend. And that is where we are heading in this post as we created such a server to perform server-side rendering at Khan Academy. Goliath and the Render Gateway For more than two years, the Khan Academy backend that underpins our website and mobile apps has been undergoing a major re-architecture. We named this massive project, Goliath – part pun on the new backend language we had chosen, Go, and part pun on the absolutely colossal amount of work we had ahead of us to get the job done. You can read all about it in these posts on the Khan Academy Engineering blog: Go + Services = One Goliath Project Half a million lines of Go Technical choices behind a successful rewrite project Beating the odds: Khan Academy’s successful monolith→services rewrite The re-architecture was a big project, made ever more complex by the need to keep the site running smoothly for the millions of folks that rely on us as we transitioned things off the old architecture and on to the new, piece by piece 1 . As part of this re-architecture, we knew we needed to change the way our website was served and so I, along with the amazing team I work with, were tasked with creating a server that would render our web pages. We made a variety of decisions to simplify the work and to simplify maintenance long term: We would only support rendering pages that used our latest frontend architecture Supporting legacy tech-debt laden code would only perpetuate problems and would most definitely increase the complexity and volume of work to be done. By using our current frontend architecture, all the information about the site, including what page to render for which routes, would be codified within the frontend code. We would get it working first and get it working fast second While we made decisions all the way through to avoid performance issues, we also deliberately avoided making any performance optimizations before we knew what a working solution looked like. And we took measurements – always take measurements before and after when you are making performance improvements. We would make it generic enough to cope with the multiple changes we make to our frontend each day. We deploy many times in one day to fix bugs and release new features. Our engineers work hard to make these deployments invisible to users and we wanted to implement a solution that would support that effectively. Our strategy was to get something working, move eligible routes over to that something one by one, and make incremental changes as we went to improve performance and fix bugs. We knew up front that we would be using an edge cloud platform like Fastly to route the traffic and ultimately provide caching for our SSR’d pages, so we made sure that our design incorporated support for things like the Vary response header to support efficient caching (though we did not use that to begin with, no premature optimization). We went as far as including code in our frontend that could track what request headers were used by a page rendering so that we could build that Vary header with a view to utilizing it once we were at a stage where cache optimization made sense 2 . After a little back-and-forth we settled on a name for this new approach to rendering our website; the Render Gateway. What we did We spent quite some time building the main Render Gateway code, solving many problems like: How do we know what code to run? How do we build a result that the cloud edge service can understand? What does that result look like? Many test implementations were stood up as we added more features, including the ability to: Verify incoming requests so that we can immediately throw away spam Add different status values and headers to the...