When you use network_mode host, the published ports are ignored, which means the ports that are open in the containers will be the same port in the host. Does not matter what you had declared in ports
The default behavior is every service in the compose can talk to each other.
Links are not required to enable services to communicate - by default, any ...
Instead of using network_mode to host, you can simply make use of links (new versions uses networks) which will make the communication to happen between two containers.
I have updated the docker-compose.yaml file and added links to connect database service (database container) to be accessed from your backend service.
In your backend database configuration, ...
yarn start should be the CMD of your docker image (I.e what is run when you start a container) and not a RUN command (which is run when creating the image used to satrt a container later)
From your exemple, something like this should be better:
COPY ./server /app
CMD yarn start
Your next step will be to identify a solution for container orchestration. For a quick dev test solution, you could host your own docker registry, push your built image to the registry, and add a deployment step that stops the existing container and spins up a new one from your registry.
However, in a production setting there are many other aspects to ...
I know the question is old, but as I assume others also will run into this requirement...
As OP is bound to this exactly host anyway (reason to use docker-copose over swarm), I suggest another route.
NFS on Synology is a PITA. One has to manage UIDs to be the same on server and client. It's impossible to change UIDs on Synology, hence only client side UIDs ...