[Go Make Things] The different ways to build a resilient website or web app

By rahmat hidayat

Thursday, May 30, 2024

​ Yesterday, I talked about how your site should work without JavaScript. Today, I wanted to talk about some different approaches for building a resilient website or web app. Let's dig in! Static HTML The most bulletproof way to build a site that works nearly 100 percent of the time is to serve flat, static HTML files. That means that when the user visits my-awesome-website.com, the server returns an index.html file with all of the content for that page already generated ahead of time and ready to view. With no database to query in real time, and no backend that has to run and compile the HTML, there's almost nothing to go wrong. Any issues that could happen to break your site would happen in transit (a dropped internet connection, for example). This approach also benefits from being really fast. Because the server doesn't really have to do much work, it responds nearly instantly. And as soon as the HTML shows up, the browser can start displaying it to the visitor. It also dramatically reduces the load on your server (and the associated costs and security concerns). You'll use less memory. You'll require less storage. There's no database to hack. There are a lot of upsides. Of course, this approach only works if the content you have can be pre-rendered. It works best for content that's the same for every visitor. Server-Side Rendered HTML Server-Side Rendering, or SSR, is when the user is sent a fully rendered HTML file from the server, but that file is dynamically generated on the server when the user requests it. This is how CMSs like WordPress work. When the user visits my-awesome-website.com, the server grabs some template files, grabs some data from a database or API, and combines the two into an HTML file. Then, it returns that file with all of the content. Your backend language could be Node, Go, Ruby, .NET, or even trusty old PHP. This approach works best when you have content that's customized from one user to the next. HTML generation is nearly always faster and cheaper (for the user) to run on the server. They get back an HTML file that can be instantly rendered in the browser. The downside of this approach is that it does put more of a load on your server, but that's a worthwhile tradeoff for having more dynamic content that's still quite resilient. A hybrid approach I've recently stated using an approach that combines both of these techniques. I use a Static Site Generator (or SSG) to create mostly flat, static HTML files. But for pages where I need to customize content for a user, I instead have it render out an index.php file for server-side rendering (you could use any language you want, really). Most of the index.php file is static HTML, but the dynamic bits use backend rendering to generate the HTML on the server. I can even use this approach to restrict access to certain pages altogether based on logged-in status or user roles and permissions. This approach results in faster, more resilient pages than 100 percent SSR would, but with more dynamic, customized content than plain old static HTML allows. What about dynamic user interactions? Tomorrow, I'll share how I handle interactive UI using this approach. If you're trying to figure out how to implement approaches like this with your products, get in touch. I advise a wide range of clients on how to build faster, more resilient sites and apps. I'd love to work with you! Cheers, Chris ​ Want to share this with others or read it later? View it in a browser.​ ​

Did someone forward this to you? Get Daily Developer Tips.

Don't want to get these emails? Totally cool. Update your subscriber preferences.

You can also unsubscribe from all emails from me, including updates to products you've purchased.

113 Cherry St #92768, Seattle, WA 98104-2205

Share :

Facebook Twitter Google+ Lintasme