Improve local development about stamhoofd

[WardToulet]

How would you feel about adding something like docker compose for development as it makes i easy to spin up all the different services an still allows for hot reloading and such.

Docker of course also be used for hosting, this might be interesting if docker is used in development and could also streamline the system for self hosting (as mentioned in #60) as many services provider docker container hosting.

[SimonBackx]

I'm pro Docker, but for javascript I don't think there are a lot of dependencies that clutter your system and you can make use of nvm. It should be optional as I think the current build time is already very long and inside Docker this will be worse. Feel free to add a Dockerfile / compose file.

[SimonBackx]

The backend is an exception, it will be very useful for setting up MySQL etc.

[WardToulet]

I'm currently working on a docker compose build system for the backend, with multistage builds I have managed to include all dependencies. Multistage builds should be faster as only the changed stage should be build.

[WardToulet]

I have made a PR #61 that is still WIP with a proposal of a structure to dokerize the application with docker and docker-compose.

[maltsavkiryl]

I have been trying to complete the docker scripts @WardToulet had previously created. I made some progress and the following things are working:

1. Start mysql server
2. Build all of the shared dependencies
3. run migrations
4. start backed

Running caddy as a reverse proxy is the final step but I have to do some more tinkering to make caddy work correctly inside of a container and expose the correct domain and ports outside of the container so that the frontend kan access them. I think there are also some issues with the certifications, but I'm still figuring out how it all works locally 😛

[maltsavkiryl]

There is no reason that local development actually needs HTTPS, right?

If so, we could skip caddy and make sure that all communication runs over HTTP.

I was searching the place where the backend host is created and found this ->

stamhoofd/frontend/shared/networking/src/Session.ts

Line 157 in c77193b

server.host = "https://" + this.organizationId + "." + process.env.HOSTNAME_API;

We could add a conditional here so that it uses http when NODE_ENV=development. Would this be a possible fix?

[SimonBackx]

You could use the current window.location to check if it already is using HTTP or HTTPS. Or like you said, check for development (but I'm using HTTPS in development, so it is not guaranteed to always be HTTP).

The main reason for HTTPS atm is because I use the .dev TLD in development, which requires HTTPS. But this shouldn't be a requirement. If needed I can setup a domain with a wildcard that alwasy points to localhost. Or we could include a DNS server in the development setup.

[maltsavkiryl]

Is there a reason you hardcode the hostname to "0.0.0.0" in the RouterServer? https://github.com/SimonBackx/simple-endpoints/blob/455f01dd16eb44fd04e268a9c56eefb9bcd83575/src/RouterServer.ts#L138

I would propose changing it so that you can pass the hostname as a parameter and configure it in your index.ts.

[SimonBackx]

Is there a reason you hardcode the hostname to "0.0.0.0" in the RouterServer? https://github.com/SimonBackx/simple-endpoints/blob/455f01dd16eb44fd04e268a9c56eefb9bcd83575/src/RouterServer.ts#L138

I would propose changing it so that you can pass the hostname as a parameter and configure it in your index.ts.

0.0.0.0 is used just to accept all connections. Caddy or any other reverse proxy should handle domain names and HTTPS and route them to the API. We could remove the obligation for a reverse proxy. Still, the problem is that we use the domain name to determine which organization you are making certain API requests to (the organization ID is in the URL). So domain names are really needed.