Laravel API and Next.js frontend decoupled or not?

@v-test Why do you think splitting the project into two separate repositories would be a good idea? You now have to coordinate feature development in two separate repositories, as well as coordinate the deployment of two separate applications.

They’re the same project. So just keep them in the same repository.

Personally, I try to work within one repo if possible. It looks like you want to build a SPA. When that's the case I usually check if using InertiaJS will fit my needs. Usually, it does, as I'm way more comfortable and productive with routing and controllers on the server.

However, if you want (or need) to go the traditional SPA route of building API endpoints, I would probably keep both repos separate. The main reason would be because setting up a Next.js app WITHIN a Laravel app could be tricky. Maybe there's a package/starter out there that can do this for you? I would spend some time looking and if I couldn't find anything, just keep them separate. You could try to do this yourself but at this point, you will probably have a heavily modified version of Next/Laravel that might be really tricky to update.

In having done a few of these myself, I'm with @drehimself on this one: if you can use Inertia to join them together; I'd go that route and keep it all-in-one otherwise splitting into separate repos is viable.

From trying to do this with Nuxt, Next and a CRA app on a few separate occasions, I'd keep them as different build processes and different repos. Easier to onboard people onto the project, easier to organize each codebase, easier to do reviews. Then you can write some simple bash/powershell scripts for upping both build environments pretty easily...if you're using sail, call sail in the Laravel repo, then in a separate window cd into the Next project and run your build command. In the Next app include an environment variable that tells it where it should look for the Laravel API endpoints (if sail, it'll likely be 127.0.0.1) and then it'll run off of port 3000 or 8000 or 8080 or wherever which can then be changed for staging and production.

A ton of time could be spent building a unified build environment but I think that you'll either end up with something half-baked or you'll spend an enormous amount of time on something where it would have been easier to just keep them separate. Getting them to build consistently doesn't even address all the customization you'll have to do writing CI/CD pipelines, documentation for onboarding new devs and any other stuff that is already available when they're two separate projects but now are different as they're merged together.