Hi !
As discussed in wq/wq-django-template#20, I'm interested in contributing a docker-compose setup for WQ.io, so it could be used easily cross-platform and would be easier to deploy.
There is however one thing that I don't understand and which looks a bit contradictory regarding config.js,
It seems config.js is both :
- generated by a REST service (e.g. wq.db) - which tends to indicate that config.js is served dynamically from wq.db and loaded on runtime by the javascript app.
- manually generated with the
dump_config management command (that is called from deploy.sh) - which tends to indicate that this is needed at build time for the javascript app.
I don't really see how these can both be true ?
This has an influence on how things can be containerized (ideally there would a nodejs image that can build completely independently from the django backend, but if the nodejs image requires config.js, it would get a little more complicated.)
Could you clarify how this works ?
Hi !
As discussed in wq/wq-django-template#20, I'm interested in contributing a docker-compose setup for WQ.io, so it could be used easily cross-platform and would be easier to deploy.
There is however one thing that I don't understand and which looks a bit contradictory regarding
config.js,It seems
config.jsis both :dump_configmanagement command (that is called fromdeploy.sh) - which tends to indicate that this is needed at build time for the javascript app.I don't really see how these can both be true ?
This has an influence on how things can be containerized (ideally there would a nodejs image that can build completely independently from the django backend, but if the nodejs image requires config.js, it would get a little more complicated.)
Could you clarify how this works ?