I first read about islands architecture when I was trying Astro for a project. Astro was still new at the time, but the idea made sense to me. If you ever used WordPress, the idea is familiar already. You have a page, you drop widgets into it (a comments section, a recent posts list, a search bar). Each widget does its own thing, does not interfere with the others. Islands architecture is exactly that mental model. Except instead of generating all the widget JavaScript upfront, you delay each one. The WordPress comparison Think of a typical WordPress page. The header, the article body, the footer (all rendered as plain HTML from the server). Then you have widgets in the sidebar: a search box, a tag cloud, a newsletter signup. Each widget is self-contained. You add it, configure it, and it renders in its own little box. Now imagine instead of shipping jQuery and all the widget scripts on every page load, you tell each widget: "hydrate when you are ready." The search box hydrates immediately because users might use it. The newsletter widget hydrates when the browser is idle. The tag cloud (maybe it does not need JavaScript at all,...
This is part two of the stack write-up. Part one covered the technical side: frontend, UI, content API, database, auth, uploads, deployment, and tooling. This post is about the operational decisions that sit on top of that stack: how the inquiry flow actually works, why I lean on CloudFront cache, the SLO and SLA I am willing to commit to, and the disaster recovery plan. The shape of the project The website is for a brick and mortar business that needs a proper web presence. The goal is quite practical: Show catalog items, services, and offers clearly. Let staff update content without touching code. Let customers send an inquiry with enough details. Generate a reference code so WhatsApp discussion is easier to track. Keep the system small enough that I can operate it myself. That last point is important. I do not want to run a big platform for a small business website. I want something that I can understand when it breaks. Inquiry flow: form, database, WhatsApp The inquiry form is the main conversion feature. Customers can choose catalog item, offer, service, or custom request. They can fill in quantity, size, option details, deadline, urgency, delivery method, contact details,...
I have been building a website for a brick and mortar business recently. It is not only a brochure site. It has catalog pages, offer pages, an inquiry form, staff admin panel, image upload, lead dashboard, and WhatsApp handoff. The project is split into two repos: one repo for the public website and admin UI one repo for the content API, database, upload, and inquiry backend I want to write down the stack while it is still fresh, because I know I will forget the small decisions later. This is not a "best stack for everyone" post. It is just what I use, what problem it solves, and why I am okay with the trade off. This is part one. I will cover the technical stack: frontend, UI, content API, database, auth, uploads, deployment, and tooling. Part two covers the operational side: the inquiry flow, caching decisions, SLO/SLA, and disaster recovery. Frontend: TanStack Start The frontend is built with TanStack Start, React 19, TanStack Router, and Vite. I picked it because I wanted server-side rendering, file-based routing, and normal React without going too far into a full framework that hides too much. The routes map quite directly to the business:
← All tags
