Django | Part 1 | Choosing the Django architecture and web framework

These days when going down the path of building a website the potential build possibilities are nearly endless.  There are so many different architectures and frameworks out there, how do you choose the correct one?  The short answer, there is no one right solution.  Instead, the ideal solution for you is dependent on your circumstance.  In this article, I will run through my thinking and approach to making this decision based on my circumstance.

My approach to this is similar to how I solve most problems - by breaking them down into their smaller components and methodically solving each.  So, working back from the endpoint, being the browser or client that is connecting to the website, the first thing I would need is a DNS.  The role of a DNS is to connect the dots between my chosen domain name and the specific IP address for my application.  That way, when the client requests the internet resources from the domain, it will connect to my web application to get them.

Choosing a DNS provider

My approach to choosing a DNS provider is not scientific.  It generally comes down to two key considerations;

• Ease of use
• Price

When weighing up these two considerations, my choice of DNS provider is Google Domains.  The reason is that it is a seamless experience for me to navigate and purchase my domain of choice and then go in and manage the DNS routing to my web application.  In addition, it was in line with competitors such as Go Daddy when comparing the price of purchasing and managing the domain on an ongoing basis.

With the DNS provider now decided, going a step back further, the next thing to solve is the web application itself.  How will I host it, and what web framework will I build it in?  

Choosing the hosting method

For me, this was an easy choice.  I have always been a big fan of serverless applications.  These are applications that are deployed natively on the cloud meaning that as a web developer I don’t have to deal with managing the server and all of the tedious problems that come with it.  Now, serverless does not mean that there are no servers, it just means that the server is managed by the cloud provider instead.  This comes with some key benefits;  

• They’re pay-per-request, instead of having your server running the whole time.
• They’re self-scaling.  Meaning that you don’t have to keep optimising the size of your server.
• They’re managed for you.  Meaning that you don’t have to deal with all of the upkeep on hardware, software, and security.

As I am building a small blog, this is a no-brainer based on the pay-per-request model alone.  I don’t want to pay for having a server running the whole time if there is no need to.  When it comes to serverless providers, my preference is Googles Cloud Run.  The reason for this is that it is affordable & easy to set up continuous deployment with Cloud Build. 

Choosing the web framework

This component is probably the most tricky decision for me as there are many different options available that are all viable in their own right.  My key three mentions are;

• Svelte - This is a component-based framework that you can connect to a backend as a service (BAAS) like Supabase.  It is a fast and affordable framework for deploying clean and reactive websites.  However, it is predominantly based on JavaScript, which in my case is not my strength, so I decided not to go with this approach.
• FastAPI - This is an incredibly fast and efficient web framework written in python.  With speeds competing with the likes of GO, it ticks a lot of the boxes for me.  However, it is still a relatively new framework with a small community.  In this case, I am looking for something a little more robust.  So, for now, I have decided not to go with this approach.
• Django - Like with FastAPI, Django is a python based web framework designed around rapid deployment and scalability.  It does not have the speed of FastAPI, however, it has a much larger community and I would consider it more robust.  This is why I have decided to use Django as the web framework for my website.

Choosing a database

I did not want my site to be static as I wanted to be able to dynamically insert content without having to recode the website.  To have dynamic content on the website I need to have a database to store all of the dynamic content.  Therefore, the last component that I needed to consider for my website build is the type of database I would be using to power it.  I am a big fan of using Postgres databases as they are a safe and secure way of storing large amounts of data transactionally.  

There are many Postgres database providers, or you could host your own locally.  My choice is to use a cloud-hosed database for similar reasons to using serverless hosting.  They will be managed for me, allowing me the time to focus on tasks more important to me.  There are many Postgres cloud providers out there, and in reality, there are not many differences between them.  My choice here is to use Google’s Cloud SQL Postgres solution.  This is mainly because I have decided to use Google Cloud for my web hosting and I can easily whitelist the application for accessing the database.  There are also low-cost lightweight options making it an affordable solution for me.

There you have it, my approach to deciding on the right architecture and web framework for my website.  As I mentioned at the beginning, there is no one solution for everyone.  Instead, by systematically breaking out your considerations and aligning them to your specific circumstance you will be able to design the correct solution that fits your needs.