Looking for feedback/review on my project starter template (DRF + Nuxt + Docker compose)
Looking for feedback/review on my project starter template (DRF + Nuxt + Docker compose)
An opinionated Django project template including DRF for the back-end, Nuxt for the front-end and docker-compose files - pcouy/drf-nuxt-template
I am trying to come-up with a reusable template to quickly start new projects using my prefered tools and frameworks, and I'm happy with what I got. However, using Docker is quite new for me and I've probably done some weird or unconventional stuff in my docker-compose.yml or my Dockerfiles. I'd love to learn from people with more experience with Docker, so feel free to tell me everything that is wrong with my setup.
I'm more confident about the stuff I did with Python/Django and Nuxt, but all criticism is welcome. This also applies to the readme : I'd like to provide detailed instructions about working with this project template, so please report anything that is unclear or missing.
Thank you to anyone who takes the time to check it out and help me make this useful to as many people as possible.
I haven't had a chance to look yet, but I'm using a pretty similar stack at, although with React instead of Nuxt/Vue. I definitely love using Docker, at least as a dev platform, because of the way it evens the field across OS's and makes it easy to onboard new contributors. Will definitely take a closer look when I get more time.
Buuut ... I do mod the !django@programming.dev community, which you might be interested in checking out. There's also the !docker@programming.dev, which is also worth checking out.
Thanks for the suggestion, I cross-posted to these two communities.
Regarding Docker, I actually made two compose files : one for quickly getting a dev env running, and another one for deploying to (pre-)production.
A few suggestions:
-
Having people remember all the docker, django, and poetry commands just slows things down. Maybe wrap those in a shell script, or better, in a pyinvoke tasks.py, or more even better, in a CLI using argparse or click. This way, people can install your tool using pip and create new projects, manage, and run them quickly.
-
If you need the user to answer a few interactive questions, questionary is pretty decent. The click library also lets you ask for input, have defaults, and also load values from environment variables.
-
Have lots of defaults in a central .env or config file that people can customize once the project has been created. Things like separate dev, test, prod or local and cloud settings.py files help keep things organized.
-
Think about ultimate deployment. Where is such a project going to get installed? As a single docker container, scalability is limited. Which cloud hosting services can you push to with one command? Add those to your pyinvoke or CLI.
-
When deploying to cloud, make sure security best practices are maintained. Keep SECRETS and API keys in a separate file which is also listed in your .gitignore so it doesn't get accidentally checked in.
-
Think about the different stages. Initial, ongoing dev, testing, first deploy, and continuing updates after that. What can you do to make the job of the dev easier?
Thanks for the detailed feedback! I made an attempt to put settings that change between environments in a separate file, I'll try switching to environment files.
Regarding secrets, I'd love to integrate with a secret management solution, or even better, turn the whole thing into some ansible stuff (which I never used but seems awesome). Do you recommend anything on this side?
-