Other benefits to modern SSR (that isn't SEO)

The first web application I ever built was a private member management platform for a non-profit organisation. The tech stack was monolithic - a Flask server that responded with HTML over the wire, Jinja being responsible for templating. Later I learned how to use Svelte, and so my second application consisted of a RESTful Flask API with a Svelte frontend. It too was a private platform, many private platforms would follow. This sets the stage for my reaction to the initial development of SvelteKit, which the masses hailed for its SSR capabilities which improves SEO, or Search Engine Optimisation. “Who cares?”, thought I, who maintains no public sites. The whole point of everything behind a login screen is that you don’t want any public traffic trawling the content.

Some time later, I was tasked with building a backend for one of our client’s ecommerce platforms. They had an existing solution that was powered by WordpPress and an amalgamation of plugins. Ultimately, due to unoptimised SQL queries, the old site would often bring a rather beefy EC2 instance to its knees. We had the opportunity to build something from the ground up. The site sells tickets for events, so we needed to come up with a solution to render tickets after payment has been received and make them available via download or email.

We decided on an asynchronous Python powered REST API in conjunction with a Svelte frontend (which was basically a SPA with client side routing), styled with TailwindCSS. At the time, I believe SvelteKit was still in beta. I needed to figure out how we were going to generate the actual, printable tickets. Keep in mind that we needed to develop loads of other important facilities such as order handling, payment integration, potential conflict resolution etc. I briefly considered rendering bitmaps programmatically, pixel by pixel, with something like Pillow - but then I would be responsible not just for the information ending up on the ticket, but what it looks like as well. I’m not a graphic designer, so that would go bad. We needed an easy, off the shelf solution. Enter wkhtmltopdf.

wkhtmltopdf is basically a headless browser technology that can take HTML, CSS and JS as input and output PDF files or images, via command line. There are also wrappers available for it in the Python ecosystem. Since we already have a firm grasp of the aforementioned frontend web basics, this provides a route with low friction. Nobody needs to learn anything new, we can just build regular web pages and output a printable file. The initial proof of concept was done by retrieving a HTML string from a dynamic Jinja template and passing the result to wkhtmltopdf. This worked swimmingly with one minor hiccup - of course Tailwind class directives would not magically enforce styling without passing the post-build CSS file contents alongside the HTML. Do we add yet another build step to the backend with NodeJS as a dependency? It was bad enough that the team responsible for UI, usually familiar with the Svelte code, had to navigate the backend repository to maintain a separate, smaller UI [1].

We decided to bite the bullet and just write plain CSS within a <style> tag in the template. This introduced a bus factor since we had several people on the team who could passably style content using Tailwind, yet only one person who could consistently work the old magic (thanks, Shane!). With that, we had a working solution at the cost of terrible maintainability. Everyone dreaded touching the ticket generation system, it was finnicky. For the digital page to correlate to a printable physical paper size, everything had to be just right.

Fast forward a year or so and the stakeholders requested changes to the ticket. I opened up the somewhat dusty code after having worked on untold other projects and domains and look upon our “art”, depending on who you ask. The change request requires data that is not being injected into the template context at all. Logos need to move around. “I hate this”, I probably mumble to myself. Then the realisation hits me - we already have a perfectly functional UI, written in a templating language that everybody understands. Of course, it being a SPA, the browser does a lot of heavy lifting in rendering the page. Send a request using curl to one of your allegedly beautiful SPA routes/pages and you’ll mostly just see tags like <head>, <script> and <nope> and, to the untrained eye, mere garbage. A funglebungle of eager-to-be-invoked JavaScript that never executes. You stare at it, it stares back, all just whispered, empty promises.

At this point in time, SvelteKit is very much production ready, so I do a small proof of concept that verifies that a raw response does indeed contain page content and not just obscure references to page content, so I started the code migration. A day or so and a couple of regex based find-and-replace operations on keywords later, I was done. SvelteKit uses folder or directory based routing structure, so I decided to scaffold my ticket template in a sort of _super_secret directory. We don’t want just anyone to be able to access this page, else you could counterfeit tickets quite easily if the backend does poor validation on ticket scanning (ours doesn’t, but still it might look legit to a human). This way, we can instruct the reverse proxy in production to route all external requests to https://ecommerce.site/_super_secret/free-template to /dev/null or whatever digital hellhole we prefer. Brilliant! The template can be accessed from the backend via an internal network HTTP GET request, with the relevant event data being populated via simple URL query params. I was ecstatic. Now, we could maintain all UI related code in one place and we can style it however we like, as long as we also retrieve the related CSS files. wkhtmltopdf will by default follow any <link> URLs, so that leaves something to be said about memoizing some expensive requests to use the template at scale.

TL;DR - Modern JS frontends are a great way to templatise anything from web pages to HTML emails or anything else you might show to an end-user. This is much more accessible to teams than traditional backend templating, since nowadays you can’t throw a stone without hitting at least 3 React developers. If you have a separate frontend, don’t unnecessarily render HTML on your backend.

[1] - You could argue that an event ticket is not a UI, but this platform’s in particular contains a scannable QR code. Checkmate.