Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make constelate runnable from a simple pip install #108

Open
mrchrisadams opened this issue Oct 5, 2020 · 0 comments
Open

make constelate runnable from a simple pip install #108

mrchrisadams opened this issue Oct 5, 2020 · 0 comments

Comments

@mrchrisadams
Copy link
Member

mrchrisadams commented Oct 5, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant