What Changed in These Pushes
The first push went to madsnorgaard/drupal.madsnorgaard.net, moving HEAD to commit ac69e6bd. This is the Drupal 11 backend that handles content management and exposes data through JSON:API. The second push hit madsnorgaard/madsnorgaard.net, advancing to commit 60c9e767 on the Nuxt 3 frontend that consumes that API and renders the public site.
These are incremental changes - not a major feature release, but the kind of structural work that keeps a headless CMS setup running cleanly. When you separate your content layer from your presentation layer like this, both sides need to stay in sync. A change to how content is modeled in Drupal often means a corresponding update to how the frontend fetches and displays that content.
Why Two Repositories Matter
Running a headless Drupal site means maintaining two distinct codebases. The backend repository holds the CMS configuration, custom modules, and content architecture. The frontend repository contains the Vue components, routing logic, and API integration that turns JSON responses into rendered pages.
This separation has real benefits. I can iterate on the frontend without touching Drupal, or adjust content types in the CMS without redeploying the entire site. But it also means thinking about the contract between the two systems. If I change how a content type is structured in Drupal without updating the corresponding fetch logic in Nuxt, the site breaks.
That contract lives in the JSON:API layer. Drupal exposes content entities as JSON, and Nuxt consumes them. When I push changes to both repositories on the same day, it usually means I am making related adjustments - updating how something is structured on the backend and how it is consumed on the frontend.
Development Workflow for a Headless Stack
The workflow for changes like these is straightforward but requires discipline. I work locally on both repositories simultaneously. Changes to content types or field configuration happen in Drupal first. Once those are committed and the API responses look correct, I update the Nuxt side to handle the new shape of the data.
Testing happens in stages. First, I verify the Drupal JSON:API responses directly - hitting the endpoints in a browser or with curl to make sure the data structure is what I expect. Then I run the Nuxt development server and check that components are rendering correctly. Only after both sides work locally do I push to the main branches.
This approach minimizes the window where the live site might be out of sync. Because both repositories deploy independently, there is always a brief moment where one might be ahead of the other. Keeping commits small and focused reduces the risk of something breaking during that transition.
Maintaining a Development Site in Public
This site runs as a live development project. It is not a sandbox hidden from view - it is a working demonstration of what a modern Drupal 11 headless setup looks like. That means structural changes like these happen in the open, and the commit history is visible to anyone interested in how the system evolves.
The Drupal backend serves as both a content store for this site and a testbed for keeping current with the latest Drupal patterns. The Nuxt frontend is where I experiment with Vue 3 composition API patterns and modern JavaScript tooling. Pushing changes to both on the same day is a reminder that headless architecture is not just about separating concerns - it is about actively managing the relationship between those concerns.
These commits represent the kind of incremental work that does not generate headlines but keeps a system functional. No new features shipped today, no major bugs fixed - just two repositories staying aligned as the site continues to evolve.