Prepare som kind of documentation for final deployment
Opened this issue · 1 comments
Ideally, we should also have some instructions about what should be done when the project is being packaged for "production". We don't need it to be super optimized (it's not that high-traffic), but we probably don't want to run it in debug mode all the time.
So far, I looked here, but it would be nice to have a few notes about what/how/why needs to be setup for a production build and deployment. In particular, I'm guessing the backend needs node.js
to run, but can we package the frontend as a "static" html+js website? Or does that require node.js
on the server side as well?
Also, can we get some instructions for properly running type checking through TypeScript? I can setup some CI and I can probably guess correctly what we should run based on vite
documentation, but it would be nice to have some "official" instructions.
In hindsight, it would be great if each component (i.e. frontend and backend) could be packaged as a docker container. We are already using docker for the database, so it makes a lot of sense to just use it for everything.
However, I'm a bit unsure about how the database should be initially populated. Maybe we could extend the database image and include the data in it directly. That way, we can just update the docker container and it gives us new data.
So the overall process would look something like this:
- We build a docker image which is serving the current version of the frontend using some reasonable web server (maybe also
node.js
?). If frontend changes, we have to update this image. - We build a docker image which is serving the current version of the backend using
node.js
. Again, if backend changes we have to update this image. - We have a docker image with a database populated with the current contents of the
models
directory. That way, when the data changes, we can just rebuild the image and get a new version of the data ready to be deployed.
If we have these three docker images, I then know how to deploy this practically anywhere because I can use a reverse proxy to route the relevant domains to frontend/backend.