You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, constellate is a comprised of a django app (storing user data, serving an API, and a vue front end (poroviding the user interface).
For a database we use postgres in production, but because Django's ORM is good you can also use SQLite, which makes it much easier to run on a smaller setup.
When we deploy via heroku, we rely on object storage for storing upload media files like photos and the like.
However it can also use a regular ol' filesystem. Indeed, this is what we use in development.
The ideal scenario for would be to make it possible to run it by doing something like this:
cl8 setup # answer common questions in a wizard, to create a usable setup file
cl8 serve # serve the system, presenting the Vue user interface, and the Django backend
Making constellate runnable without all the heroku stuff
To run this on a single server without all the production level stuff provided by heroku, but without needing to set up I think you'd need the following
a way to proxy requests to the listening port
a way to to serve the uploaded files in a more secure way than django runserver.
We use gunicorn at the moment as the server for serving requests, but that doesn't serve any uploaded files - just static ones with whitenoise.
If we wanted to serve the uploaded files too, we'd need a way to serve this in a safe way. I'm not sure of the best way to do this. We could expose the uploaded directory using the provided staticfiles app in django, but there are plenty of warnings against doing this in the docs.
When researching possible options for serving a site. This issue on the django herokuapp github repo helped me understand some subtle differences between using gunicorn for serving a django app, and waitress for a django app. Because waitress does something clever with buffering incoming requests it seems a slightly safer choice if you don't have a something like nginx in front of it acting as a reverse proxy, and serving the majority of requests. See the design of waitress section for more
The other alternative - making a heroku app button
The other alternative, which I like slightly more is to make a 'deploy with heroku' button, based on the config we have.
You'd still need some persistent storage though, like an AWS bucket, or similar.
The text was updated successfully, but these errors were encountered:
Right now, constellate is a comprised of a django app (storing user data, serving an API, and a vue front end (poroviding the user interface).
For a database we use postgres in production, but because Django's ORM is good you can also use SQLite, which makes it much easier to run on a smaller setup.
When we deploy via heroku, we rely on object storage for storing upload media files like photos and the like.
However it can also use a regular ol' filesystem. Indeed, this is what we use in development.
The ideal scenario for would be to make it possible to run it by doing something like this:
Making constellate runnable without all the heroku stuff
To run this on a single server without all the production level stuff provided by heroku, but without needing to set up I think you'd need the following
django runserver
.We use gunicorn at the moment as the server for serving requests, but that doesn't serve any uploaded files - just static ones with whitenoise.
If we wanted to serve the uploaded files too, we'd need a way to serve this in a safe way. I'm not sure of the best way to do this. We could expose the uploaded directory using the provided staticfiles app in django, but there are plenty of warnings against doing this in the docs.
When researching possible options for serving a site. This issue on the django herokuapp github repo helped me understand some subtle differences between using gunicorn for serving a django app, and waitress for a django app. Because waitress does something clever with buffering incoming requests it seems a slightly safer choice if you don't have a something like nginx in front of it acting as a reverse proxy, and serving the majority of requests. See the design of waitress section for more
The other alternative - making a heroku app button
The other alternative, which I like slightly more is to make a 'deploy with heroku' button, based on the config we have.
You'd still need some persistent storage though, like an AWS bucket, or similar.
The text was updated successfully, but these errors were encountered: