Initial LonelyDNS Development Environment

I have a few minutes between errands this weekend so let me quickly describe the development environment I’ve set up for LonelyDNS.

On my primary development machine (running Fedora 33 workstation), I have docker installed thanks to this article from Fedora Magazine. I switch between PyCharm and VS Code depending on which IDE I feel like using at the moment. I’ve honestly had a love/hate relationship with PyCharm. I love the automation regarding setting up projects and refactoring code but I hate anything that uses Java (even if it works well). However today is not the day for that soapbox.

Enter the Monolith

LonelyDNS has been initially setup as a monolith with the code located in the same project albeit in different folders.

  • .envs: This folder contains several files with variables depending on the app’s environment (dev or prod).
  • backend: This folder contains the Django project for the API server.
  • docker: This folder is divided into sub-folders based on environment (dev or prod) that each contain Dockerfiles for the specific containers (e.g. django, postgres).
  • frontend: This folder contains the Vue.js project for the frondend app.
  • requirements: This folder contains the pip requirements files used to install Python dependencies. There are some dependencies (e.g. black, coverage, pylint) that are only used during development and those have been separated from the base (production) dependencies.
  • development.yml: This is the docker-compose file that builds and runs the app’s containers while I’m developing.

The final results looks something like:

└── lonelydnsapi
├── .envs
├── backend
├── docker
├── frontend
├── requirements
│   ├── base.txt
│   └── dev.txt
└── development.yml

If you have any experience using PyDanny’s cookiecutter-django project, the layout above may look familiar to you. I’m not using cookiecutter-django for this project but I have borrowed some of the same principles in order to maintain my sanity.

Next Steps

I no longer believe in the “fail fast” mantra for my personal projects. “Fail fast” feels like taking shortcuts just for the sake of getting things done quickly and that is not what this project is about.

I’m taking some time this evening to brainstorm features I want in my MVP and to investigate the architectural decisions that different approaches to multi-tenancy will require me to make.

Until next time…