Objectives

I set out to build a blog that enabled intuitive navigation and discovery of the blog's content using a clean and minimalistic interface. Features such as a category sidebar with the number of posts included within each category should enable the user to find other posts that might be of interest.

The blog should include a detailed amount of metadata which informs the reader on how useful the blog's article is. One of my personal dislikes is when I'm reading a blog post and there's no created or updated date on the post. This leaves me wondering if the solution provided really is aligned to the challenge I'm facing.

The Approach & Solution

Firstly, I drafted a database schema with a rough sketch on my notepad. Following this, I created the 'Category' and 'Post' models within the 'blog' app.

I decided to structure the relationships between categories and posts as a many-to-many relationship. It would have been easier to develop a solution using a one-to-many relationship however, it seemed reasonable to me that a post could fall into many different categories.

Following this, in a separate app called 'users', I created a 'Profile' model which has a one-to-one relationship with Django's default 'User' model. These are connected using Django signals whereby when an instance of 'User' is created, it sends a signal to the custom 'Profile' model to simultaneously create an instance of the 'Profile' model.

Following the implementation of the models, I designed the URL structure of the application. Working in this way helped me to decide upon the various views that needed to be created. I have learned that it's best to work in order of most generic to most specific in terms of creating the URLs/views.

The final stage was to render the templates which is of course was an iterative process requiring revisions to the models and views as better or more desirable options become apparent.

During development, I have refactored to implement a model manager which represents a queryset for published posts which is re-used repeatedly throughout the project. This has moved a lot of the implementation logic away from the views and towards the models. This has made it easier to remove any duplicate SQL queries from the views in addition to making the code easier to maintain, and re-use.

Evaluation

If I were to repeat the project, I would create a custom user model which would use an email address for registration rather than a username. I think that using usernames is an outdated way of signing up for a website. It's more difficult for a user to remember their username than their email address. This fits my own personal preferred and biased method and of signing up to web services.

Additionally, due to privacy concerns, I don't believe in using Google or Facebook's expedited login buttons. They're very convenient at the point of registration but expensive in terms of the data that you're giving away. Some might argue the very valid point that they're extremely secure because of the resources that they put into ensuring their platforms are secure, however I still believe this is at the expense of user privacy. If it becomes easy to use Apple's newer sign in with apple button, then I may revisit this because of their approach to privacy.

Changing over to a custom user model at this point would require a considerable amount of effort to derive very little benefit. I have used this pattern in a subsequent project within one of my private repositories.