I have a project FE, BE and a DB. now all the tutorials I found use the three in one file.

Now should it be the DB in one docker-compose file and the BE and FE in another? Or should it be one file per project with DB, FE and BE?

[UPDATE]

The stack I'm using is Spring Boot, Postgres and Angular.

CodePudding user response：

Logically your application has two parts. The front-end runs in the browser, and it makes HTTP requests to the back-end. The database is an implementation detail of the back-end and not something you separately need to manage.

So I'd consider two possible Compose layouts:

1. This is "one application", and there is one docker-compose.yml that manages all of it.
2. The front- and back-end are managed separately, since they are two separate components with a network API. You have a frontend/docker-compose.yml that manages the front-end, and a backend/docker-compose.yml that manages the back-end and its associated database.

Typical container style is not to have a single shared database. Since it's easy to launch an isolated database in a container, you'd generally have a separate database per application (or per microservice if you're using that style). Of the options you suggest, a separate Compose file only launching a standalone database is the one I'd least consider.

You haven't described your particular tech stack here, but another consideration is that you may not need a container for the front-end. If it's a plain React application, the "classic" development flow of compiling it to static files and publishing them via any convenient HTTP service still works with a Docker-based backend. You get some advantages from this path like Webpack's hashed build files, so you can avoid disrupting running clients when you push out a new build. If you separate the front- and back-ends initially, then you can change the way the front-end is deployed without affecting the back-end at all.