chore: allow docker compose to start the backend server (plbstl)

[plbstl]

Description

The Backend section of the Advanced Contribution Guide isn't entirely true. You cannot use docker compose up to start the backend server. The command only starts redis and mongodb services, while having to manually run one of the dev scripts to start the backend server.

This change makes sure that docker compose up in the backend folder also starts the server, making contributions to this project a bit more seamless.

I had to use a separate volume for the node_modules in the backend because of mismatch between where the bcrypt module is built (my PC - MacOS) and where it is being run (Docker - Linux). It creates an error that prevents the server from booting up.

services:
  #...
  api-server:
    #...
    volumes:
      #...
      - /monkeytype/backend/node_modules
    entrypoint: 'bash -c "cd /monkeytype/backend && npm install && npm run dev"'

Only the backend dependencies are installed and built in the Docker container. The script can be a bit more complicated to skip unnecessary npm installs, but this is also okay.

Checks

• [x] Check if any open issues are related to this PR; if so, be sure to tag them below.
• [x] Make sure the PR title follows the Conventional Commits standard. (https://www.conventionalcommits.org for more info)
• [x] Make sure to include your GitHub username inside parentheses at the end of the PR title

[Miodec]

My one issue with this PR is that I personally use Docker to only host the databases, and then run the servers in node myself. Maybe we can have one file for just databases and one for databses and node server?

[plbstl]

Maybe we can have one file for just databases and one for databases and node server?

Yes, that can work. Maybe use the COMPOSE_FILE env var to determine the file to use

[Miodec]

We can't just use multiple files?

[plbstl]

Yes, we're using multiple files. The env var is not necessary but a nice to have. Now thinking about it, it may not even be needed

[Miodec]

Yes, we're using multiple files. The env var is not necessary but a nice to have. Now thinking about it, it may not even be needed

I mean multiple files for composing backend:

• one that only runs the databasees
• one that runs both databases and the api server

[github-actions[bot]]

This PR is stale. Please trigger a re-run of the PR check action.

[plbstl]

Maybe we can have one file for just databases and one for databases and node server?

Yes, that can work. Maybe use the COMPOSE_FILE env var to determine the file to use

Let me elaborate on what I meant by this.

There will be two docker-compose files in the backend. When someone wants to contribute and they run docker compose up, the env var will instruct docker on which file to use. So, there is a default file being used.

Yes, we're using multiple files. The env var is not necessary but a nice to have. Now thinking about it, it may not even be needed

We know by default, docker compose checks for docker-compose.yaml. So the default file that is supposed to be set in the COMPOSE_FILE env var can be named docker-compose.yaml, and the other one named something more specific which will be run with docker-compose -f <filename> up

[Miodec]

Maybe we can have one file for just databases and one for databases and node server?

Yes, that can work. Maybe use the COMPOSE_FILE env var to determine the file to use

Let me elaborate on what I meant by this.

There will be two docker-compose files in the backend. When someone wants to contribute and they run docker compose up, the env var will instruct docker on which file to use. So, there is a default file being used.

Yes, we're using multiple files. The env var is not necessary but a nice to have. Now thinking about it, it may not even be needed

We know by default, docker compose checks for docker-compose.yaml. So the default file that is supposed to be set in the COMPOSE_FILE env var can be named docker-compose.yaml, and the other one named something more specific which will be run with docker-compose -f <filename> up

In that case, i would move the compose files to a backend/docker and rename them to db-and-server and db-only. Then add npm run docker and npm run docker-db scripts.