Showcase /
How this page got to you
Follow a request from your browser to this page, then see how a change to the code reaches the live site. The diagram follows along as you scroll.
THE REQUEST · 1 OF 4 · YOU
You typed sanders.email
Your browser asks DNS where sanders.email lives and gets back one IP address. It's the same address everywhere in the world. Google routes you to the closest edge.
THE REQUEST · 2 OF 4 · LOAD BALANCER
The load balancer
Google's load balancer handles the encryption (the padlock in your address bar), soaks up junk traffic, and sends each request where it belongs: pages to storage, anything interactive to the API.
Why not A server running nginx means patching it, renewing certificates and guessing capacity by hand.
THE REQUEST · 3 OF 4 · CDN + STORAGE
Pages are stored as files
Everyone sees the same pages, so they're built once and stored as plain files, cached close to you. Nothing has to run to show you this page.
Why not WordPress or a server-rendered framework adds seconds and a machine to keep alive.
THE REQUEST · 4 OF 4 · CLOUD RUN
Interactive parts run on a small server
The contact form, view counts and demos like the authentication page go to a small Python API in a container. When nobody's using it, it scales to zero and costs nothing.
Why not Kubernetes would mean running a whole cluster for one small service.
THE PIPELINE · 1 OF 4 · MERGE
A change is merged into main
Merging a change into the main branch starts the pipeline. Nobody logs into a server.
THE PIPELINE · 2 OF 4 · BUILD
Cloud Build tests the change
It builds the site and fails the build if any page gets too heavy or breaks the design rules. Then it runs the API tests and builds the container.
THE PIPELINE · 3 OF 4 · SHIP
The files and the API ship separately
The site's files sync to storage with caching rules. The API container goes to Artifact Registry.
THE PIPELINE · 4 OF 4 · RUN
Cloud Run switches to the new version
Cloud Run moves traffic to the new version once it's healthy. Rolling back is one command.