Suppose I have a front-end which is mostly a single-page application written using angular, grunt, and bower. And suppose I have a backend, which is mostly just a REST API sitting on top of an ORM, which stores/retrieves objects from a database, using things like grunt, express and sequelize.
The angular application does all of the visual stuff the user sees, but it does so by being a GUI over the services provided by the back-end.
It would be desirable to separate these into two different codebases, to permit independent development, versioning, continuous integration, push to development, etc.
Option #1 seems to be a monolith, i.e. "don't separate them". The pro is that the build chain is simple, and everything is in one place - but there seem to be many cons; harder to version independently, a broken front means an un-deployable back, and so on.
Option #2 seems to be a quasi-monolith, where the front-end build chain results in writing a bunch of files to the back-end. The
dist directory on the front-end would refer to some directory on the back-end, so essentially when the front end minifies, uglifies, etc, it ends up publishing to the back-end, which runs everything.
Option #3 seems full-separation: front-end and back-end each run their own servers on different ports, and they are fully separate projects. The drawback seems that they need to be configured to know about each other's ports; the back-end must allow CORS from the front-end, and the front-end needs to know where all those endpoints are expected to be.
Option #4 might be to use something like docker-compose to rig the whole thing together.
I'm sure there are other options. What's the recommended best practice?