RUG::B

I recently wrote an article about multi-arch docker images and I could try to rework this into a presentation.

Extending on this I could provide a tiny intro on docker images in general, so we understand better how it fits into the registry part.

So a rough outline: - What is this docker thing again - How to build a docker image - What's in a docker image - How and where to store and fetch the images - How does the registry work

For a 20min talk this would only scratch the surface, so don't expect a deep dive into all the inner workings of the docker ecosystem. I only look as far as I need to, to understand and help me with my problems.

Historically, the worlds of on-demand server-side rendering (SSR) vs. static site generation (SSG) have seemed far apart. You can use one type of tool, or the other, but not both in a single codebase with a simple set of techniques to make effective use of both approaches.

However in recent years, we've seen the rise of the "Jamstack" and a new generation of JavaScript-based tools which claim to solve this problem once and for all. Great news! Or is it? Nope, because then you must write everything in JavaScript (or TypeScript). That leaves…well…everyone else out in the cold.

As Rubyists, it's time to think outside the box. In Bridgetown 1.0 and soon 1.1, we're doing just that by marrying a next-generation SSG with full-featured SSR thanks to deep integration with Rack & Roda, the fastest Ruby web framework (lovingly maintained by Ruby legend Jeremy Evans).

In this talk, I'll showcase some of the aspects of what's possible in Bridgetown when on a route-by-route, page-by-page, and even component-by-component basis, you can decide if you're SSG'ing or SSR'ing your content. Then I'll show you how simple it is to deploy this hybrid architecture on Render.com via a Blueprint YAML file containing only a few lines. Is this truly the best of both worlds? Are SSR & SSG friends for life? Let's find out!