Ever since learning about the existence of Django, Python’s MVC framework, I’ve wanted to learn how to use it. By now, I’ve played with quite a few other MVC frameworks (a custom PHP framework, Laravel, Yii, and Rails). Most of the same concepts are there: a routing file, a view file, and a model. But the differences were much more apparent:
- Minimal file base. Much of Laravel and Rails had the custom MVC files buried within all of the framework files. It wasn’t nearly as bad with Yii. However, the Django MVC framework files are… almost nowhere to be found within my code base. As a developer, this made my life much easier to focus on the code itself instead of wading through some complex file structure to find the handful of files that I needed to edit.
- Reusability. Other frameworks claim this. But Django feels more package-centric: the architecture enabled having multiple applications within the one code base. Having virtually no framework files intermingling with the project’s essential code enables greater package modularity for the future. I could have put my version control head in several locations within the project area (for multiple apps). For a developer that will likely have in the future many smaller applications that I’ll want to demonstrate all on one Python Server, this is very important. It also lends well to the micro-services architecture that I keep seeing.
- The built-in Admin site. None of the other MVC frameworks had an application pre-built for me that could easily create, read, update, and delete data. Normally, one would never use this, but I soon learned the why and advantage of this.
- Automated testing. I know that Laravel has some updated testing support built in. I was impressed at how up front, from the beginning, the Django tutorial was on discussing and stepping the reader through the automated testing features. Having spoken with an industry manager, automated testing often proves to be more trouble than it is worth. At CalPERS, I often struggled with wrapping my brain around how one would implement automated testing with a GUI. Note: my CalPERS teams never did any automated testing, it was always done by hand. This tutorial helped spell out the place for it: backend logical condition testing.
- Lack of out of the box React Documentation. Though to be fair, only Laravel Documentation (not Rails) ever discusses “React integration”. Larvel’s documentation placed the php template code tutorials next to the React tutorials. However, the moment I tried to find some other (non-project sponsored) tutorials online: I was impressed. Every single tutorial I stumbled upon (no: I did not do an exhaustive search) had the same implementation: use the REST API format. Using REST meant, no MVC “HTML Template” files. Using REST meant very little back-end code: a tiny serializer file, a small-ish models.py file (the only place to document database table fields all in one place), an entry into the urls.py file, and a small definition in the view.py file (collecting data from the model, using the serializer to prep, and return the properly formatted data). This was one of my light bulb moments: this tightly structured and standardized format likely is what enables the Admin site to work with any data.
- And, while I’m on the subject, yes, Django has an inline template code so that Python code can easily be sprinkled into my HTML / JavaScript files. To be honest, I was so focused on using React that I glossed over this feature.
I feel like I really need to get down to my “why did I choose to develop a project with Django and React” and its impact on my design decisions going forward:
Why did I choose to develop the project with Django and React?
- Ignoring the obvious? (sorry Laravel and Ruby, but Django is one of the main industry standards now and React is the industry standard front-end framework)
- I’ve been itching to learn Python and Django since September 2023! At the time, I did not know how popular it was compared with the other platforms. I figured it could be best to ease into learning it by learning other PHP frameworks (get to know what a framework is all about), learning React with PHP (make the back end easier), and Ruby on Rails had been a popular platform that I jumped into all of those first. It turned out that with this framework, there was such a tiny amount of MVC framework code, that I’ve spent 90% of my time working on the front end!
- All of the Python analytic libraries that I’ll have access to. Some job listings that spell out their use of Python mention the main libraries that they use. Plus, I learned a while back, how well Python libraries plug into spreadsheets and generate report data, which I’m looking forward to generating analytics on my app data. For example: what percentage of jobs tend to get back to me? Of those, how fast or slow do they tend to respond? Which technologies am I seeing mentioned in the places that I’m looking at?
- Python seems to lend itself better to the microservices and containerization that I saw in the AWS training. What I really mean by this, after having taken the AWS classes, is that some of the compute services didn’t have much PHP or ruby support. Plus, having now gone through maybe 6 to 8 company interview code tests, half of them did not allow for PHP or Ruby! All but one accepted Python. Going forward, for all interview code test preparation, I highly recommend JavaScript to everybody.
These are the online tutorials that I did in this particular order:
- Official Django Project
- Jordan Irabor’s ‘How To Build a To-Do Application Using Django and React’
- Diogo Souza’s ‘Using React with Django to create an app: Tutorial’
In the future, I’ll gladly work at a business doing Laravel or Rails work (hopefully they are either using or planning on migrating to a front-end framework like React). But going forward, Django is now my personal site MVC of choice. Especially since I can find a no-sql option for it It feels that the options and versatility of Python, Django, and React are too much for me to ignore.