vihanrichard
New member
Hey Laravel devs! 
I’ve recently been diving into Headless Laravel setups where Laravel acts strictly as an API backend, and the frontend is decoupled (e.g., built with React, Vue, or even Next.js). I’m looking to get some input and share thoughts on how to best structure a Headless Laravel app for clean separation of concerns.
Here’s the ideal structure I’ve been working with:
app/
├── Http/
│ ├── Controllers/Api/ # API controllers only
│ └── Middleware/
├── Services/ # Business logic (non-framework specific)
├── Repositories/ # Data access layer
├── Models/
├── Events/Listeners/
├── Jobs/
routes/
├── api.php # API-only routes
I’ve recently been diving into Headless Laravel setups where Laravel acts strictly as an API backend, and the frontend is decoupled (e.g., built with React, Vue, or even Next.js). I’m looking to get some input and share thoughts on how to best structure a Headless Laravel app for clean separation of concerns.
Here’s the ideal structure I’ve been working with:
app/
├── Http/
│ ├── Controllers/Api/ # API controllers only
│ └── Middleware/
├── Services/ # Business logic (non-framework specific)
├── Repositories/ # Data access layer
├── Models/
├── Events/Listeners/
├── Jobs/
routes/
├── api.php # API-only routes
What Do You Think?
- How do you structure your Headless Laravel APIs?
- Do you use any other patterns like Domain-Driven Design or Hexagonal Architecture?
- Any tooling recommendations for testing, caching, or debugging APIs?