Design Pattern: Django Rest Framework
We use Django Rest Framework (DRF)for our backend service on my PPL (Software Development course) project. The service purpose is to store data, serve business logics, and provide APIs for our web and mobile clients to use. In short, our system architecture consists of only one monolithic service for the backend that serves both the web and mobile clients.
Personally, my experience on developing with DRF is remarkable. It is a battery-included framework and one can truly go far and make clean and comprehensive APIs easily with minimal code. With DRF, you can easily construct common CRUD and custom endpoints. Additionally, it has built-in and additional libraries for essential features such as pagination, filter, search, authentication, logging, and many more. For me, it is a pleasant framework to use for API development that I can focus only on the data and business logics, and let DRF handle the common tasks such as paginating, etc.
The ease of development is because of the well-designed API that developer follows when using DRF. It has some design principles and philosophies that makes generalization possible, so that people can develop systems with different set of features and data with the same Django/DRF API.
Patterns
There are some design patterns that I found on DRF.
Template Method Pattern
The most common is the template pattern that is used on so many places. Models, View classes, Serializers, all implements the template pattern that it provides base/skeleton for some thing and we only need to provide/override implementation for things that we need to customize.
For example, the ViewSet classes. It provides construction for common REST endpoints such as listing records, create, retrieve, update, and delete. For ModelViewSet classes, we only need to define the model it corresponds to and it will create complete list, create, retrieve, update, delete endpoints with its error messages, validation, headers, and many other basic common configurations for the requests and responses. Furthermore, we can specify additional features such as defining filter backends, pagination scheme, or custom endpoint for a certain specific purpose.
The code above results in endpoints that conforms with fields in CaseSubjectSerializer and configured with custom queryset, filter backends, permissions, pagination, search, and ordering. Additionally, I specify a custom logic that will be invoked whenever a deletion is performed (someone fires a DELETE HTTP request to the endpoint). This whole notion of extending and overriding existing implementation is the essence of Template Method Pattern.
With a few lines of code, it can provide a comprehensive set of features for the endpoints. To do the same thing in other framework/languages would probably need more code and most of the time its boilerplate code that will be repeated for every endpoints. So it makes sense to extend an existing (and powerful) construct provided by DRF, that we follows the DRY guideline.
Adapter Pattern
I also found a usage of adapter pattern in our DRF backend application. Django provides a way to send email programmatically with its send_mail API. The only thing that we need to specify is what provider will we use to send the email. In my case, we use SendGrid as the email service and we specify the SendgridBackend as the email backend for our DRF application.
With the email backend setting is done, all we have to do is to call the send_mail function from Django and it will automatically adapts the email sending mechanism to utilize the SendGrid service we set up earlier.
We can change the email service easily from the settings if we need to and the “email sending” part of the code will remain the same.
Although the ease of development and the huge arsenal of ready-to-use features, it is important to note that for some, the framework is an opinionated one and developers are recommended to follow the way Django is designed to be used, and for some specific rare edge cases, who knows that it might be difficult to do a workaround.
This article is a part of my writing series about software development that cover topics such as Git, Agile framework, TDD, Clean Code, CI/CD, and many more.
