▲ 2 r/node+2 crossposts

Coming from WordPress/PHP: How Do You Structure Your Docker Dev Stack for Next.js + Strapi?

I’m coming from a mostly WordPress/PHP background and I’m currently trying to properly learn the modern JS stack instead of just stitching things together until they work.

My current setup is a homelab with TrueNAS, Docker/Dokploy, Traefik and GitHub.
For WordPress development I’m used to having everything nicely contained in one Docker Compose project, developing there, then pushing/deploying from Git.

Now I’m trying to move into a stack based around:
Next.js / React for the frontend
Strapi as the backend/CMS
PostgreSQL
Puck as a visual editor
Docker Compose for the full project
GitHub → Dokploy for deployment

At the moment I have a basic three-service stack:
frontend
backend
database

It works, but I’m still figuring out what the “normal” developer workflow is supposed to look like.
For example, I’m currently running the frontend and Strapi in development mode inside Docker, with source folders bind-mounted into the containers so I can work on the code over SSH.

The same repo is also deployed through Dokploy, which made me realise that development and deployment probably shouldn’t be treated exactly the same way.

So I’m curious how people who work with React/Next.js + Strapi actually structure this.
Do you normally:
run Node/Next/Strapi directly on your dev machine and only Dockerize databases/services?
run the whole development environment inside Docker?
use separate compose.dev.yml and production Compose files?
keep Strapi and Next.js in one monorepo or separate repos?
use next dev / strapi develop in Docker locally, but next build / strapi start for staging and production?
develop against a local Postgres container and then use a completely separate persistent DB for staging?
use Dev Containers or something similar instead of manually exec’ing into containers?

I’m especially interested in how people keep the workflow simple when the goal is to build a reusable project template that can later be cloned for different clients.
I’m not really looking for “just use X because it’s trendy” answers. I’d love to see how people actually structure their Docker Compose files and development workflow in real projects, and what you wish you had done differently when you first moved from WordPress/PHP into React/Next/Strapi.

reddit.com
u/Ok-Nerve7307 — 1 day ago
▲ 6 r/webdev

I Stopped Building “WordPress Sites” and Started Building API-First Backends

I’ve been rethinking how I build WordPress projects as a solo developer and I’m curious how other people here are approaching this.

For context:

I build websites for animal shelters and rescues. Originally I was building traditional WordPress sites with themes tightly coupled to the backend. The more projects I built, the more I noticed the same problem over and over:

* backend logic stays mostly the same

* frontend requirements constantly change

* every redesign becomes a partial rebuild

So I started experimenting with treating WordPress less like “the website” and more like an application backend.

Current architecture:

* TrueNAS server

* Docker + Docker Compose inside a jail

* One global Traefik instance for routing

* Every project isolated in its own repo + compose stack

* VS Code Remote SSH from my Mac (home + on the go via Tailscale)

* WordPress acting as a headless/API-first backend

* React/Next.js frontends consuming a custom REST API

Instead of exposing raw WP post structures, I’m building a dedicated API layer:

/wp-json/shelter/v1/animals

/wp-json/shelter/v1/animals/{id}

The plugin contains:

* CPTs + taxonomies

* lifecycle/business logic

* transformers/view models

* query layer

* REST controllers

The frontend only consumes stable JSON contracts.

That means:

* I can swap frontends without touching backend logic

* build multiple frontend designs for the same backend

* eventually evolve the plugin into a SaaS/API product

I’m also separating repos aggressively now:

```txt

/workspace/projects/

├── animal-shelter-plugin/

├── shelter-backend/

├── shelter-next-frontend/

├── client-a/

└── client-b/

```

The reusable plugin lives independently from client projects.

What surprised me most:

WordPress actually becomes much cleaner once you stop treating it like the rendering engine and start treating it like infrastructure.

Curious:

* Are other people here using WP this way?

* How are you structuring multi-project Docker dev environments?

* Would you stay REST-first or move toward WPGraphQL immediately?

* Any major pitfalls you hit going API-first with WordPress?

Would genuinely love feedback from people further down this path.

reddit.com
u/Ok-Nerve7307 — 3 months ago

Shelter api

I'm trying to build out an API for animal shelters based on wordpress custom post types and it's meta fields...

The front end will be based on node.js and tailwind css and react or something like that...

So that the backend can stay the same for every client but the frontend is interchangeable.

Any ideas or thoughts?

reddit.com
u/Ok-Nerve7307 — 3 months ago