DEV Community: Hana Belay

Personal Finance Management App with Django, HTMX, Alpine, Tailwind, and Plaid

Hana Belay — Wed, 09 Oct 2024 13:43:51 +0000

I’ve been eager to dive into HTMX, especially after watching the DjangoCon Europe 2022 talk From React to HTMX on a Real-World SaaS Project. I have been using HTMX and Alpine in my day-to-day work lately, and together, they’ve made developing interactive web apps a lot more enjoyable, especially as someone who isn’t particularly fond of front-end development.

I haven’t been a huge fan of Django templates, but HTMX, Alpine.js, and Django Cotton have started to shift my perspective. And with Tailwind CSS on top, it’s become one of the best stacks I’ve worked with so far.

This project is a personal finance management app that integrates Plaid to link bank accounts and provide financial insights. I used Plaid’s official examples from their repository as a reference.

Want a quick overview of the code? Check it out on GitHub

Features

Plaid Integration to link bank accounts, fetch real-time account data, and track transactions.
Automated webhooks to:
- Automatically sync and update bank data whenever new transactions are available.
- Easily update and re-authenticate accounts when they enter a bad state (e.g., login required).
- Automatically detect new bank accounts and prompt users to add newly detected accounts.
Provides financial insights such as net worth, account-specific details, and category-based spending breakdowns.
Two-factor authentication (2FA) with an authenticator app for an added layer of security.

Dependency Management with Poetry

For managing dependencies in this project, I used Poetry. Poetry simplifies the package management process and automates much of the heavy lifting involved with dependencies. It relies on the pyproject.toml file, which is now the standard for defining build requirements in modern Python projects.

Why Poetry?

Easier dependency resolution.
It creates and manages virtual environments, so if you ever forget to create/activate one, Poetry's got your back.
It locks down the exact versions of packages, making sure the environment is reproducible. This is very helpful especially when working in a larger team.

Ruff and Pre-commit

I’ve been using Ruff, which is a very fast Python linter and code formatter, built in Rust. It handles a bunch of tools all in one, like Black, isort, and more.

What I like about Ruff:

You can configure it using pyproject.toml, which keeps things clean and centralized.
It’s all-in-one—so no need to manage separate tools like Black, isort, etc.

I also used djlint for linting Django templates. It’s decent, but I’m still on the lookout for something better. If you know of any good alternatives, feel free to share!

For more on setting up Pre-commit hooks for code formatting and linting in Django, check out my article here.

Project Structure

django_finance/
├── apps/
│   ├── accounts/
│   ├── common/
│   └── plaid/
├── config/
│   ├── app_template/
│   ├── settings/
│   ├── asgi.py
│   ├── celery.py
│   ├── urls.py
│   └── wsgi.py
├── static/
│   ├── css/
│   ├── images/
│   └── js/
├── templates/
│   ├── account/
│   ├── components/
│   ├── errors/
│   ├── layouts/
│   ├── mfa/
│   ├── plaid/
│   ├── _base_dashboard.html
│   ├── _base.html
│   └── index.html
├── tests/
│   ├── accounts/
│   ├── common/
│   ├── plaid/
│   └── conftest.py
├── theme/
├── .pre-commit-config.yaml
├── db.sqlite3
├── manage.py
├── poetry.lock
├── pyproject.toml
└── README.md

In the common app, I add management commands, validation, base models, template tags, etc. The BaseModel looks like this:

class BaseModel(models.Model):
    """
    Base model for common fields and methods.
    """

    id = models.AutoField(primary_key=True)
    uuid = models.UUIDField(default=uuid.uuid4, unique=True, editable=False)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    is_active = models.BooleanField(default=True, db_index=True, help_text="Used for soft deleting records.")

    objects = BaseModelManager()

    class Meta:
        abstract = True

    def soft_delete(self):
        self.is_active = False
        self.save()

    def restore(self):
        self.is_active = True
        self.save()

I have also created a custom startapp command to generate Django apps with predefined files and content suitable for my use case.

Tests

For writing tests, I use pytest alongside factory_boy, which makes it easy to declare test-specific fields and create test data.

Initially, I used to place a tests folder within each Django app. However, I’ve since switched to having a single tests folder at the root of the project, with subfolders for each app. This approach has made navigation much smoother and keeps everything organized. Plus, it makes sharing common fixtures much easier since they can be defined at a higher level and reused across multiple test modules.

tests/
├── accounts/
│   ├── __init__.py
│   ├── factories.py
│   ├── test_managers.py
│   ├── test_models.py
├── common/
│   ├── __init__.py
│   ├── test_validators.py
├── plaid/
│   ├── conftest.py
│   ├── dummy_data.py
│   ├── factories.py
│   ├── test_models.py
│   ├── test_services.py
│   ├── test_tasks.py
│   ├── test_views.py
│   ├── test_webhooks.py
├── __init__.py/
└── conftest.py

A sample test:


class TestCreatePlaidLinkToken:
    LINK_TOKEN = "link_token"

    class MockLinkTokenResponse:
        def to_dict(self):
            return {
                "link_token": TestCreatePlaidLinkToken.LINK_TOKEN,
                "expiration": "2020-03-27T12:56:34Z",
                "request_id": "request_id",
            }

    @pytest.fixture
    def setup_mocks(self, mocker):
        return {
            "mock_link_token": mocker.patch(
                "django_finance.apps.plaid.views.plaid_config.client.link_token_create",
                return_value=self.MockLinkTokenResponse(),
            ),
            "mock_logger": mocker.patch("django_finance.apps.plaid.views.logger"),
        }

    @pytest.fixture
    def create_link_token(self, client):
        def _create_link_token(data=None):
            return client.post(
                reverse("create_link_token"),
                json.dumps(data) if data else None,
                content_type="application/json",
            )

        return _create_link_token

    def test_create_plaid_link_token_success(self, login, setup_mocks, create_link_token):
        login()
        response = create_link_token()
        assert response.status_code == 201
        data = json.loads(response.content)
        assert "link_token" in data
        assert data["link_token"] == self.LINK_TOKEN
        setup_mocks["mock_link_token"].assert_called_once()

The Frontend

This project combines the following frontend tools:

HTMX allows you to add dynamic interactions to your project without needing heavy JavaScript frameworks. You can organize your Django templates with small, reusable HTMX snippets. This allows you to update specific parts of the page based on user actions, without requiring a full page reload. This pattern works great with Django’s views because each piece of content can be treated as its own view and then injected into the DOM dynamically.

Alpine.js is another lightweight JavaScript framework used to add interactivity. It plays nicely with Django’s template structure and provides quick, declarative behavior for things like modals, dropdowns, or toggles. In combination with HTMX, Alpine can give you just enough JavaScript to enhance the UX without having to deal with something like React or Vue. For instance, you can use Alpine to manage state in the frontend, like opening and closing modals or handling client-side validation.

Tailwind CSS handles the styling in this project, which speeds up the development of clean and responsive UIs. This project also uses Flowbite for pre-built UI components like modals, tooltips, and buttons. Flowbite integrates well with Tailwind and helps you avoid reinventing the wheel for common UI elements.

Django Cotton allows you to create reusable Django templates. I discovered this awesome library halfway through the project while trying to make a modal reusable. Initially, I tried using Django’s include template tag, but when passing lots of context data, it quickly became cluttered. Django-Cotton allows you to create highly reusable components that bind well with your HTMX and Tailwind in an HTML tag-like syntax. For example:

<c-modal modal_id="logout-modal" modal_title="Are you sure you want to logout?" action_url="{% url 'account_logout' %}" />

Two-factor Authentication with AllAuth

For implementing authentication in this project, I used the AllAuth library, which also provides support for multi-factor authentication (MFA). It offers an MFA module that integrates seamlessly with your existing user authentication setup. You can enable 2FA via an authenticator app, adding an extra layer of security. You can also easily customize the templates AllAuth provides to match the look and feel of your app.

Conclusion

Overall, this project is primarily educational and has just enough features to get you started with integrating Django, HTMX, Alpine.js, Tailwind, and Plaid.

That being said, beware that there might be a few bugs here and there, and there’s always room for improvement and further reuse of components. But overall, it’s a solid foundation for anyone looking to explore these technologies.

Checkout the project on GitHub

If you would like me to explore the topics mentioned here in more detail, let me know in the comments.

Happy coding! 🖤

Django Code Formatting and Linting Made Easy: A Step-by-Step Pre-commit Hook Tutorial

Hana Belay — Thu, 05 Oct 2023 06:41:11 +0000

When it comes to coding, we should all aspire to adhere to best practices and industry standards to foster easy communication and collaboration. Formatting and Linting tools allow you to improve your code quality against a set of pre-defined standards.

Formatting: What could be more delightful than code that reads like a well-crafted story, consistently styled and structured? Formatting helps you refine your code layout, indentation, styling, and spacing, enhancing not only its aesthetics but also its readability and reusability.

Linting: Beyond the basic syntax rules, linting allows you to keep your code healthy by checking it for potential bugs, and deviations from established best practices. It also points out areas of improvement and guides you towards creating cleaner, more robust code.

In a team of developers, it is significant to ensure that every team member contributes code that communicates effectively with each other and remains comprehensible to any future developer.

In this blog post, we will set up formatting and linting in a Django project. We will try to incorporate some of the coding styles recommended in Django’s documentation by using tools like pre-commit, black, isort, and flake8. We will also learn how to use pre-commit in continuous integration (CI).

Prerequisite
Configure a Django Project
Introduction to Pre-commit
Configure Black
Configure Isort
Configure Flake8
Bonus: Configure Djlint
Running Pre-commit in Continuous Integration (CI)
Conclusion

Prerequisite

This guide assumes that you are familiar with Django, Git, and GitHub.

Configure a Django Project

The Django project I am going to use is one of my own which is an e-commerce API built using Django Rest Framework. I will demonstrate the concepts by using this project so you can clone it to your local machine. However, feel free to use alternative projects if you prefer.

git clone https://github.com/earthcomfy/django-ecommerce-api.git
git checkout without-pre-commit

You can then create/activate a virtual environment and follow along.

Introduction to Pre-commit

Git hooks are scripts that Git executes before or after events such as committing, merging, or pushing. These scripts allow you to customize and automate parts of your Git workflow.

Pre-commit is a type of Git hook that runs just before you make a commit. When you run git commit, the pre-commit hook checks whether or not the changes being committed meet certain standards that are configured. These standards are commonly linters and code formatters. If your changes don’t meet those rules and standards, your commit will be rejected. In some cases, the linter and formatter will automatically fix the issues on the spot. In other cases, however, the linter will tell you what needs to be fixed and where.

Pre-commit is a framework for managing and maintaining multi-language pre-commit hooks. It supports hooks for various programming languages. Using this framework, you only have to specify a list of hooks you want to run before every commit, and pre-commit handles the installation and execution of those hooks despite your project’s primary language.

That being said, let’s now install this package in our project:

pip install pre-commit

Next, create a file named .pre-commit-config.yaml at the root of the project.

touch .pre-commit-config.yaml

The heart of the pre-commit framework is the .pre-commit-config.yaml file. This file defines the hooks you want to run and where to find them. Hooks are specified as Git repositories, and each hook is associated with a command or script to execute.

Now, let’s add our first hook:

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.4.0
    hooks:
      - id: check-yaml
      - id: end-of-file-fixer
      - id: trailing-whitespace

The above configuration uses hooks from the pre-commit/pre-commit-hooks repository. The latest version at the time of writing is 4.4.0 You can check for the latest releases in the repository of any hook you want to add. The above configuration specifies 3 scripts that will be run:

check-yaml Attempts to load all yaml files to verify syntax.
end-of-file-fixer Makes sure files end in a new line and only a new line.
trailing-whitespace Trims trailing whitespace.

For a list of other hooks provided by this repository, check https://github.com/pre-commit/pre-commit-hooks

Once the configuration is set up, run:

pre-commit install

This will set up the hooks locally based on the configuration specified in .pre-commit-config.yaml file. After this installation, every time you run git commit, the configured hooks will automatically run on the staged files.

Note that you can also run pre-commit run --all-files at any time to run all configured hooks on all files in your project, rather than just the files that are staged for the next commit. This command is especially helpful during the initial setup of pre-commit to check all files and identify and fix issues before making the initial commit.

So, let’s do exactly that:

pre-commit run --all-files

As you can see in the image below, the check-yaml script ran successfully while the other 2 failed.

The hooks will automatically fix the issues so that’s great. Now, we can stage the changed files and commit them:

Commit successful 🙂

Depending on your project, you can set up as many hooks as you like. In our case, we are going to set up 3 hooks: black, isort, flake8. We will also set up djlint as a bonus.

Configure Black

Black is a Python code formatter that automatically formats Python code to comply with its style guide called PEP 8. PEP 8 is the official style guide for Python code, and it provides recommendations on how to format code for better readability and consistency.

Pre-commit will not run on gitignored files. In a Django project, we usually track migration files (unless you have a specific reason not to). Given that migration files are auto-generated by Django, it’s better not to run pre-commit on these files. Therefore, before configuring Black, let’s exclude migration files. At the top of the config file, add the following:

exclude: .*migrations\/.*

Then let’s configure the hook:

- repo: https://github.com/psf/black-pre-commit-mirror
    rev: 23.9.1
    hooks:
      - id: black
        language_version: python3.10

rev The latest version of black at the time of writing is 23.9.1
language_version Black recommends specifying the latest version of Python supported by your project.

The next step is to customize settings for black. We are going to do this customization in a file called pyproject.toml.

pyproject.toml is a configuration file used in Python projects. It is designed to specify project information and configuration details in a standardized way. The advantage of using this config file is that it is quickly becoming a standard place to configure most Python tools such as black and Isort.

Let’s create the file at the root of the project:

touch pyproject.toml

Open the file and add the following settings:

[tool.black]
line-length = 88
target-version = ['py310']
include = '\.pyi?$'

line-length How many characters per line to allow. The default is 88.
target-version Python versions that should be supported by Black’s output.

For a list of other configurations, check https://black.readthedocs.io/en/stable/usage_and_configuration/

Pre-commit will pick up these configs and check your project against them.

As mentioned before, it is a good practice to run all files after adding a new hook:

pre-commit run --all-files

A lot of things have been automatically reformatted as you can see:

Now, I am going to stage the changes and commit:

Configure Isort

isort is a Python utility that helps in sorting and organizing import statements in Python code to create readable and consistent code. It automatically formats import statements in accordance with PEP 8.

Add the hook to pre commit config file:

- repo: https://github.com/pycqa/isort
    rev: 5.12.0
    hooks:
      - id: isort
        name: isort (python)

Similar to Black, you can tailor the settings for isort by utilizing the same pyproject.toml file. Append the following configurations for isort immediately below the existing black settings:

[tool.isort]
profile = "django"
combine_as_imports = true
include_trailing_comma = true
line_length = 88
multi_line_output = 3
known_first_party = ["config"]

profile is built into isort to allow easy interoperability with common projects and code styles.
combine_as_imports Combines as imports on the same line.
include_trailing_comma Includes a trailing comma on multi-line imports that include parentheses.
line_length The max length of an import line (used for wrapping long imports). It should be the same as black.
multi_line_output Defines how from imports wrap when they extend past the line_length limit.
known_first_party Force isort to recognize a module as being part of the current Python project. It should be the name of your Django project.

For a list of other configuration options, check https://pycqa.github.io/isort/docs/configuration/options.html

let’s now run pre-commit against all files:

pre-commit run --all-files

You can see a lot of files have been fixed by isort. Also, the pre-commit config file has been updated to trim a trailing whitespace.

Stage and commit changes:

Configure Flake8

Flake8 is a popular linting tool for Python code. It is not a single tool but a wrapper that integrates several other tools to check your code for compliance with style guides such as PEP 8 and to detect various programming errors.

To configure the hook, append the following in pre-commit config file:

- repo: https://github.com/pycqa/flake8
    rev: 6.1.0
    hooks:
      - id: flake8

Flake8 supports storing its configuration in your project in one of setup.cfg, tox.ini, or .flake8 file.

Let’s go with .flake8 option. Create a .flake8 file at the root of your project:

touch .flake8

Then, add the following setting in the file:

[flake8]
max-line-length = 88

For a list of configuration options, check https://flake8.pycqa.org/en/latest/user/configuration.html

Let’s now run pre-commit against all files:

pre-commit run --all-files

Note that this plugin doesn't automatically fix the issues for us. It only tells us what is wrong and where. Let’s discuss the issues raised by flake8:

1) The first issue arises from the settings. In the base.py file, the os module is imported, although it is not directly utilized within that file. Instead, it is used in the development.py which is imported from the base. To address this issue, we can eliminate the import statement from the base.py file and explicitly incorporate it in the development.py file.
2) For the line too long issue in the base.py file, I am going to ignore it and put # noqa
3) The unable to detect undefined names stems from the fact that we are using global imports in the settings. This specific case related to the settings is fine by me so I am going to tell flake8 to ignore this issue. Go to the .flak8 file and append this:

per-file-ignores =
    config/settings/*:F405 F403 F401

4) The line-length violations (E501) are caused because Black doesn't know how to operate on strings. So I am actually going to ignore this warning. I am also going to ignore W503, pertaining to the line break before a binary operator, as part of this approach. Add this in .flake8 file:

ignore = E501, W503

The other issues F401, E712, and F841 have been fixed. This is what the final .flake8 file looks like:

[flake8]
max-line-length = 88
ignore = E501, W503
per-file-ignores =
    config/settings/*:F405 F403 F401

Now let’s run pre-commit again:

pre-commit run --all-files

Voila, everything is fixed, stage and commit the changes:

Bonus Tool: Djlint

Djlint is a valuable tool designed for formatting and linting Django HTML templates. I have extensively searched for such a tool, especially because Prettier does not support Django HTML files, making Djlint a good alternative.

Although our current Django project doesn't involve HTML files, it's straightforward to set up Djlint, and the configuration process aligns with the approach we've taken for other hooks.

Add the following to the pre-commit config file:

- repo: https://github.com/Riverside-Healthcare/djLint
    rev: v1.32.0
    hooks:
      - id: djlint-reformat-django
      - id: djlint-django

To customize Djlint settings, similar to what we did for Black and isort, you can utilize the pyproject.toml file:

[tool.djlint]
profile = "django"
ignore = "H031"

You can ignore linting rules as per your requirements. For example, in the above config, H031 which checks for the presence of meta keywords is ignored. You can check https://www.djlint.com/docs/linter/ for a list of linting rules.

Running Pre-Commit in Continuous Integration (CI)

Running pre-commit in Continuous Integration (CI) is a practice that involves integrating pre-commit checks into the CI/CD (Continuous Integration/Continuous Deployment) pipeline. By incorporating formatting and linting checks into the CI process, you ensure that code quality standards are maintained and potential issues are caught early in the development life-cycle.

Welcome pre-commit ci, a continuous integration service for the pre-commit framework.

To configure the service, follow the steps below:

Go to https://pre-commit.ci/
Press sign in with GitHub

Install this service into a GitHub repository of your choice

That’s it!

This is pre-commit running after making a PR:

Conclusion

I hope you found this article helpful. By automating formatting and enforcing linting standards, you can focus on business logic and architecture and save yourself time. If you got lost somewhere throughout the guide, check out the project on GitHub

Happy coding! 🖤

From Problems to Solutions: Understanding Design Patterns

Hana Belay — Sun, 26 Mar 2023 03:00:00 +0000

An interesting fact in software development is that you are almost always not the first person to face a specific problem. The problem may have been occurring since the dawn of software development. In this blog post, we are going to take a look at design patterns, why we need them, and an overview of some of the design patterns.

Design patterns are a systematic approach for addressing recurring problems that programmers face. They describe a universal standard to solve those problems. The provided solution is in such a way that it can be reused despite the specific domain of the problem at hand. Therefore, next time you face a programming problem, beware that you don’t have to rediscover the solution from scratch.

Why Design Patterns?

Experience makes one perfect: You, as a developer, have to first understand existing good designs, their application area, and trade-offs so that you can reuse them or develop your own.
Shared language of design: Design patterns provide a common vocabulary for programmers. This helps to effectively communicate with one another, reducing misunderstandings and increasing productivity.
Better scalability: Design patterns help to make systems more scalable, allowing them to grow and adapt as needs change.
Improved code structure: Design patterns help to structure code in a consistent and organized manner, making it easier to understand and maintain. This can lead to improved code quality and reduced development time.

Elements of a Design Pattern

Name - is a handle used to describe the design issue. It is necessary because it gives a common ground of understanding among programmers.
Problem - is used to describe when the pattern can be used.
Solution - is a template that describes elements and their relationships without providing implementation detail.
Consequence - is used to describe the trade-offs of the pattern. Examples: time and space trade-offs, flexibility, extensibility, etc.

Types of Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software, commonly known as the Gang of Four, is a cornerstone in software engineering that brought design patterns into the mainstream. The book breaks down 23 different design patterns that fall into the following 3 categories:

Creational - They are concerned with object-creation techniques.
Structural - They are concerned with the combination of objects and classes in a flexible and effective way.
Behavioral - They are concerned with the interaction between classes and objects and their responsibility.

Introduction to Six Design Patterns

The following section is going to provide an overview of 6 software design patterns (2 from each category) and how they can be used to solve common programming challenges.

1. Singleton

The Singleton pattern is a type of creational pattern that ensures the creation of a single instance of a class and provides a global point of access to that instance.

The Why:

Suppose you are building a Database connection class:

You don’t want to create a separate DB instance for every object that needs to access it. If you do so, it’s going to be costly. This concept goes for other shared resources like files as well.
You want to provide global and easy access to that instance. Similar to global variables, the Singleton pattern gives you access to an object from anywhere in your program.

The How:

There are various ways of implementing a Singleton pattern. However, all of the implementations share the following basic concepts:

Unlike a regular constructor that creates a new object whenever you call it, a Singleton class has a private constructor. A private constructor prevents other objects from instantiating an object of the Singleton class.
A private instance variable.
A static method that returns a reference to that instance. This static method basically acts as a constructor and calls the private constructor under the hood to either create an object (when requested for the first time) or return the cached one (for subsequent requests).

2. Factory Method

The factory method is also another type of creational pattern that provides an interface for creating objects but lets the subclasses decide which class to instantiate. In other words, the subclasses can change the type of objects that will be created.

The Why:

Suppose you are creating a logging framework by using the factory method design pattern to log different kinds of messages including, but not limited to, error messages, warning messages, and informational messages. In this use case:

The logger can provide a factory method for creating different types of messages.
The client code that uses this logger doesn’t need to know the exact implementation of the messages, it only needs to know the interface for creating them.
You can provide flexibility. If the object creation process changes, for example, a new class is added, only the factory method needs to be updated. No need to change the client code that uses those objects.

The How:

Replace direct object construction calls with calls to a specific factory method.
Create an object by calling the factory method, rather than invoking a constructor.

3. Adapter

Adapter is a type of structural design pattern that allows objects with incompatible interfaces to work together. It lies at an intermediary position between the client and the interface that the client wants to communicate with.

The Why:

Suppose you are building a video format conversion tool by following the Adapter design pattern:

Your software needs to adapt between different video formats, such as MP4, AVI, and FLV. It should be able to take a video in any format as input and convert it to the desired format. Communication between the target and the client happens via the adapter.
If in the future you want to support new formats, the pattern makes it easier because the video format conversion is decoupled from the specific video formats.

The How:

Define an adapter class that converts the incompatible interface of a class (adaptee) into another interface (target) clients expect.
Use this adapter to work with (reuse) other classes that do not have the required interface.

4. Decorator

Decorator is another type of structural design pattern that lets you attach new behaviors to objects without affecting the behavior of other objects from the same class. Even though inheritance can be used to alter the behavior of an object statically, a decorator helps you alter it dynamically as well.

The Why:

Suppose you are building a text editor:

The text editor can be your concrete component, and a spell checker can be your decorator.
The spell checker class should have the same interface as the text editor class so that it can be used as a decorator.
The spell-checker class can wrap the text editor and add spell-checking functionality to the editor. This makes it flexible to add new functionalities to the editor in the future.

The How:

Define an interface for the components and decorators.
Implement concrete components and concrete decorators that conform to the interface.
The decorators should have a reference to the components they decorate and delegate to the components to perform basic behaviors. The decorators will have methods that add new behavior.
Use the decorators to wrap the components in the desired order to attach the additional behavior.

Note - Adapter provides a different interface to its subject. Decorator provides an enhanced interface.

5. Observer

Observer is a behavioral design pattern that defines a one-to-many dependency between objects so that when one object, named the subject, changes its state, all of its dependents, named observers, are notified and updated automatically.

The Why

Suppose you are building a stock market website:

You can use the Observer pattern to update your users with the latest stock prices.
The website is the subject, and its users are the observers. Whenever the stock prices change, the website notifies its users.

The How

Define a Subject object.
Define Observer objects. An observer can subscribe or unsubscribe to a stream of events.
The relationship between the subject and observers shouldn’t be tightly coupled.
When the subject’s state changes, all registered observers are notified and updated.

6. Strategy

Strategy is another type of behavioral design pattern that allows you to define a family of algorithms, encapsulate each one, and make them interchangeable. It enables the client to select the algorithm’s behavior at run time.

The Why

Suppose you are creating software that has sorting functionality:

A sorting algorithm, such as quick sort, insertion sort, or bubble sort, can be selected at runtime and used to sort a collection of items.
The sorting strategies can be easily replaced or modified, which makes it possible to add or remove functionality as needed

The How

Create a Strategy interface that defines common behavior.
Create concrete strategy classes that conform to the Strategy interface. Each concrete strategy is a variation of the algorithm.
Create a context class that defines a reference to a sorting strategy object.
The context class should have a method that accepts a strategy object and invokes the selected strategy.

Conclusion

In conclusion, having a solid grasp of design patterns is crucial, especially as you advance your career in software engineering.

Reference

https://www.amazon.com/gp/product/0201633612/

https://refactoring.guru/

Elevate Your Django Projects with GraphQL Integration

Hana Belay — Tue, 31 Jan 2023 07:38:01 +0000

If you are a Django developer looking for something beyond the traditional REST APIs to add some extra power and flexibility to your projects, integrating GraphQL might be a good place to start.

GraphQL is a modern query language that gives you more control over your data and how it's retrieved. By combining the power of Django and GraphQL, you can unlock new capabilities and provide a more flexible and efficient way for clients to access and manipulate your data.

In this blog post, we will explore the benefits of using GraphQL with Django and how to integrate the two technologies.

Note:- If you encounter any issues throughout the tutorial, you can check out the code in the GitHub repository.

Prerequisite
GraphQL Introduction
Project Configuration
Graphene-Django
GraphQL Schema
Load Data to the Database for Testing
Testing the Schema
GraphQL Mutation
Conclusion

Prerequisite

This guide assumes that you have a basic understanding of the Django framework.

Introduction

GraphQL is a query language for an API that allows you to specify the data you want to retrieve or manipulate in a request. It is often used as an alternative (not a replacement) to REST APIs because:

It allows the client to request and get only what it needs; nothing more, nothing less.
It reduces the under-fetching or over-fetching of data.
It allows you to batch multiple operations into a single request.

The terms we are going to often use throughout the tutorial are schema and mutation.

A GraphQL schema is the core of a GraphQL server that defines the structure of the data and the operations that can be performed on that data.

Mutations are GraphQL operations that allow you to modify data on the server. They are often used to create, update, or delete data in a database.

Project Configuration

First, create a virtual environment and activate it:

python3 -m venv .venv
source .venv/bin/activate

Next, install Django and create a new Django project:

pip install django==4.1.5
django-admin startproject config .

Run migrations:

python manage.py migrate

Create a superuser:

python manage.py createsuperuser

Run the server to ensure the installation worked correctly:

python manage.py runserver

Great, now let’s create a new app called products. This app will be used to demonstrate the integration of Django and GraphQL.

python manage.py startapp products

Add it to the list of installed apps inside the settings:

# settings.py

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    # Local apps
    "products"
]

For the purpose of this tutorial, let’s build a simple product model. A product can have tags and prices that are associated with it. Go to the models.py file of the products app and add the following code:

# products/models.py

from django.conf import settings
from django.db import models
from django.template.defaultfilters import slugify
from django.utils.translation import gettext_lazy as _

User = settings.AUTH_USER_MODEL

def get_image_filename(instance, filename):
    name = instance.name
    slug = slugify(name)
    return f"products/{slug}-{filename}"

class ProductTag(models.Model):
    name = models.CharField(
        max_length=100, help_text=_("Designates the name of the tag.")
    )
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self) -> str:
        return self.name

class Product(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    name = models.CharField(max_length=200)
    tags = models.ManyToManyField(ProductTag, blank=True)
    desc = models.TextField(_("Description"), blank=True)
    thumbnail = models.ImageField(upload_to=get_image_filename, blank=True)
    url = models.URLField()
    quantity = models.IntegerField(default=1)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        ordering = ("-created_at",)

    def __str__(self):
        return self.name

class Price(models.Model):
    product = models.ForeignKey(Product, on_delete=models.CASCADE)
    price = models.DecimalField(decimal_places=2, max_digits=10)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self) -> str:
        return f"{self.product.name} {self.price}"

The Product model contains an image field for the thumbnail so let’s go ahead and install Pillow.

pip install pillow==9.3.0

Then, let’s register the models as follows:

# products/admin.py

from django.contrib import admin

from .models import Price, Product, ProductTag

class PriceAdmin(admin.StackedInline):
    model = Price

@admin.register(Product)
class ProductAdmin(admin.ModelAdmin):
    inlines = (PriceAdmin,)

    class Meta:
        model = Product

admin.site.register(ProductTag)
admin.site.register(Price)

The Price model is registered inline with the Product model so that we can add the prices of a product while creating the product inside the admin panel.

Since we are working with user-uploaded images, we need to set MEDIA_URL and MEDIA_ROOT in the settings:

# config/settings.py

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'

Next, configure the project's urls.py to serve user-uploaded media files during development.

# config/urls.py

from django.conf import settings
from django.conf.urls.static import static

# Media Assets
urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Let’s now test the functionality we have so far:

py mangage.py makemigrations
py manage.py migrate
py mangage.py runserver

Go to the admin panel http://localhost:8000/admin/ to play around.

Graphene-Django

Graphene-Django is a library built on top of Graphene (a Python library for building GraphQL APIs).

It provides some additional abstractions that make it easy to add GraphQL functionality to your Django project.

Let’s install it:

pip install graphene-django==3.0.0

Add it to the list of installed apps in the settings:

# config/settings.py

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "products",
    "graphene_django", # here
]

Hurray! Let’s move on to the next section where the fun begins.

GraphQL Schema

A GraphQL schema is the core of a GraphQL server that defines the structure of the data and the operations that can be performed on that data. It specifies the types of data that can be queried or modified, as well as the relationships between those types.

In a GraphQL API, the schema serves as a contract between the server and the client. The client can send a query or mutation to the server that specifies the data it wants to retrieve or manipulate, and the server will only execute the request if it is valid according to the schema. This helps to ensure that the client can only access or modify data that is allowed by the schema.

Head over to the products app and create a file called schema.py

# products/schema.py

from graphene_django import DjangoObjectType

from .models import Price, Product, ProductTag

class ProductTagType(DjangoObjectType):
    class Meta:
        model = ProductTag
        fields = ("id", "title")

class ProductType(DjangoObjectType):
    class Meta:
        model = Product
        fields = "__all__"

class PriceType(DjangoObjectType):
    class Meta:
        model = Price
        fields = "__all__"

We have created GraphQL types for each of our Django models. The types inherit from DjangoObjectType
DjangoObjectType automatically defines GraphQL fields that correspond to fields on the Django models. If you are familiar with Django Rest Framework, it is similar to ModelSerializer

Now we need a root type that specifies a set of operations and an entry point for queries. This is specified in the following Query class:

# products/schema.py

import graphene

class Query(graphene.ObjectType):
    tags = graphene.List(ProductTagType)
    products = graphene.List(ProductType)
    prices = graphene.List(PriceType)

    def resolve_tags(self, info, *args, **kwargs):
        return ProductTag.objects.all()

    def resolve_products(self, info, **kwargs):
        return Product.objects.all()

    def resolve_prices(self, info, *args, **kwargs):
        return Price.objects.all()

The Query class has the types as fields (tags, products, prices) and resolver functions to query the database for a specific model.

Now that we have our root type Query we need to pass it into the Schema

Add the following at the end of the schema.py file:

schema = graphene.Schema(query=Query)

Below is the entire schema.py file:

# products/schema.py

import graphene
from graphene_django import DjangoObjectType

from .models import Price, Product, ProductTag

class ProductTagType(DjangoObjectType):
    class Meta:
        model = ProductTag
        fields = "__all__"

class ProductType(DjangoObjectType):
    class Meta:
        model = Product
        fields = "__all__"

class PriceType(DjangoObjectType):
    class Meta:
        model = Price
        fields = "__all__"

class Query(graphene.ObjectType):
    tags = graphene.List(ProductTagType)
    products = graphene.List(ProductType)
    prices = graphene.List(PriceType)

    def resolve_tags(root, info):
        return ProductTag.objects.all()

    def resolve_products(root, info):
        return Product.objects.all()

    def resolve_prices(root, info):
        return Price.objects.all()

schema = graphene.Schema(query=Query, mutation=Mutation)

One of the biggest advantages of GraphQL is the ability to expose only one endpoint to the client. This is contrary to a REST API where we have to specify multiple endpoints.

Create a file named urls.py inside the products app and add the following:

# products/urls.py

from django.urls import path
from django.views.decorators.csrf import csrf_exempt
from graphene_django.views import GraphQLView

from .schema import schema

app_name = "products"

urlpatterns = [
    path("graphql", csrf_exempt(GraphQLView.as_view(graphiql=True, schema=schema))),
]

Django by default has a CSRF middleware that provides protection against Cross-Site Request Forgeries.
This middleware prevents frontend applications from posting to the graphql endpoint. One way to mitigate this is by wrapping the GraphQLView with the csrf_exempt decorator.

Finally, update the project’s urls.py file to include the URL configuration for the products app:

# config/urls.py

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path("admin/", admin.site.urls),
    path("", include("products.urls", namespace="products")),
]

Run the server and go to http://localhost:8000/graphql

Type in the following query and execute it:

{
  products {
    id
    name
    desc
    url
    quantity
  }
}

The output will look something like this:

That’s because we don’t have any data. To create some data for testing, we are going to use fixtures in the next section.

Load Data to the Database for Testing

To populate our database with some data, let’s use fixtures. A fixture is a collection of data that Django knows how to import into a database.

At the root of your project, create a file named data.json and add the following:

[
{
    "model": "auth.user",
    "pk": 2,
    "fields": {
        "password": "pbkdf2_sha256$390000$uVxVY1kKAqEwAbvQn0H3AX$A5EsaIcpX3eKVL71t9n1t/+wzZLvWIYtSqwERzW0gGU=",
        "last_login": null,
        "is_superuser": true,
        "username": "test",
        "first_name": "",
        "last_name": "",
        "email": "",
        "is_staff": true,
        "is_active": true,
        "date_joined": "2023-01-09T06:44:06.618Z",
        "groups": [],
        "user_permissions": []
    }
},
{
    "model": "products.producttag",
    "pk": 2,
    "fields": {
        "name": "Sci-Fi",
        "created_at": "2023-01-09T06:07:41.890Z",
        "updated_at": "2023-01-09T06:07:41.890Z"
    }
},
{
    "model": "products.producttag",
    "pk": 3,
    "fields": {
        "name": "Horror",
        "created_at": "2023-01-09T06:26:02.766Z",
        "updated_at": "2023-01-09T06:26:02.766Z"
    }
},
{
    "model": "products.producttag",
    "pk": 4,
    "fields": {
        "name": "Fantasy",
        "created_at": "2023-01-09T06:26:21.166Z",
        "updated_at": "2023-01-09T06:26:21.166Z"
    }
},
{
    "model": "products.product",
    "pk": 1,
    "fields": {
        "user": [
            "test"
        ],
        "name": "2001: A Space Odyssey",
        "desc": "This allegory about humanity’s exploration of the universe—and the universe’s reaction to humanity—is a hallmark achievement in storytelling that follows the crew of the spacecraft Discovery as they embark on a mission to Saturn. Their vessel is controlled by HAL 9000, an artificially intelligent supercomputer capable of the highest level of cognitive functioning that rivals—and perhaps threatens—the human mind.",
        "thumbnail": "",
        "url": "https://amzn.to/3leeblk",
        "quantity": 7,
        "created_at": "2023-01-09T06:28:49.806Z",
        "updated_at": "2023-01-09T06:28:49.807Z",
        "tags": [
            2
        ]
    }
},
{
    "model": "products.product",
    "pk": 2,
    "fields": {
        "user": [
            "test"
        ],
        "name": "It by Stephen King (1986)",
        "desc": "It should come as no surprise that Stephen King shows up on this list of the top horror books more than once. He is, after all, the reigning king of terror. This novel taps into a pretty pervasive phobia: clowns. Pennywise, the killer clown, dwells in the sewers of Derry, Maine, and he preys upon the young residents of the town by shapeshifting into their deepest fears. The group of kids (the so-called Losers Club) must band together to defeat him.",
        "thumbnail": "",
        "url": "https://www.amazon.com/dp/1444707868?tag=readerwp-20",
        "quantity": 1,
        "created_at": "2023-01-09T06:30:53.032Z",
        "updated_at": "2023-01-09T06:30:53.032Z",
        "tags": [
            3
        ]
    }
},
{
    "model": "products.product",
    "pk": 3,
    "fields": {
        "user": [
            "test"
        ],
        "name": "The Eye of the World, by Robert Jordan",
        "desc": "The Dark One, an evil force imprisoned inside a weakening cell, threatens the world. The Dragon Reborn, a reincarnated savior with powerful magical abilities, is born to a dying warrior woman on the slopes of a snowy mountain. Accompanied by a band of village youths, he seeks to defeat the Dark One, in The Wheel of Time, the sprawling, 14-book series. The depth of world-building is incredible, the characters indelible, and it comes to satisfying conclusion.",
        "thumbnail": "",
        "url": "https://www.amazon.com/dp/1250832365?ots=1&slotNum=1&imprToken=38c2ca9c-fad5-d50a-6ce&linkCode=ogi&tag=oprah-auto-20&ascsubtag=%5Bartid%7C10072.g.41315629%5Bsrc%7C%5Bch%7C%5Blt%7Csale%5Bpid%7C09d26eb0",
        "quantity": 1,
        "created_at": "2023-01-09T06:31:56.008Z",
        "updated_at": "2023-01-09T06:31:56.008Z",
        "tags": [
            4
        ]
    }
},
{
    "model": "products.price",
    "pk": 1,
    "fields": {
        "product": 1,
        "price": "100.00",
        "created_at": "2023-01-09T06:28:49.808Z",
        "updated_at": "2023-01-09T06:28:49.808Z"
    }
},
{
    "model": "products.price",
    "pk": 2,
    "fields": {
        "product": 2,
        "price": "90.00",
        "created_at": "2023-01-09T06:30:53.034Z",
        "updated_at": "2023-01-09T06:30:53.034Z"
    }
},
{
    "model": "products.price",
    "pk": 3,
    "fields": {
        "product": 3,
        "price": "70.00",
        "created_at": "2023-01-09T06:31:56.009Z",
        "updated_at": "2023-01-09T06:31:56.009Z"
    }
}
]

Then, run the following command:

python  manage.py loaddata data.json

You can log in to the admin panel with the following credentials and see the test data.

username: test
password: 123django

Tip:- To dump data into JSON you can use the following command:

python manage.py dumpdata --natural-foreign --exclude=auth.permission --exclude=contenttypes --exclude=sessions --exclude=admin.logentry --indent=4 > data.json

Testing the Schema

If you now go back to http://localhost:8000/graphql and type in the previous query, you will see the following output:

Interesting. To get related model fields like product tags and prices, you can use the following query:

{
  products {
    id
    name
    desc
    url
    quantity
    priceSet {
      id
    }
    tags {
      id
    }
  }
}

Follow up: write a query to fetch products of the same tag.

For image fields, consider using the library Graphene-file-upload because file uploading is not natively implemented in Graphene.

GraphQL Mutation

In GraphQL, a mutation is an operation that allows you to modify data through create, update, or delete operations.

Graphene-Django makes it really easy to perform mutations.

To demonstrate this, let’s create a mutation for creating a product tag. Inside the schema.py file, add the following class:

# products/schema.py

class CreateProductTag(graphene.Mutation):
    class Arguments:
        name = graphene.String(required=True)

    product_tag = graphene.Field(ProductTagType)

    def mutate(self, info, name):
        product_tag = ProductTag(name=name)
        product_tag.save()
        return CreateProductTag(product_tag=product_tag)

The inner class is used to specify the arguments for the create operation.
The class attribute product_tag specifies the response of the mutation.

Just like we created a Query class as an entry point for queries, we also need to create a Mutation class to use as an entry point for mutations:

# products/schema.py

class Mutation(graphene.ObjectType):
    create_product_tag = CreateProductTag.Field()

Update the schema to include mutation:

# products/schema.py

schema = graphene.Schema(query=Query, mutation=Mutation)

Run the server and type the following mutation to test it:

mutation {
  create_product_tag: createProductTag(name: "Comedy") {
    productTag {
      id
      name
    }
  }
}

Press the play button and you will see the following output:

Note:- Graphene automatically camelcases all field names for better compatibility with JavaScript clients.

Let’s do the same thing for update and delete operations:

# products/schema.py

class UpdateProductTag(graphene.Mutation):
    class Arguments:
        id = graphene.Int()
        name = graphene.String(required=True)

    product_tag = graphene.Field(ProductTagType)

    def mutate(root, info, id, name):
        tag = ProductTag.objects.get(id=id)
        tag.name = name
        return UpdateProductTag(product_tag=tag)

class DeleteProductTag(graphene.Mutation):
    class Arguments:
        id = graphene.Int()

    ok = graphene.Boolean()

    def mutate(root, info, id):
        ProductTag.objects.get(id=id).delete()
        return DeleteProductTag(ok=True)

class Mutation(graphene.ObjectType):
    create_product_tag = CreateProductTag.Field()
    update_product_tag = UpdateProductTag.Field()
    delete_product_tag = DeleteProductTag.Field()

Below is the updated schema.py file:

# products/schema.py

import graphene
from graphene_django import DjangoObjectType

from .models import Price, Product, ProductTag

class ProductTagType(DjangoObjectType):
    class Meta:
        model = ProductTag
        fields = "__all__"

class ProductType(DjangoObjectType):
    class Meta:
        model = Product
        fields = "__all__"

class PriceType(DjangoObjectType):
    class Meta:
        model = Price
        fields = "__all__"

class Query(graphene.ObjectType):
    tags = graphene.List(ProductTagType)
    products = graphene.List(ProductType)
    prices = graphene.List(PriceType)

    def resolve_tags(root, info):
        return ProductTag.objects.all()

    def resolve_products(root, info):
        return Product.objects.all()

    def resolve_prices(root, info):
        return Price.objects.all()

class CreateProductTag(graphene.Mutation):
    class Arguments:
        name = graphene.String(required=True)

    product_tag = graphene.Field(ProductTagType)

    def mutate(root, info, name):
        product_tag = ProductTag(name=name)
        product_tag.save()
        return CreateProductTag(product_tag=product_tag)

class UpdateProductTag(graphene.Mutation):
    class Arguments:
        id = graphene.Int()
        name = graphene.String(required=True)

    product_tag = graphene.Field(ProductTagType)

    def mutate(root, info, id, name):
        tag = ProductTag.objects.get(id=id)
        tag.name = name
        return UpdateProductTag(product_tag=tag)

class DeleteProductTag(graphene.Mutation):
    class Arguments:
        id = graphene.Int()

    ok = graphene.Boolean()

    def mutate(root, info, id):
        ProductTag.objects.get(id=id).delete()
        return DeleteProductTag(ok=True)

class Mutation(graphene.ObjectType):
    create_product_tag = CreateProductTag.Field()
    update_product_tag = UpdateProductTag.Field()
    delete_product_tag = DeleteProductTag.Field()

schema = graphene.Schema(query=Query, mutation=Mutation)

Alright, let’s test the operations.

Delete a product tag

Type in the following query to delete a product tag:

mutation{
  deleteProductTag(id:5){
    ok
  }
}

You will get an output like this:

{
  "data": {
    "deleteProductTag": {
      "ok": true
    }
  }
}

Update a product tag

And for an update try the following query:

mutation {
  updateProductTag(id: 2, name: "Updated Sci-Fi") {
    productTag{
      id
      name
    }
  }
}

The response is going to be:

{
  "data": {
    "updateProductTag": {
      "productTag": {
        "id": "2",
        "name": "Updated Sci-Fi"
      }
    }
  }
}

So far we have seen the CRUD operations on ProductTag model. As a follow-up, you can experiment with the other models.

Tip: One important feature if you use Django Rest Framework is that you can reuse your serializers with Graphene Django mutations! You can create a Mutation based on a serializer by using the SerializerMutation base class:

from graphene_django.rest_framework.mutation import SerializerMutation
from .serializers import ProductSerializer

class CreateProduct(SerializerMutation):
    class Meta:
        serializer_class = ProductSerializer

Conclusion

In conclusion, the Graphene-Django library makes it easy to get started with GraphQL integration by allowing you to use your existing Django models as the data source for your GraphQL API and automatically generate the schema. For more information, check out the documentation.

Furthermore, by leveraging the built-in authentication and permission systems of Django, you can easily control access to your GraphQL API. With all of these benefits, GraphQL integration is definitely worth considering for your next Django project.

Note:- Some of the sections of this tutorial (the first two paragraphs and the conclusion) were written with the help of an AI.

If you got lost somewhere throughout the guide, check out the project on GitHub

Happy coding! 🖤

Integrate Stripe Payments with Django By Building a Digital Products Selling App

Hana Belay — Mon, 26 Dec 2022 07:00:00 +0000

One of the great features of online selling is being able to process payments online. With the ever-growing online businesses, having a good payment processing system is necessary. Online selling has a lot of advantages among which are; low start-up and operating costs, high flexibility, a wide selection of available products, and improved customer experience.

In this tutorial, you will learn how to integrate Stripe to accept one-time payments for your digital products through a Django app. A digital product can be a book, for example, to which the buyer will be given access after completing the payment.

Stripe is a suite of APIs powering online payment processing and commerce solutions for internet businesses of all sizes. It is one of the most widely used tools for handling payments due to its ease of integration, convenience of use, and nice documentation.

There are two ways to accept one-time payments using Stripe. These are:

Stripe Checkout: This is a low-code payment integration that you can use to quickly integrate payments solution into your application.
Payment Intent: This provides a more custom experience to end users by storing necessary information about the payment and linking to a Stripe customer. It handles complex payment flows as well.

This tutorial is going to focus on Stripe Checkout. We are going to build an application where you as an admin can upload your products, and your customers (end users) will be able to purchase them.

Note:- If you encounter any issues throughout the tutorial, you can check out the code in the GitHub repository.

Prerequisite
Project Configuration
Building the Model
Setting Up the Views
Stripe Configuration
Stripe Checkout
Payment Confirmation Using WebHook
Give the Customer Access to the Product
Create Payment History
Conclusion

Prerequisite

This guide assumes that you are familiar with Django.

Project Configuration

First, create a virtual environment and activate it:

python3 -m venv .venv
source .venv/bin/activate

Next, install Django and create a new Django project:

pip install django==4.1.4
django-admin startproject config .

Run migrations:

python manage.py migrate

Create a superuser:

python manage.py createsuperuser

Run the server to ensure the installation worked correctly:

python manage.py runserver

Great, now let’s create a new app called products. This app will contain the model of the product we are selling, the views, and URL configurations that are related to it.

py manage.py startapp products

Add it to the installed apps list in the settings:

# config/settings.py

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    # Local apps
    'products',
]

Building the Model

To keep it simple for the main scope of this tutorial, we are going to build a simple product model. A product can have tags. In addition, we also want to create a price model so that we can track the changing prices of a product over time. Go to the models.py file of the products app and add the following code:

# products/models.py

from django.conf import settings
from django.db import models
from django.template.defaultfilters import slugify
from django.utils.translation import gettext_lazy as _

User = settings.AUTH_USER_MODEL

def get_image_filename(instance, filename):
    name = instance.name
    slug = slugify(name)
    return f"products/{slug}-{filename}"

class ProductTag(models.Model):
    name = models.CharField(
        max_length=100, help_text=_("Designates the name of the tag.")
    )
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self) -> str:
        return self.name

class Product(models.Model):
    name = models.CharField(max_length=200)
    tags = models.ManyToManyField(ProductTag, blank=True)
    desc = models.TextField(_("Description"), blank=True)
    thumbnail = models.ImageField(upload_to=get_image_filename, blank=True)
    url = models.URLField()
    quantity = models.IntegerField(default=1)

    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        ordering = ("-created_at",)

    def __str__(self):
        return self.name

class Price(models.Model):
    product = models.ForeignKey(Product, on_delete=models.CASCADE)
    price = models.DecimalField(decimal_places=2, max_digits=10)

    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self) -> str:
        return f"{self.product.name} {self.price}"

Note that the product has a url field that is going to be used to send the customer a link to the digital product you are selling (book).
The Product model also contains an image field for the thumbnail so let’s go ahead and install Pillow.

pip install pillow==9.3.0

Then, let’s register the models as follows:

# products/admin.py

from django.contrib import admin

from .models import Price, Product, ProductTag

class PriceAdmin(admin.StackedInline):
    model = Price

@admin.register(Product)
class ProductAdmin(admin.ModelAdmin):
    inlines = (PriceAdmin,)

    class Meta:
        model = Product

admin.site.register(ProductTag)
admin.site.register(Price)

The Price model is registered inline with the Product model so that we can add the prices of a product while creating the product inside the admin panel.

Since we are working with user-uploaded images, we need to set MEDIA_URL and MEDIA_ROOT in the settings:

# config/settings.py

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'

Next, configure the project's urls.py to serve user-uploaded media files during development.

# config/urls.py

from django.conf import settings
from django.conf.urls.static import static

# Media Assets
urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Great, let’s now test the functionality we have so far:

py manage.py makemigrations
py manage.py migrate
py manage.py runserver

Go to the admin panel and you can now create products

Setting Up the Views

Let’s now create views and templates to list our available products and view them in detail.

# products/views.py

from django.views import View
from django.views.generic import DetailView, ListView

from .models import Price, Product

class ProductListView(ListView):
    model = Product
    context_object_name = "products"
    template_name = "products/product_list.html"

class ProductDetailView(DetailView):
    model = Product
    context_object_name = "product"
    template_name = "products/product_detail.html"

    def get_context_data(self, **kwargs):
        context = super(ProductDetailView, self).get_context_data()
        context["prices"] = Price.objects.filter(product=self.get_object())
        return context

Then, update the project’s urls.py file to include the URL configuration for products app:

# config/urls.py

from django.urls import include, path

urlpatterns = [
    #...
    path("", include("products.urls", namespace="products")),
]

Create a urls.py file inside the products app and add the URL configuration for the product list and detail views:

# products/urls.py

from django.urls import path

from .views import (
    ProductDetailView,
    ProductListView,
)

app_name = "products"

urlpatterns = [
    path("", ProductListView.as_view(), name="product-list"),
    path("<int:pk>/", ProductDetailView.as_view(), name="product-detail"),
]

Then, create a templates folder at the root of your project:

mkdir templates

Add it to the settings:

# config/settings.py

TEMPLATES = [
    {
        "DIRS": [BASE_DIR / "templates"],
        ...
    },
]

Inside the templates directory, create a file named base.html that will be used as a base template for all the other templates we are going to create. Note that we are using Bootstrap for styling.

<!DOCTYPE html>
<html lang="en">
  <head>
    <!-- Required meta tags -->
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1, shrink-to-fit=no"
    />

    <!-- Bootstrap CSS -->
    <link
      rel="stylesheet"
      href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css"
      integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm"
      crossorigin="anonymous"
    />

    <!--Font awesome icons -->
    <link
      rel="stylesheet"
      href="https://use.fontawesome.com/releases/v5.8.2/css/all.css"
      integrity="sha384-oS3vJWv+0UjzBfQzYUhtDYW+Pj2yciDJxpsK1OYPAYjqT085Qq/1cq5FLXAZQ7Ay"
      crossorigin="anonymous"
    />

    {% block script %}{% endblock %}

    <title>{% block title %} {% endblock %}</title>
  </head>
  <body>
    <div class="container p-3 my-3">
      <div class="row">
        <div class="col-md-12">
          <!--Any flash messages pop up in any page because this is the base template-->
          {% if messages %}
          <div class="alert alert-dismissible" role="alert">
            {% for message in messages %}
            <div class="alert alert-{{ message.tags }}">{{ message }}</div>
            {% endfor %}
            <button
              type="button"
              class="close"
              data-dismiss="alert"
              aria-label="Close"
            >
              <span aria-hidden="true">&times;</span>
            </button>
          </div>
          {% endif %} {% block content %}{% endblock %}
        </div>
      </div>
    </div>

    <!-- jQuery first, then Popper.js, then Bootstrap JS -->
    <script
      src="https://code.jquery.com/jquery-3.2.1.slim.min.js"
      integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN"
      crossorigin="anonymous"
    ></script>
    <script
      src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js"
      integrity="sha384-ApNbgh9B+Y1QKtv3Rn7W3mgPxhU9K/ScQsAP7hUibX39j7fakFPskvXusvfa0b4Q"
      crossorigin="anonymous"
    ></script>
    <script
      src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js"
      integrity="sha384-JZR6Spejh4U02d8jOt6vLEHfe/JQGiRRSQQxSfFWpi1MquVdAyjUar5+76PVCmYl"
      crossorigin="anonymous"
    ></script>
  </body>
</html>

Next, create a folder named products inside the templates folder, and inside it, create 2 files named product_list.html and product_detail.html

{% comment %} templates/products/product_list.html {% endcomment %}

{% extends "base.html" %} {% block title %} Products {% endblock title%} {% block content %} {% for product in products %}
<div class="card" style="width: 18rem">
  <img
    class="card-img-top"
    src="{{product.thumbnail.url}}"
    alt="Card image cap"
  />
  <div class="card-body">
    <h5 class="card-title">{{product.name}}</h5>
    <p class="card-text">{{product.desc}}</p>
    <a
      href="{% url 'products:product-detail' product.id %}"
      class="btn btn-primary"
      >View Detail</a
    >
  </div>
</div>
{% endfor %} {% endblock content %}

{% comment %} templates/products/product_detail.html {% endcomment %}

{% extends "base.html" %} 
{% block title %} Buy Product {% endblock title%} 
{% block content %}
<div class="card-deck">
  {% for price in prices %}
  <div class="card">
    <img
      class="card-img-top"
      src="{{product.thumbnail.url}}"
      alt="Card image cap"
    />
    <div class="card-body">
      <h5 class="card-title">{{product.name}}</h5>
      <p class="card-text">{{product.desc}}</p>
      <div class="card-text">
        <h5 class="card-text">${{ price.price }}</h5>
        <form
          action=""
          method="POST"
        >
          {% csrf_token %}
          <button type="submit" class="btn btn-primary">Checkout</button>
        </form>
      </div>
    </div>
  </div>
  {% endfor %}
</div>
{% endblock content %}

On the product detail page, we are looping through and displaying the different prices of the product with a checkout button attached.
In this tutorial, the only variation for a product is its price. However, you can configure the models to include and update the structure as it seems fit to your requirements.

Go to http://localhost:8000/admin/ and create a sample product. Then go to the index page http://localhost:8000 to see the product and its detail.

Stripe Configuration

First, install the Stripe package which provides convenient access to the Stripe API from Python applications:

pip install stripe==5.0.0

Next, log in to your Stripe account or create a new one and head over to the dashboard

Click on “Developers” then on the left sidebar click on “API keys”:

Grab the public and secret keys for use in your project. Note that you will get a different pair in production (when test mode is disabled).

Then, create a .env file at the root of your project:

touch .env

and store the keys in your environment file:

# Stripe
STRIPE_PUBLISHABLE_KEY=
STRIPE_SECRET_KEY=

In order to access these keys in the project, we need to install Python Decouple:

pip install python-decouple==3.6

Then, update the settings to include the public and secret keys you grabbed from the Stripe dashboard:

# config/settings.py

from decouple import config

# Stripe
STRIPE_PUBLISHABLE_KEY = config('STRIPE_PUBLISHABLE_KEY')
STRIPE_SECRET_KEY = config('STRIPE_SECRET_KEY')

Finally, make sure that you have set up an account name on the Stripe Dashboard https://dashboard.stripe.com/settings/account

Stripe Checkout

In this section, we are going to create a Stripe checkout session. Normally, you would want to put payment-related logic into its own app, however, for the scope of this tutorial, we will use the products app we created earlier to create the views for a Stripe checkout.

Before proceeding, let’s first understand what the flow is going to look like:

We will create a Checkout session when the “Checkout” button is pressed.
The Checkout Session is unique with different properties among which is a URL that redirects customers to a Stripe-hosted payment page. This is done by using Stripe’s JavaScript module.
Customers will fill in their payment details like card number and complete the transaction.
Customers will be redirected to a success page for successful payments and to a cancellation page for canceled payments.
After the transaction is completed, payment is confirmed using webhook.

Head over to products/views.py and create the Stripe checkout session view as follows:

# products/views.py

import stripe
from django.conf import settings
from django.shortcuts import redirect
from django.views import View

from .models import Price

stripe.api_key = settings.STRIPE_SECRET_KEY

class CreateStripeCheckoutSessionView(View):
    """
    Create a checkout session and redirect the user to Stripe's checkout page
    """

    def post(self, request, *args, **kwargs):
        price = Price.objects.get(id=self.kwargs["pk"])

        checkout_session = stripe.checkout.Session.create(
            payment_method_types=["card"],
            line_items=[
                {
                    "price_data": {
                        "currency": "usd",
                        "unit_amount": int(price.price) * 100,
                        "product_data": {
                            "name": price.product.name,
                            "description": price.product.desc,
                            "images": [
                                f"{settings.BACKEND_DOMAIN}/{price.product.thumbnail}"
                            ],
                        },
                    },
                    "quantity": price.product.quantity,
                }
            ],
            metadata={"product_id": price.product.id},
            mode="payment",
            success_url=settings.PAYMENT_SUCCESS_URL,
            cancel_url=settings.PAYMENT_CANCEL_URL,
        )
        return redirect(checkout_session.url)

Here are a couple of things to note from the above code:

The view will be called with a price id URL parameter.
The view creates a new Checkout Session by calling the stripe.checkout.Session.create method with the appropriate parameters.
One of the parameters is line_items. It provides a list of items the customer is purchasing.
Stripe allows you to create product and price objects in the dashboard. However, in our case, we are managing the product and prices ourselves so we need to create the Stripe Price object inline. To do so, we used the price_data parameter of line_items by passing in the currency, unit amount, product name, description, and image. For a list of fields and parameters, you can use, check out the doc.
The metadata parameter defines a set of key-value pairs that you can attach to an object. You can store additional information about the object using it. We will use the metadata value later when we create a webhook handler.
We are implementing a one-time payment so we used mode with payment value.
The success and cancel URLs define the URLs the customer will be redirected to when the transaction is completed, or canceled respectively.

Now, update the .env file to include the following environment variables:

BACKEND_DOMAIN=http://127.0.0.1:8000
PAYMENT_SUCCESS_URL=http://127.0.0.1:8000/success/
PAYMENT_CANCEL_URL=http://127.0.0.1:8000/cancel/

Then, update the settings:

# config/settings.py

BACKEND_DOMAIN = config("BACKEND_DOMAIN")
PAYMENT_SUCCESS_URL = config("PAYMENT_SUCCESS_URL")
PAYMENT_CANCEL_URL = config("PAYMENT_CANCEL_URL")

Add the URL configuration for the CreateStripeCheckoutSessionView

# products/urls.py

from django.urls import path

from .views import CreateStripeCheckoutSessionView

app_name = "products"

urlpatterns = [
    path(
        "create-checkout-session/<int:pk>/",
        CreateStripeCheckoutSessionView.as_view(),
        name="create-checkout-session",
    ),
]

Great, we now need to update the product_detail template so that the Checkout form is functional:

{% comment %} templates/products/product_detail.html {% endcomment %}

{% extends "base.html" %} 
{% block title %} Buy Product {% endblock title%} 
{% block script %} <script src="https://js.stripe.com/v3/"></script> {% endblock script%} 
{% block content %}
<div class="card-deck">
  {% for price in prices %}
  <div class="card">
    <img
      class="card-img-top"
      src="{{product.thumbnail.url}}"
      alt="Card image cap"
    />
    <div class="card-body">
      <h5 class="card-title">{{product.name}}</h5>
      <p class="card-text">{{product.desc}}</p>
      <div class="card-text">
        <h5 class="card-text">${{ price.price }}</h5>
        <form
          action="{% url 'products:create-checkout-session' price.id %}"
          method="POST"
        >
          {% csrf_token %}
          <button type="submit" class="btn btn-primary">Checkout</button>
        </form>
      </div>
    </div>
  </div>
  {% endfor %}
</div>
{% endblock content %}

In the above code:

We added the Stripe.js library at the top.
We updated the form action attribute to send form data to the CreateStripeCheckoutSessionView

Let’s also add payment success and cancel views:

# products/views.py

from django.views.generic import TemplateView

class SuccessView(TemplateView):
    template_name = "products/success.html"

class CancelView(TemplateView):
    template_name = "products/cancel.html"

Create the templates (success.html and cancel.html) for the above 2 views inside templates/products directory.

Success.html

{% comment %} templates/products/success.html {% endcomment %}

{% extends "base.html" %} 
{% block title %} Success {% endblock title%} 
{% block content %}
<div class="alert alert-success" role="alert">
  Thanks for purchasing our product
  <a
      href="{% url 'products:product-list' %}"
      >Go to Products</a
    >
</div>
{% endblock content %}

Cancel.html

{% comment %} templates/products/cancel.html {% endcomment %}

{% extends "base.html" %} 
{% block title %} Cancel {% endblock title%} 
{% block content %}
<div class="alert alert-info" role="alert">
  Forgot to add something to your cart?
  <a
      href="{% url 'products:product-list' %}"
      >Go to Products</a
    >
</div>
{% endblock content %}

Finally, configure the routes for success and cancel views:

# products/urls.py

from django.urls import path

from .views import CancelView SuccessView

app_name = "products"

urlpatterns = [
    path("success/", SuccessView.as_view(), name="success"),
    path("cancel/", CancelView.as_view(), name="cancel"),
]

Time to test the functionality, head over to the product detail page (here I have one product with three different prices):

Then click the Checkout button on one of the products and you will get redirected to the Stripe checkout page:

As mentioned in the docs too, use the following form fields for testing:

For card number use 4242 4242 4242 4242
For Date use a valid future date, such as 12/34
Use any three-digit CVC

You can use any value you like for the other fields.

Great, after you click the Pay button, you will be redirected to the success page:

To make sure everything worked correctly, head over to https://dashboard.stripe.com/test/payments and you will see your recent payment listed:

Everything seems to be working fine now, However, even if the payment failed, the user will be redirected to the success page i.e. being redirected to the success page doesn’t guarantee a successful payment. Therefore, we need a way to ensure the process went smoothly. This is where WebHooks come into play.

Payment Confirmation Using WebHook

Stripe uses webhooks to notify your application when an event happens. Although there are a couple of events that you can handle, the event we are interested in right now is the checkout.session.completed event that occurs when a Checkout Session has been successfully completed.

First and foremost install the Stripe CLI tool for your OS.

Then, run the following command to send all Stripe events in test mode to a local webhook endpoint called /webhooks/stripe/

stripe listen --forward-to localhost:8000/webhooks/stripe/

Copy the webhook secret key generated by running the above command and paste it into the .env file found at the root of your project:

STRIPE_WEBHOOK_SECRET=

Update the settings as well:

STRIPE_WEBHOOK_SECRET = config("STRIPE_WEBHOOK_SECRET")

Great, now head over to products/views.py and create the webhook handler as an HTTP endpoint:

# products/views.py

import stripe
from django.conf import settings
from django.http import HttpResponse
from django.utils.decorators import method_decorator
from django.views import View
from django.views.decorators.csrf import csrf_exempt
from .models import Price, Product

stripe.api_key = settings.STRIPE_SECRET_KEY

@method_decorator(csrf_exempt, name="dispatch")
class StripeWebhookView(View):
    """
    Stripe webhook view to handle checkout session completed event.
    """

    def post(self, request, format=None):
        payload = request.body
        endpoint_secret = settings.STRIPE_WEBHOOK_SECRET
        sig_header = request.META["HTTP_STRIPE_SIGNATURE"]
        event = None

        try:
            event = stripe.Webhook.construct_event(payload, sig_header, endpoint_secret)
        except ValueError as e:
            # Invalid payload
            return HttpResponse(status=400)
        except stripe.error.SignatureVerificationError as e:
            # Invalid signature
            return HttpResponse(status=400)

        if event["type"] == "checkout.session.completed":
            print("Payment successful")

        # Can handle other events here.

        return HttpResponse(status=200)

Note that we have used the csrf_exempt decorator to make the view exempt from the CSRF protection ensured by Django’s middleware This allows us to receive data from another domain (Stripe) even if it has no CSRF token.
Stripe can optionally sign the webhook events it sends to your endpoints by including a signature in each event’s Stripe-Signature header. By adding this, we are verifying that the events were indeed sent by Stripe and not by a third party.

Add the URL configuration:

# products/urls.py

from django.urls import path

from .views import StripeWebhookView

app_name = "products"

urlpatterns = [
    path("webhooks/stripe/", StripeWebhookView.as_view(), name="stripe-webhook"),
]

Since we have configured Stripe earlier in this section to send all events to a local endpoint named webhooks/stripe/, make sure the name of the URL is also /webhooks/stripe/

Let's test it. Now when you make a payment, you will see the payment successful output on the console:

Give the Customer Access to the Product

We now need to give the customer access to the product he/she purchased upon successful payment. Since we are selling a digital product (book), we can do so by sending the user an email containing a link to the product.

Go to products/views.py and update the webhook as follows:

# products/views.py

import stripe
from django.conf import settings
from django.core.mail import send_mail # Add this
from django.http import HttpResponse
from django.utils.decorators import method_decorator
from django.views import View
from django.views.decorators.csrf import csrf_exempt
from .models import Price, Product

stripe.api_key = settings.STRIPE_SECRET_KEY

@method_decorator(csrf_exempt, name="dispatch")
class StripeWebhookView(View):
    """
    Stripe webhook view to handle checkout session completed event.
    """

    def post(self, request, format=None):
        payload = request.body
        endpoint_secret = settings.STRIPE_WEBHOOK_SECRET
        sig_header = request.META["HTTP_STRIPE_SIGNATURE"]
        event = None

        try:
            event = stripe.Webhook.construct_event(payload, sig_header, endpoint_secret)
        except ValueError as e:
            # Invalid payload
            return HttpResponse(status=400)
        except stripe.error.SignatureVerificationError as e:
            # Invalid signature
            return HttpResponse(status=400)

        if event["type"] == "checkout.session.completed":
            print("Payment successful")

            # Add this
            session = event["data"]["object"]
            customer_email = session["customer_details"]["email"]
            product_id = session["metadata"]["product_id"]
            product = get_object_or_404(Product, id=product_id)

            send_mail(
                subject="Here is your product",
                message=f"Thanks for your purchase. The URL is: {product.url}",
                recipient_list=[customer_email],
                from_email="your@email.com",
            )

        # Can handle other events here.

        return HttpResponse(status=200)

Remember the product_id we passed as metadata in the CreateStripeCheckoutSessionView? we are using that to get the product URL and send it to the user through his/her email.

For testing purposes, we can use the console email backend so update the settings as follows:

# config/settings.py

EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend"

Now, test the payment process again and you will get an email on your console with a link to the product.

Create Payment History

Aside from making sure the payment went smoothly, you may also want to keep a user’s payment history in your database. To do so, let’s first create a PaymentHistory model with the following fields:

# products/models.py

class PaymentHistory(models.Model):
    PENDING = "P"
    COMPLETED = "C"
    FAILED = "F"

    STATUS_CHOICES = (
        (PENDING, _("pending")),
        (COMPLETED, _("completed")),
        (FAILED, _("failed")),
    )

    email = models.EmailField(unique=True)
    product = models.ForeignKey(Product, on_delete=models.CASCADE)
    payment_status = models.CharField(
        max_length=1, choices=STATUS_CHOICES, default=PENDING
    )
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.product.name

Then, in the webhook view, create a payment history object upon a successful payment:

# products/views.py

from .models import PaymentHistory # Add this

@method_decorator(csrf_exempt, name="dispatch")
class StripeWebhookView(View):
    """
    Stripe webhook view to handle checkout session completed event.
    """

    def post(self, request, format=None):
        payload = request.body
        endpoint_secret = settings.STRIPE_WEBHOOK_SECRET
        sig_header = request.META["HTTP_STRIPE_SIGNATURE"]
        event = None

        try:
            event = stripe.Webhook.construct_event(payload, sig_header, endpoint_secret)
        except ValueError as e:
            # Invalid payload
            return HttpResponse(status=400)
        except stripe.error.SignatureVerificationError as e:
            # Invalid signature
            return HttpResponse(status=400)

        if event["type"] == "checkout.session.completed":
            print("Payment successful")
            session = event["data"]["object"]
            customer_email = session["customer_details"]["email"]
            product_id = session["metadata"]["product_id"]
            product = get_object_or_404(Product, id=product_id)

            send_mail(
                subject="Here is your product",
                message=f"Thanks for your purchase. The URL is: {product.url}",
                recipient_list=[customer_email],
                from_email="test@gmail.com",
            )

            PaymentHistory.objects.create(
                email=customer_email, product=product, payment_status="completed"
            ) # Add this

        # Can handle other events here.

        return HttpResponse(status=200)

Conclusion

In this tutorial, we have created a minimal product listing and checkout functionality using Stripe. Your next steps can be integrating Celery for sending emails upon successful payment, registration/login system for your customers, updating the user interface, expanding the model structure, and so on.

If you got lost somewhere throughout the guide, check out the project on GitHub

Happy coding! 🖤

When to Use Functional Programming vs OOP

Hana Belay — Mon, 12 Dec 2022 07:00:00 +0000

Back in the old days, software projects were relatively simple in terms of scope and lines of code. However, through time, software projects have become drastically complex and the good old procedural programming paradigm no longer suffices. The more your software becomes complex, the more it is prone to bugs. Therefore, you need a way of managing and structuring your project in a way that is easy to debug, read, and scale.

A programming paradigm is a way or technique to solve a given problem using some tools and guidelines. A language may support multiple paradigms or just a single one. Most of the paradigms fall into either imperative or declarative.

The imperative style follows a series of computational steps by changing state. Programming paradigms that fall into this category include procedural programming (one of the oldest ones where instructions are grouped into procedures) and object-oriented programming which we will see later on.

The alternative declarative style focuses on what a program should do instead of the steps that it needs to follow. It does so without producing a change in state or a side effect. An example in this category is functional programming.

Today, we have object-oriented and functional programming at the forefront of programming paradigms. These relatively newer programming paradigms coupled with an improved software development process provide ways to cope with the complexity of code.

In this article, we are going to look at these two paradigms and compare them. Let’s get started!

Object Oriented Programming

A program in OOP is a group of objects that have an attribute and behavior.

Attribute - is the characteristics of a real-world object. For example, a student has an ID and a name. These attributes correspond to data that is held in variables.
Behavior - is the action an object performs in response to an event. For example, a student submits an assignment when told to do so by the teacher. These correspond to functions that are called to process some data and do something like displaying it on the console for instance.

The attribute and behavior together form a single unit called an object. Thus, in OOP, you think about how you can map real-world objects to objects in the programming sense. This could be just about anything; from physical objects to elements of a computer system.

A concept that is often associated with objects is class. Class is a group of similar objects. It is a blueprint that defines certain properties and behaviors for a group of related objects.

Here is a simple class diagram for a Student class:

There are four pillars of OOP. These are:

Inheritance is the concept of dividing classes into sub-classes. For example, a vehicle class can be divided into cars, buses, etc. In this approach, the child classes share common characteristics with the parent class while also adding their own features. The main advantage of this is the re-usability of code (DRY).
Abstraction is the concept of showing necessary information while hiding unnecessary implementation details. This decreases complexity and improves extensibility. Just like you don’t need to know how a car engine works to drive a car, you don’t need to know the meticulous details of how certain methods of a particular class work.
Encapsulation is the concept of restricting access to some data and methods of a class. You don’t need to access what you don’t need to access. This helps prevent accidental usage of data.
Polymorphism is the ability of methods to take on different forms. Polymorphism allows you to have a unique implementation of the same method. Concepts included in polymorphism are method overloading and method overriding.

The above concepts of OOP are highly dependent on one another. You can’t have polymorphism without inheritance for example. It is the relationship between objects through the different pillars that make up OOP.

Functional Programming

How many times have you scratched your head because the function you wrote didn’t behave as expected? Side effects of a function can introduce a lot of bugs into your code. This is where functional programming really shines. The foundational mathematical principle for functional programming is lambda calculus. Lambda calculus is an elegant representation of a function from a computational perspective. Expressions in lambda calculus are built using the following three things:

Variables
Building functions (lambda notation - λ)
and a way of applying functions

For example; a simple lambda expression for the increment operator may look like λx.x+1

In functional programming functions are pure. This means that functions take an input and produce an output without modifying the input.

For example, if you have a function getSqrt() that returns the square root of a number, given the same number (input), it should always return the same output for the square root.

In functional programming, you can look at a function and reason about it. This makes code readable and easier to test. Since functions in functional programming don’t have a side effect, you can run them side by side. They can’t interfere with one another. This makes functional programming very efficient for writing parallel and asynchronous programs.

Functions in functional programming are also first-class citizens. This means that they can be treated as primitives like integers and support all available operations; they can be stored in a variable, passed as an argument to another function, and returned as results.

Another concept in functional programming is higher-order functions and recursion. Instead of the traditional loop construct, functional languages take a declarative approach and use recursive functions and higher-order functions for iteration. A higher-order function (HOF) either takes a function as an argument or returns it. HOF is possible because functions are first-class citizens.

In functional programming, most of the data structures are immutable. Immutability is being unable to be changed. You cannot modify the value of a variable once it has been created. The only way to change it is to create a new one.

Although the functional programming paradigm is relatively less popular than OOP or other imperative programming paradigms, nowadays it is used in many real-world applications. Haskell, a purely functional programming language, is used in Facebook, for example, for spam filtering.

Comparison

OOP is imperative; it follows a clear set of computational steps to follow to get to the final result. Functional programming, on the other hand, is declarative; it describes the “what” i.e. what you want to achieve rather than the “how”.

The idea of executing commands in a sequence is pointless in functional programming because there is no change in state or a side effect.

Immutability together with the concept of pure functions makes functional programming easier to work with ****parallel and asynchronous programs.

Most languages nowadays have built-in support for both OOP and functional programming. For example, you can write a program in a functional programming paradigm using languages like Python or JavaScript. Functions like map and filter are higher-order functions. Thus, you can always have the best of both worlds. If you want to use a fully functional programming language, you have Haskell and many others such as Erlang.

Programming paradigms are different ways of solving a problem. Thus, if the problem can be solved by performing a set of computational steps on a growing number of entities, OOP is a good choice. On the other hand, functional programming is a good choice if you are going to have a growing number of operations on a fixed set of entities.

Functional programming shines when complexity is involved. As mentioned in the previous section, functions in functional programming are pure, immutable, and have no side effects. Thus, you can write code that has fewer bugs, more test coverage, and high scaling.

A program written in a functional programming paradigm uses a lot of memory because it always requires you to create new objects (immutability). A program written in the OOP paradigm can become less efficient as the complexity of the code grows because of the complex relationship between classes.

Functional programming is also used a lot in the frontend space of web development, so having an understanding of how things work can be really handy.

In OOP, you can have a smooth transition from real-world objects to objects in the programming sense whereas, in functional programming, the transition may not be as smooth.

At the end of the day though, it’s up to you and your team to assess your requirements, consider different variables like development time, community support, scalability, etc. and pick the paradigm that works best for your case.

Happy coding! 🖤

What’s your go-to paradigm? Let me know in the comments section below.

References

https://faculty.ksu.edu.sa/sites/default/files/ObjectOrientedProgramminginC4thEdition.pdf

https://doc.lagout.org/programmation/Functional Programming/Functional Programming For The Real World.pdf

Build a Blog API With JWT Authentication Using Django Rest Framework

Hana Belay — Wed, 07 Dec 2022 06:10:28 +0000

Django REST framework is a powerful and flexible toolkit for building Web APIs. You can easily build a REST API using DRF and consume the endpoints from a React, Angular, or other Frontend application. DRF provides a lot of features out of the box to make the development process easier and faster. In this tutorial, we will build a blog API with the following features:

Custom user model where email is the unique identifier instead of email.
JWT-based authentication.
Ability to create, retrieve, update, and delete posts.
Like/Dislike feature for posts.
Ability to comment on posts.

Note:- If you encounter any issues throughout the tutorial, you can check out the code in the GitHub repository.

Prerequisite
Project Configuration
Custom User Model in Django for Email-Based Auth
User Profile
JWT Authentication
User Registration and Login Endpoints
The Blog API

Prerequisite

This guide assumes that you have intermediate-level knowledge of Django and Django Rest Framework.

Project Configuration

First, create a virtual environment and activate it:

python3 -m venv .venv
source .venv/bin/activate

Next, install Django and create a new Django project:

pip install django==4.1.2
django-admin startproject config .

Custom User Model in Django for Email-Based Auth

One of the things that make Django really great is its built-in User model that comes with username-based authentication. In no time, you can have authentication that works out of the box. However, not all projects need username and password pair for authentication, or in some cases, you might want to include additional fields in the built-in User model. Either way, you are in luck because Django also provides room for customization. In this tutorial, we will tweak the default User model to use email as the unique primary identifier of users instead of a username.

Other use cases for a custom user model include:

Including other unique fields for authentication like a phone number.
To stack all user information, be it auth-related or non-auth fields all in the User model.

Alright, let’s now create an app named users that will contain the logic we just talked about.

py manage.py startapp users

Add it to the installed apps list in the settings:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    # Local apps
    'users',
]

There are two ways you can customize the User model. Either by extending from AbstractUser or AbstractBaseUser

What’s the difference and when should you use one over the other? Glad you asked.

AbstractUser: Are you satisfied with the existing fields in the built-in User model but do you want to use email as the primary unique identifier of your users or perhaps remove the username field? or do you want to add fields to the existing User? If yes, AbstractUser is the right option for you.
AbstractBaseUser: This class contains authentication functionality but no fields, so you have to add all the necessary fields when you extend from it. You probably want to use this to have more flexibility on how you want to handle users.

Note: If you’re starting a new project, it’s highly recommended to set up a custom user model, even if the default User model is sufficient for you. This model behaves identically to the default user model, but you’ll be able to customize it in the future if the need arises:

from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    pass

Custom Model Manager

A Manager is a class that provides an interface through which database query operations are provided to Django models. You can have more than one manager for your model.

Consider this model:

from django.db import models

class Car(models.Model):
    pass

To get all instances of Car, you will use Car.objects.all()

objects is the default name that Django managers use. To change this name, you can do the following:

from django.db import models

class Car(models.Model):
    cars = models.Manager();

Now, to get all instances of car, you should use Car.cars.all()

For our custom user model, we need to define a custom manager class because we are going to modify the initial Queryset that the default Manager class returns. We do this by extending from BaseUserManager and providing two additional methods create_user and create_superuser

Create a file named managers.py inside the users app and put the following:

# users/managers.py

from django.contrib.auth.base_user import BaseUserManager
from django.utils.translation import gettext_lazy as _

class CustomUserManager(BaseUserManager):
    """
    Custom user model manager where email is the unique identifier
    for authentication instead of usernames.
    """

    def create_user(self, email, password, **extra_fields):
        if not email:
            raise ValueError(_("Users must have an email address"))
        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save()
        return user

    def create_superuser(self, email, password, **extra_fields):
        extra_fields.setdefault("is_staff", True)
        extra_fields.setdefault("is_superuser", True)
        extra_fields.setdefault("is_active", True)

        if extra_fields.get("is_staff") is not True:
            raise ValueError(_("Superuser must have is_staff=True."))
        if extra_fields.get("is_superuser") is not True:
            raise ValueError(_("Superuser must have is_superuser=True."))
        return self.create_user(email, password, **extra_fields)

Then, create the custom user model as follows:

# users/models.py

from django.contrib.auth.models import AbstractUser
from django.utils.translation import gettext_lazy as _

from .managers import CustomUserManager

class CustomUser(AbstractUser):
    email = models.EmailField(_("email address"), unique=True)

    USERNAME_FIELD = "email"
    REQUIRED_FIELDS = ["username"]

    objects = CustomUserManager()

    def __str__(self):
        return self.email

USERNAME_FIELD specifies the name of the field on the user model that is used as the unique identifier. In our case it’s email.
REQUIRED_FIELDS A list of the field names that will be prompted when creating a superuser via the createsuperuser management command. This doesn’t have any effect in other parts of Django like when creating a user in the admin panel.

Next, we need to tell Django about the new model that should be used to represent a User. This is done as follows:

# config/settings.py

AUTH_USER_MODEL = 'users.CustomUser'

Finally, create and apply migrations:

py manage.py makemigrations
py manage.py migrate

Forms

You need to extend Django's built-in UserCreationForm and UserChangeForm forms so that they can use the new user model that we are working with.

Create a file named forms.py inside the users app and add the following:

# users/forms.py

from django.contrib.auth.forms import UserChangeForm, UserCreationForm

from .models import CustomUser

class CustomUserCreationForm(UserCreationForm):
    class Meta:
        model = CustomUser
        fields = ("email",)

class CustomUserChangeForm(UserChangeForm):
    class Meta:
        model = CustomUser
        fields = ("email",)

Admin

Tell the admin panel to use these forms by extending from UserAdmin in users/admin.py

# users/admin.py

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin

from .forms import CustomUserChangeForm, CustomUserCreationForm
from .models import CustomUser

@admin.register(CustomUser)
class CustomUserAdmin(UserAdmin):
    add_form = CustomUserCreationForm
    form = CustomUserChangeForm

    model = CustomUser

    list_display = (
        "username",
        "email",
        "is_active",
        "is_staff",
        "is_superuser",
        "last_login",
    )
    list_filter = ("is_active", "is_staff", "is_superuser")
    fieldsets = (
        (None, {"fields": ("username", "email", "password")}),
        (
            "Permissions",
            {
                "fields": (
                    "is_staff",
                    "is_active",
                    "is_superuser",
                    "groups",
                    "user_permissions",
                )
            },
        ),
        ("Dates", {"fields": ("last_login", "date_joined")}),
    )
    add_fieldsets = (
        (
            None,
            {
                "classes": ("wide",),
                "fields": (
                    "username",
                    "email",
                    "password1",
                    "password2",
                    "is_staff",
                    "is_active",
                ),
            },
        ),
    )
    search_fields = ("email",)
    ordering = ("email",)

add_form and form specify the forms to add and change user instances.
fieldsets specify the fields to be used in editing users and add_fieldsets specify fields to be used when creating a user.

And that’s all you need. You can now go to the admin panel and add/edit users.

User Profile

Let’s now create a user profile. This includes non-auth-related fields for the user. For now, this model contains an avatar and bio. You must already be familiar with modeling a profile for the user. Basically, this is done by using a one-to-one relationship between the User and Profile model. In a one-to-one relationship, one record in a table is associated with one and only one record in another table using a foreign key. For example - a user model instance is associated with one and only one profile instance.

Head over to users/models.py and add the following:

# users/models.py

import os

from django.conf import settings
from django.db import models
from django.template.defaultfilters import slugify

def get_image_filename(instance, filename):
    name = instance.product.name
    slug = slugify(name)
    return f"products/{slug}-{filename}"

class Profile(models.Model):
    user = models.OneToOneField(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    avatar = models.ImageField(upload_to=get_image_filename, blank=True)
    bio = models.CharField(max_length=200, blank=True)

    def __str__(self):
        return self.user.email

    @property
    def filename(self):
        return os.path.basename(self.image.name)

Whenever you are using an ImageField in Django, you need to install Pillow which is one of the most common image-processing libraries in Python. Let’s install it:

pip install pillow==9.3.0

Next, let’s register the profile model in line with the custom user model as follows:

# users/admin.py

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin

from .forms import CustomUserChangeForm, CustomUserCreationForm
from .models import CustomUser, Profile

class ProfileInline(admin.StackedInline):
    model = Profile
    can_delete = False
    verbose_name_plural = "Profile"

@admin.register(CustomUser)
class CustomUserAdmin(UserAdmin):
    add_form = CustomUserCreationForm
    form = CustomUserChangeForm

    model = CustomUser

    list_display = (
        "username",
        "email",
        "is_active",
        "is_staff",
        "is_superuser",
        "last_login",
    )
    list_filter = ("is_active", "is_staff", "is_superuser")
    fieldsets = (
        (None, {"fields": ("username", "email", "password")}),
        (
            "Permissions",
            {
                "fields": (
                    "is_staff",
                    "is_active",
                    "is_superuser",
                    "groups",
                    "user_permissions",
                )
            },
        ),
        ("Dates", {"fields": ("last_login", "date_joined")}),
    )
    add_fieldsets = (
        (
            None,
            {
                "classes": ("wide",),
                "fields": (
                    "username",
                    "email",
                    "password1",
                    "password2",
                    "is_staff",
                    "is_active",
                ),
            },
        ),
    )
    search_fields = ("email",)
    ordering = ("email",)
    inlines = (ProfileInline,)

admin.site.register(Profile)

Since we are working with user-uploaded images, we need to set MEDIA_URL and MEDIA_ROOT in the settings:

# config/settings.py

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'

Next, configure the project's urls.py to serve user-uploaded media files during development.

# config/urls.py

from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
    # ... 
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Before testing this out, let’s create a signal to automatically create a user profile when a user is created. Create a file named signals.py and add the following:

# users/signals.py

from django.contrib.auth import get_user_model
from django.db.models.signals import post_save
from django.dispatch import receiver

from .models import Profile

User = get_user_model()

@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

@receiver(post_save, sender=User)
def save_profile(sender, instance, **kwargs):
    instance.profile.save()

Finally, connect the receivers in the ready() method of the app's configuration by importing the signals module. Head over to users/apps.py and add the following:

# users/apps.py

from django.apps import AppConfig

class UsersConfig(AppConfig):
    default_auto_field = "django.db.models.BigAutoField"
    name = "users"

    def ready(self):
        import users.signals

Test it out:

py manage.py makemigrations
py manage.py migrate
py manage.py runserver

JWT Authentication

The default authentication system that Django provides is session-based. Sessions in Django are implemented using the django.contrib.sessions.middleware.SessionMiddleware middleware. This session-based auth works well with the traditional HTML request-response cycle. However, if you have a client that expects the server to return a JSON response instead of an HTML, you are going to have to use token authentication or JWT authentication and let the client decide what to do with the JSON response. In this tutorial, we will implement JWT authentication using Django Rest Framework.

What is JWT?

JSON Web Token (JWT) is a cryptographically signed URL-safe token for securely transmitting information between parties as a JSON object.

In JWT-based auth, the following happens:

The client sends the username and password to the server.
The server validates user credentials against the database.
The server generates and sends to the client a secure JWT token that is signed using a secret key. This token is of the format:
```
header.payload.signature
```
Decoding tokens in the above format will give information about the user like ID, username, etc.
The client then includes this token in the HTTP header for subsequent requests.
The server verifies the token using the secret key without hitting the database. If the token has been tampered with, the client’s request will be rejected.

This token (also called access token), although customizable, is usually short-lived. Along with the access token, the server also generates and sends to the client a refresh token. A refresh token has a longer life and you can exchange it for an access token.

JWT thus is scalable and fast because of fewer database hits.

Alright, let’s first install Django Rest Framework:

pip install djangorestframework==3.14.0

Add it to installed apps settings:

# config/settings.py

INSTALLED_APPS = [
    # ...
    "rest_framework",
]

To implement JWT auth in our project, we are going to make use of djangorestframework_simplejwt. Install it:

pip install djangorestframework-simplejwt==5.2.2

Then, tell DRF the authentication backend we want to use:

# config/settings.py

REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": (
        "rest_framework_simplejwt.authentication.JWTAuthentication",
    ),
}

Here are a couple of setting variables for simple JWT that can be customized in the settings:

# config/settings.py

from datetime import timedelta

SIMPLE_JWT = {
    "ACCESS_TOKEN_LIFETIME": timedelta(minutes=15),
    "REFRESH_TOKEN_LIFETIME": timedelta(days=14),
    "ROTATE_REFRESH_TOKENS": True,
    "BLACKLIST_AFTER_ROTATION": True,
    "UPDATE_LAST_LOGIN": False,
    "ALGORITHM": "HS256",
    "SIGNING_KEY": SECRET_KEY,
    "VERIFYING_KEY": None,
    "AUDIENCE": None,
    "ISSUER": None,
    "JWK_URL": None,
    "LEEWAY": 0,
    "AUTH_HEADER_TYPES": ("Bearer",),
    "AUTH_HEADER_NAME": "HTTP_AUTHORIZATION",
    "USER_ID_FIELD": "id",
    "USER_ID_CLAIM": "user_id",
    "USER_AUTHENTICATION_RULE": "rest_framework_simplejwt.authentication.default_user_authentication_rule",
    "AUTH_TOKEN_CLASSES": ("rest_framework_simplejwt.tokens.AccessToken",),
    "TOKEN_TYPE_CLAIM": "token_type",
    "JTI_CLAIM": "jti",
    "SLIDING_TOKEN_REFRESH_EXP_CLAIM": "refresh_exp",
    "SLIDING_TOKEN_LIFETIME": timedelta(minutes=5),
    "SLIDING_TOKEN_REFRESH_LIFETIME": timedelta(days=1),
}

If ROTATE_REFRESH_TOKENS is set to True, a new refresh token will be returned along with the access token. And if BLACKLIST_AFTER_ROTATION is set to True, refresh token submitted to the refresh view will be added to the blacklist. You need to add 'rest_framework_simplejwt.token_blacklist' to the list of installed apps for the BLACKLIST_AFTER_ROTATIONsetting to work. so let’s do that:

# config/settings.py

# Third-party apps
INSTALLED_APPS = [
    # ...
    "rest_framework_simplejwt.token_blacklist",
]

Finally, run the following command to apply the app’s migrations:

py manage.py migrate

Now, we need to create access and refresh tokens when the user registers/login. In the next section, we will add serializer and views to accomplish this task.

User Registration and Login Endpoints

Create a file named serializers.py inside the users app and add the following:

# users/serializers.py

from django.contrib.auth import authenticate
from rest_framework import serializers

from .models import CustomUser, Profile

class CustomUserSerializer(serializers.ModelSerializer):
    """
    Serializer class to serialize CustomUser model.
    """

    class Meta:
        model = CustomUser
        fields = ("id", "username", "email")

class UserRegisterationSerializer(serializers.ModelSerializer):
    """
    Serializer class to serialize registration requests and create a new user.
    """

    class Meta:
        model = CustomUser
        fields = ("id", "username", "email", "password")
        extra_kwargs = {"password": {"write_only": True}}

    def create(self, validated_data):
        return CustomUser.objects.create_user(**validated_data)

class UserLoginSerializer(serializers.Serializer):
    """
    Serializer class to authenticate users with email and password.
    """

    email = serializers.CharField()
    password = serializers.CharField(write_only=True)

    def validate(self, data):
        user = authenticate(**data)
        if user and user.is_active:
            return user
        raise serializers.ValidationError("Incorrect Credentials")

class ProfileSerializer(CustomUserSerializer):
    """
    Serializer class to serialize the user Profile model
    """

    class Meta:
        model = Profile
        fields = ("bio",)

class ProfileAvatarSerializer(serializers.ModelSerializer):
    """
    Serializer class to serialize the avatar
    """

    class Meta:
        model = Profile
        fields = ("avatar",)

Note that we have also created a serializer class for the profile.

Then in the views.py

# users/views.py

from django.contrib.auth import get_user_model
from rest_framework import status
from rest_framework.generics import GenericAPIView, RetrieveUpdateAPIView
from rest_framework.permissions import AllowAny, IsAuthenticated
from rest_framework.response import Response
from rest_framework_simplejwt.tokens import RefreshToken

from . import serializers
from .models import Profile

User = get_user_model()

class UserRegisterationAPIView(GenericAPIView):
    """
    An endpoint for the client to create a new User.
    """

    permission_classes = (AllowAny,)
    serializer_class = serializers.UserRegisterationSerializer

    def post(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        user = serializer.save()
        token = RefreshToken.for_user(user)
        data = serializer.data
        data["tokens"] = {"refresh": str(token), "access": str(token.access_token)}
        return Response(data, status=status.HTTP_201_CREATED)

class UserLoginAPIView(GenericAPIView):
    """
    An endpoint to authenticate existing users using their email and password.
    """

    permission_classes = (AllowAny,)
    serializer_class = serializers.UserLoginSerializer

    def post(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        user = serializer.validated_data
        serializer = serializers.CustomUserSerializer(user)
        token = RefreshToken.for_user(user)
        data = serializer.data
        data["tokens"] = {"refresh": str(token), "access": str(token.access_token)}
        return Response(data, status=status.HTTP_200_OK)

class UserLogoutAPIView(GenericAPIView):
    """
    An endpoint to logout users.
    """

    permission_classes = (IsAuthenticated,)

    def post(self, request, *args, **kwargs):
        try:
            refresh_token = request.data["refresh"]
            token = RefreshToken(refresh_token)
            token.blacklist()
            return Response(status=status.HTTP_205_RESET_CONTENT)
        except Exception as e:
            return Response(status=status.HTTP_400_BAD_REQUEST)

class UserAPIView(RetrieveUpdateAPIView):
    """
    Get, Update user information
    """

    permission_classes = (IsAuthenticated,)
    serializer_class = serializers.CustomUserSerializer

    def get_object(self):
        return self.request.user

class UserProfileAPIView(RetrieveUpdateAPIView):
    """
    Get, Update user profile
    """

    queryset = Profile.objects.all()
    serializer_class = serializers.ProfileSerializer
    permission_classes = (IsAuthenticated,)

    def get_object(self):
        return self.request.user.profile

class UserAvatarAPIView(RetrieveUpdateAPIView):
    """
    Get, Update user avatar
    """

    queryset = Profile.objects.all()
    serializer_class = serializers.ProfileAvatarSerializer
    permission_classes = (IsAuthenticated,)

    def get_object(self):
        return self.request.user.profile

The above views are self-explanatory. Basically, the views for user authentication use the RefreshToken class of simple JWT to generate and send to the client refresh and access tokens. In addition, the logout view blacklists the refresh token. The other views are used to get or update a user and his/her profile.

Now, let’s hook our views in the URLs.

Head over to config/urls.py and add the users app URLs:

# config/urls.py

from django.urls import include, path

urlpatterns = [
    # ...
    path("", include("users.urls", namespace="users")),
]

Inside the users app, create a file named urls.py and add the endpoints as follows:

# users/urls.py

from django.urls import path
from rest_framework_simplejwt.views import TokenRefreshView

from users import views

app_name = "users"

urlpatterns = [
    path("register/", views.UserRegisterationAPIView.as_view(), name="create-user"),
    path("login/", views.UserLoginAPIView.as_view(), name="login-user"),
    path("token/refresh/", TokenRefreshView.as_view(), name="token-refresh"),
    path("logout/", views.UserLogoutAPIView.as_view(), name="logout-user"),
    path("", views.UserAPIView.as_view(), name="user-info"),
    path("profile/", views.UserProfileAPIView.as_view(), name="user-profile"),
    path("profile/avatar/", views.UserAvatarAPIView.as_view(), name="user-avatar"),
]

Note that the token/refresh endpoint will be used to get a new access and refresh token.

The Blog API

First, create an app named posts

py manage.py startapp posts

and add it to the list of installed apps in the settings:

# config/settings.py

INSTALLED_APPS = [
    # ...
    "posts",
]

Let’s wire up the models. We are going to have 3 models. The Post, Category, and Comment

A post can have many categories and comments, thus we are going to use a ManyToMany field:

# posts/models.py

from django.conf import settings
from django.db import models
from django.utils.translation import gettext_lazy as _

class Category(models.Model):
    name = models.CharField(_("Category name"), max_length=100)

    class Meta:
        verbose_name = _("Category")
        verbose_name_plural = _("Categories")

    def __str__(self):
        return self.name

class Post(models.Model):
    title = models.CharField(_("Post title"), max_length=250)
    author = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        related_name="posts",
        null=True,
        on_delete=models.SET_NULL,
    )
    categories = models.ManyToManyField(Category, related_name="posts_list", blank=True)
    body = models.TextField(_("Post body"))
    likes = models.ManyToManyField(
        settings.AUTH_USER_MODEL, related_name="post_likes", blank=True
    )
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        ordering = ("-created_at",)

    def __str__(self):
        return f"{self.title} by {self.author.username}"

class Comment(models.Model):
    post = models.ForeignKey(Post, related_name="comments", on_delete=models.CASCADE)
    author = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        related_name="post_comments",
        null=True,
        on_delete=models.SET_NULL,
    )
    body = models.TextField(_("Comment body"))
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        ordering = ("-created_at",)

    def __str__(self):
        return f"{self.body[:20]} by {self.author.username}"

Now, register these models in the admin:

# posts/admin.py

from django.contrib import admin

from .models import Category, Comment, Post

admin.site.register(Category)
admin.site.register(Post)
admin.site.register(Comment)

Create and run migrations:

py manage.py makemigrations
py manage.py migrate

Great! let’s now set up the serializer classes and views.

Create serializers.py inside the posts app and add the following:

# posts/serializers.py

from rest_framework import serializers

from .models import Category, Comment, Post

class CategoryReadSerializer(serializers.ModelSerializer):
    class Meta:
        model = Category
        fields = "__all__"

class PostReadSerializer(serializers.ModelSerializer):
    author = serializers.CharField(source="author.username", read_only=True)
    categories = serializers.SerializerMethodField(read_only=True)
    likes = serializers.SerializerMethodField(read_only=True)

    class Meta:
        model = Post
        fields = "__all__"

    def get_categories(self, obj):
        categories = list(
            cat.name for cat in obj.categories.get_queryset().only("name")
        )
        return categories

    def get_likes(self, obj):
        likes = list(
            like.username for like in obj.likes.get_queryset().only("username")
        )
        return likes

class PostWriteSerializer(serializers.ModelSerializer):
    author = serializers.HiddenField(default=serializers.CurrentUserDefault())

    class Meta:
        model = Post
        fields = "__all__"

class CommentReadSerializer(serializers.ModelSerializer):
    author = serializers.CharField(source="author.username", read_only=True)

    class Meta:
        model = Comment
        fields = "__all__"

class CommentWriteSerializer(serializers.ModelSerializer):
    author = serializers.HiddenField(default=serializers.CurrentUserDefault())

    class Meta:
        model = Comment
        fields = "__all__"

Separating serializers for read and write is something that can be really helpful because you may sometimes want to include more details in the response for read (list and retrieve) but limit the number of fields when adding an entry to the database. This makes your serializer classes less complicated.
Also, note the use of serializers.CurrentUserDefault. This is really hand-in to automatically set the authenticated user as the author or owner of something.

Next, to write our views, we are going to use ViewSets. If you are new to ViewSets, here is a quick overview.

ViewSet is a type of class-based view that combines the logic for a set of related views into a single class. The 2 most common types of ViewSets that you are most likely to use are Modelviewset and ReadOnlyModelViewSet. One of the main advantages of ViewSets is to have URL endpoints automatically defined for you through Routers

ViewSets have the highest level of abstraction and you can use them to avoid writing all the code for basic and repetitive stuff. They are a huge time-saver!

That being said, add the following code in the views and read the comments for further explanation.

# posts/views.py

from django.shortcuts import get_object_or_404
from rest_framework import permissions, status, viewsets
from rest_framework.response import Response
from rest_framework.views import APIView

from posts.models import Category, Comment, Post
from posts.serializers import (
    CategoryReadSerializer,
    CommentReadSerializer,
    CommentWriteSerializer,
    PostReadSerializer,
    PostWriteSerializer,
)

from .permissions import IsAuthorOrReadOnly

# Category is going to be read-only, so we use ReadOnlyModelViewSet
class CategoryViewSet(viewsets.ReadOnlyModelViewSet):
    """
    List and Retrieve post categories
    """

    queryset = Category.objects.all()
    serializer_class = CategoryReadSerializer
    permission_classes = (permissions.AllowAny,)

class PostViewSet(viewsets.ModelViewSet):
    """
    CRUD posts
    """

    queryset = Post.objects.all()

    # In order to use different serializers for different 
    # actions, you can override the 
    # get_serializer_class(self) method
    def get_serializer_class(self):
        if self.action in ("create", "update", "partial_update", "destroy"):
            return PostWriteSerializer

        return PostReadSerializer

    # get_permissions(self) method helps you separate 
    # permissions for different actions inside the same view.
    def get_permissions(self):
        if self.action in ("create",):
            self.permission_classes = (permissions.IsAuthenticated,)
        elif self.action in ("update", "partial_update", "destroy"):
            self.permission_classes = (IsAuthorOrReadOnly,)
        else:
            self.permission_classes = (permissions.AllowAny,)

        return super().get_permissions()

class CommentViewSet(viewsets.ModelViewSet):
    """
    CRUD comments for a particular post
    """

    queryset = Comment.objects.all()

    def get_queryset(self):
        res = super().get_queryset()
        post_id = self.kwargs.get("post_id")
        return res.filter(post__id=post_id)

    def get_serializer_class(self):
        if self.action in ("create", "update", "partial_update", "destroy"):
            return CommentWriteSerializer

        return CommentReadSerializer

    def get_permissions(self):
        if self.action in ("create",):
            self.permission_classes = (permissions.IsAuthenticated,)
        elif self.action in ("update", "partial_update", "destroy"):
            self.permission_classes = (IsAuthorOrReadOnly,)
        else:
            self.permission_classes = (permissions.AllowAny,)

        return super().get_permissions()

# Here, we are using the normal APIView class
class LikePostAPIView(APIView):
    """
    Like, Dislike a post
    """

    permission_classes = (permissions.IsAuthenticated,)

    def get(self, request, pk):
        user = request.user
        post = get_object_or_404(Post, pk=pk)

        if user in post.likes.all():
            post.likes.remove(user)

        else:
            post.likes.add(user)

        return Response(status=status.HTTP_200_OK)

We haven’t created custom permission to limit edit and delete actions to the owner of a post, so let’s go ahead and do that. Create a file named permissions.py inside the posts app and add the following:

# posts/permissions.py

from rest_framework import permissions

class IsAuthorOrReadOnly(permissions.BasePermission):
    """
    Check if authenticated user is author of the post.
    """

    def has_permission(self, request, view):
        return request.user.is_authenticated is True

    def has_object_permission(self, request, view, obj):
        if request.method in permissions.SAFE_METHODS:
            return True

        return obj.author == request.user

Finally, let’s configure the URLs:

# config/urls.py

from django.urls import include, path

urlpatterns = [
    # ...
    path("post/", include("posts.urls", namespace="posts")),
]

# posts/urls.py

from django.urls import include, path
from rest_framework.routers import DefaultRouter

from .views import CategoryViewSet, CommentViewSet, LikePostAPIView, PostViewSet

app_name = "posts"

router = DefaultRouter()
router.register(r"categories", CategoryViewSet)
router.register(r"^(?P<post_id>\d+)/comment", CommentViewSet)
router.register(r"", PostViewSet)

urlpatterns = [
    path("", include(router.urls)),
    path("like/<int:pk>/", LikePostAPIView.as_view(), name="like-post"),
]

Great! that’s all. You can use Postman or the built-in browsable API to test the endpoints. Note that, if you use the browsable API, you need to add session authentication to the DEFAULT_AUTHENTICATION_CLASSES because the browsable API uses session authentication for the login form. To do so, head over to the settings and update the DEFAULT_AUTHENTICATION_CLASSES setting:

# config/settings.py

REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": (
        "rest_framework_simplejwt.authentication.JWTAuthentication",
        "rest_framework.authentication.SessionAuthentication",
    ),
}

Then, in the project’s urls.py file add the API URL:

# config/urls.py

from django.urls import include, path

urlpatterns = [
    path("api-auth/", include("rest_framework.urls")),
]

P.S. don’t forget to configure CORS to allow in-browser requests from other origins like your React app for example.

Happy coding! 🖤

Build a ChatBot Using Python, Django

Hana Belay — Thu, 17 Nov 2022 09:00:00 +0000

A ChatBot has become one of the must-have features of modern-day web applications. It plays a huge role in customer service which was once traditionally held by human beings. Through ChatBot, you can automatically generate a response to a user’s input by making use of different machine-learning techniques.

Note:- If you encounter any issues throughout the tutorial, you can check out the code in the GitHub repository.

Prerequisite
Project Configuration
WebSockets Using Django Channels
Tailwind CSS Configuration
Frontend - Create a WebSocket Connection
Enable a Channel Layer
Backend - WebSocket Consumers
ChatterBot - Generate Automated Response
ChatterBot Training
Offload Automated Response Generation to Celery
Conclusion

Prerequisite

This guide assumes that you have intermediate-level Django knowledge.

Project Configuration

To implement the ChatBot, the following technologies will be used:

ChatterBot Library - To generate automated responses to a user’s input.
Celery - Getting the automated response from a machine-learning dialog engine is going to take a while. So Celery will be used to perform this task in the background.
WebSockets using Django Channels - To send to the client the automated response generated by the machine learning model immediately when it’s available.
Redis - Will be used as a message broker and result backend for Celery. In addition, it will be used as a channel layer for WebSocket communication.
TailwindCSS - To create the user interface.

We will dive into the details of each of them, but first, let’s set up the project. I have created a starter Docker template with all the configurations so that we can move forward with the development without wasting time.

Create a folder on your local machine > cd into it > clone the template:

mkdir chatbot
cd chatbot
git clone https://github.com/earthcomfy/blog-template .

This will generate the following folders and files inside your project:

There isn’t much going on except a basic Django setup in Docker with web, db, redis, and celery services. Refer to this article for more information on how to set up a Django project inside Docker. If you don’t want to use Docker, you can also follow along by setting up a virtual environment and running the necessary services on your machine.

In the root directory of your project, there is a file named .env.template, rename it to .env and update the environment variables accordingly.

Great, now build the image and spin up the containers by running:

docker-compose up --build

Go to http://0.0.0.0:8000/ to check if everything worked correctly.

Great, everything is working. Now close Docker by pressing ctrl + c and create a Django app named chat

docker-compose run --rm web python manage.py startapp chat

Add it to the list of installed apps inside settings/base.py

# settings/base.py

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    # Local apps
    "chat"
]

Hurray! Let’s move on to the next section where the fun begins.

WebSockets Using Django Channels

It goes without saying that in a typical Django project the client makes an HTTP request > Django calls the view that is responsible for managing this request and returns a response back to the client.

This communication is pretty standard. However, ever since Django introduced ASGI and started supporting it natively, writing Django applications with asynchronous code has become possible. ASGI not only allows you to run asynchronous apps, but it also makes it possible to work with more advanced protocols like WebSockets.

Django Channels, which is built on ASGI, goes beyond HTTP and support other protocols such as WebSockets. The underlying implementation of Django Channels is very similar to regular HTTP views.

That being said, the following packages are needed to set up channels in a project:

channels
daphne

Both of them were added to the requirements.txt file so they must have already been installed when you built your Docker image.

Daphne is an HTTP, HTTP2, and WebSocket protocol server for ASGI, and was developed to power Django Channels. This server needs to be added to the list of installed apps so that it can take over the runserver management command.

# settings/base.py

INSTALLED_APPS = [
    "daphne", # here
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    # Local apps
    "chat"
]

Note:- Please be wary of any other third-party apps that require an overloaded or replacement runserver command. Daphne provides a separate runserver command and may conflict with it. In order to solve such issues, make sure daphne is at the top of your INSTALLED_APPS

Next, go to your project's asgi.py file and adjust it as follows to wrap the Django ASGI application:

# asgi.py

import os

from channels.auth import AuthMiddlewareStack
from channels.routing import ProtocolTypeRouter, URLRouter
from channels.security.websocket import AllowedHostsOriginValidator
from decouple import config
from django.core.asgi import get_asgi_application

os.environ.setdefault("DJANGO_SETTINGS_MODULE", config("DJANGO_SETTINGS_MODULE"))

# Initialize Django ASGI application early to ensure the AppRegistry
# is populated before importing code that may import ORM models.
django_asgi_app = get_asgi_application()

application = ProtocolTypeRouter(
    {
        "http": django_asgi_app,
        # We will add WebSocket protocol later. For now, it's just HTTP.
    }
)

Finally, set your ASGI_APPLICATION setting to point to that routing object as your root application:

# settings/base.py

ASGI_APPLICATION = "config.asgi.application"

Perfect! From this point onward, the daphne development server will be run. To ensure this, fire up the containers by running:

docker-compose up

Notice the ASGI/Daphne version 4.0.0 development server

Alright, this application is going to require a single view where the user and the ChatBot can interact. For this, let’s first set up Tailwind CSS in the project.

Tailwind CSS Configuration

There are many ways to set up Tailwind CSS in Django. One way to do so is by using a package called django-tailwind. This package provides an easy way to use Tailwind CSS in a Django project.

This package was included in requirements.txt so it must have already been installed when you created the Docker image.

After installation, add tailwind to the list of installed apps in the settings:

# settings/base.py

INSTALLED_APPS = [
    "daphne",
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    # Third-party apps
    "tailwind",
    # Local apps
    "chat",
]

Now, Create a TailwindCSS-compatible Django app. When prompted for the app name you can give it any name or proceed with the default theme

docker-compose run --rm web python manage.py tailwind init

Add the app - theme to the list of installed apps in the settings:

# settings/base.py

INSTALLED_APPS = [
    # ...
    # Local apps
    "chat",
    "theme",
]

# settings/base.py

# Tailwind
TAILWIND_APP_NAME = "theme"

Install Tailwind CSS dependencies by running the following command:

docker-compose run --rm web python manage.py tailwind install

Perfect! Now, head over to theme/templates/base.html This file will be used as a base template to include Tailwind’s style sheet in all the other templates. Let’s modify it as follows:

{% comment %} theme/templates/base.html {% endcomment %}

{% load static tailwind_tags %}
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>{% block title %}Django Chatbot{% endblock %}</title>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    {% tailwind_css %}
  </head>

  <body>
    {% block body %} {% endblock %}
  </body>
  {% block scripts%}{% endblock %}
</html>

Then, head over to the chat app created earlier and create a templates directory. Within the templates directory, create another directory named chat, and within that create a file named chat.html

Put the following snippet inside the file:

{% comment %} chat/templates/chat/chat.html {% endcomment %}

{% extends 'base.html' %} {% block body %}
<div class="p-6 w-[800px]">
  <h1 class="text-3xl tracking-tight font-light" id="chat-header"></h1>
  <div
    id="chat-log"
    class="mt-4 w-full relative p-6 overflow-y-auto h-[30rem] bg-gray-50 border border-gray-200"
  ></div>
  <div class="mt-4">
    <input
      id="chat-message-input"
      class="py-2 outline-none bg-gray-50 border border-gray-300 text-gray-900 text-sm focus:border-blue-500"
      type="text"
      placeholder="Write your message here."
    />
    <button
      id="chat-message-submit"
      class="py-2 px-4 ml-2 border border-transparent text-sm font-medium rounded-md text-white bg-blue-800 hover:bg-blue-900"
      type="submit"
    >
      Send
    </button>
  </div>
</div>
{% endblock %}

The above is a basic Django HTML file with a div where chat history will be displayed and an input box for the user’s input with the submit button.

Next, create a view that will render the above template:

# chat/views.py

from django.views.generic import TemplateView

class ChatView(TemplateView):
    template_name: str = "chat/chat.html"

Then, Create urls.py module inside the chat app and map the ChatView to the URL patterns.

# chat/urls.py

from django.urls import path
from .views import ChatView

app_name = "chat"

urlpatterns = [path("", ChatView.as_view(), name="chat_view")]

Finally, go to the project's urls.py file and include the chat app's URL:

# config/urls.py

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path("admin/", admin.site.urls),
    path("", include("chat.urls", namespace="chat")),
]

Done! Now, make sure the styles are applied properly and that what we have so far is working.

Start tailwind:

docker-compose run web python manage.py tailwind start

In another terminal spin up the containers:

docker-compose run web python manage.py tailwind start

Go to http://localhost:8000/ and you will see the following 🎉

Note:- If the styles aren’t applied, make sure you have started tailwind and restart the containers.

Frontend - Create a WebSocket Connection

Inside chat.html, you need to write a script that will open a WebSocket connection to a Django Server and listen to the established connection to send and receive data.

Open the chat.html file and add the following script just under the body block i.e. {% endblock %}

{% block scripts %}
<script>
  var wss_protocol = window.location.protocol == "https:" ? "wss://" : "ws://";
  var chatSocket = new WebSocket(
    wss_protocol + window.location.host + "/ws/chat/"
  );
  var messages = [];

  chatSocket.onopen = function (e) {
    document.querySelector("#chat-header").innerHTML =
      "Welcome to Django Chatbot";
  };

  chatSocket.onmessage = function (e) {
    var data = JSON.parse(e.data);
    var message = data["text"];
    messages.push(message);

    var str = '<ul class="space-y-2">';
    messages.forEach(function (msg) {
      str += `<li class="flex ${
        msg.source == "bot" ? "justify-start" : "justify-end"
      }">
      <div class="relative max-w-xl px-4 py-2 rounded-lg shadow-md
        ${
          msg.source == "bot"
            ? "text-gray-700 bg-white border border-gray-200"
            : "bg-blue-600 text-white"
        }">
        <span className="block font-normal">${msg.msg}</span></div></li>`;
    });
    str += "</ul>";
    document.querySelector("#chat-log").innerHTML = str;
  };

  chatSocket.onclose = function (e) {
    alert("Socket closed unexpectedly, please reload the page.");
  };

  document.querySelector("#chat-message-input").focus();
  document.querySelector("#chat-message-input").onkeyup = function (e) {
    if (e.keyCode === 13) {
      // enter, return
      document.querySelector("#chat-message-submit").click();
    }
  };

  document.querySelector("#chat-message-submit").onclick = function (e) {
    var messageInputDom = document.querySelector("#chat-message-input");
    var message = messageInputDom.value;
    chatSocket.send(
      JSON.stringify({
        text: message,
      })
    );

    messageInputDom.value = "";
  };
</script>
{% endblock %}

The above script creates a WebSocket connection to the /ws/chat/ path > listens to different events and manipulates the DOM.
Depending on the source of the message (user or bot), different alignments and styles are applied (see under the chatsocket.onmessage)

If you run the server at this point, type in any message, and hit submit, the WebSocket connection will be opened but you will see an error in the JavaScript console because we don’t have a consumer that accepts WebSocket connections yet.

Enable a Channel Layer

A Channel layer provides an abstraction for multiple consumers to talk with each other and with other parts of Django. It is the middleman that passes messages from senders to receivers. The Channel layer that will be used in this guide is Redis. Aside from serving as a WebSocket communication, Redis can also be used as a:

Message Broker and Result backend for Celery.
Caching.

It is an all-in-one tool!

We have already configured a Redis service inside Docker. Django Channels also needs to know how to interface with Redis. This is provided by a package called channels_redis

channels_redis is an officially maintained channel layer that uses Redis as its backing store. It is already included in requirements.txt so it must have already been installed when you built your Docker image.

Next, add the Channel layer settings:

# settings/base.py

# Django Channels
CHANNEL_LAYERS = {
    "default": {
        "BACKEND": "channels_redis.core.RedisChannelLayer",
        "CONFIG": {
            "hosts": [config("REDIS_BACKEND")],
        },
    },
}

A channel layer has the following:

1) Channel - a mailbox where messages can be sent to. Each channel has a name. Anyone who has the name of a channel can send a message to the channel.

2) Group - a group of related channels. A group has a name. Anyone who has the name of a group can add/remove a channel to the group by name and send a message to all channels in the group.

Backend - WebSocket Consumers

When a WebSocket API opens a connection, Channels need to be informed where to look to accept and handle the connection. This is where Consumers come in. Consumers correspond to Views in normal Django HTTP requests.

When a message is sent from the client, it is received by the consumers listening to the group or channel on the other end.

Create a file named consumers.py inside the chat app and add the following:

# chat/consumers.py

import json

from asgiref.sync import async_to_sync
from channels.generic.websocket import WebsocketConsumer

class ChatConsumer(WebsocketConsumer):
    def receive(self, text_data):
        text_data_json = json.loads(text_data)

        # The consumer ChatConsumer is synchronous while the channel layer
        # methods are asynchronous. Therefore wrap the methods in async-to-sync
        async_to_sync(self.channel_layer.send)(
            self.channel_name,
            {
                "type": "chat_message",
                "text": {"msg": text_data_json["text"], "source": "user"},
            },
        )

        # We will later replace this call with a celery task that will
        # use a Python library called ChatterBot to generate an automated
        # response to a user's input.
        async_to_sync(self.channel_layer.send)(
            self.channel_name,
            {
                "type": "chat.message",
                "text": {"msg": "Bot says hello", "source": "bot"},
            },
        )

    # Handles the chat.mesage event i.e. receives messages from the channel layer
    # and sends it back to the client.
    def chat_message(self, event):
        text = event["text"]
        self.send(text_data=json.dumps({"text": text}))

The above consumer accepts a WebSocket connection on the path /ws/chat/, takes a message, and sends a response to the client (for now the response is just a simple message “Bot says hello”).
Any consumer has a self.channel_layer and self.channel_name attribute, which contains a pointer to the channel layer instance (Redis in our case) and the channel name respectively.

Similar to urls.py Channels uses a routing configuration to route to the consumer. Inside the chat app, create a file named routing.py and add the following:

# chat/routing.py

from django.urls import re_path

from . import consumers

websocket_urlpatterns = [
    re_path(r"ws/chat/$", consumers.ChatConsumer.as_asgi()),
]

Next, head over to asgi.py and modify it as follows:

# config/asgi.py

"""
ASGI config for config project.

It exposes the ASGI callable as a module-level variable named ``application``.

For more information on this file, see
https://docs.djangoproject.com/en/4.1/howto/deployment/asgi/
"""

import os

from channels.auth import AuthMiddlewareStack
from channels.routing import ProtocolTypeRouter, URLRouter
from channels.security.websocket import AllowedHostsOriginValidator
from django.core.asgi import get_asgi_application
from decouple import config

os.environ.setdefault("DJANGO_SETTINGS_MODULE", config("DJANGO_SETTINGS_MODULE"))

# Initialize Django ASGI application early to ensure the AppRegistry
# is populated before importing code that may import ORM models.
django_asgi_app = get_asgi_application()

import chat.routing

application = ProtocolTypeRouter(
    {
        "http": django_asgi_app,
        "websocket": AllowedHostsOriginValidator(
            AuthMiddlewareStack(URLRouter(chat.routing.websocket_urlpatterns))
        ),
    }
)

The above code points the root routing configuration to the chat.routing module. This means when a connection is made to the development server (channel's development server), ProtocolTypeRouter checks whether it's a normal HTTP request or a WebSocket.
If it's a WebSocket, AuthMiddlewareStack will take it from there and will populate the connection’s scope with a reference to the currently authenticated user, similar to how Django’s AuthenticationMiddleware populates the request object of a view function with the currently authenticated user.
Next, URLRouter will route the connection to a particular consumer based on the provided URL patterns.

Now, if you head over to http://localhost:8000/ and type in any message, you will get a response that says “Bot says hello”

Great! Now, the response to a user’s input needs to be automated. Let’s do that in the next section using ChatterBot.

ChatterBot - Generate Automated Response

ChatterBot is a Python library that makes it easy to generate automated responses to a user’s input. To use this in your project, add it to the list of installed apps in the settings:

# settings/base.py

INSTALLED_APPS = [
    # ...
    # Third-party apps
    "tailwind",
    "chatterbot.ext.django_chatterbot",
    # Local apps
    "chat",
    "theme",
]

Under the hood, ChatterBot uses logic adapters to determine how to respond to a given input statement. You can have multiple logic adapters for your bot. Most of the logic adapters use the Naive Bayesian classification algorithm to determine if an input statement meets a particular set of criteria and to generate a response accordingly. The Naive Bayesian classification algorithm is based on conditional probability. Learn more about it here.

For a list of logic adapters, you can check this out. For the purpose of this tutorial, let’s use a single adapter called Best Match Adapter. As the name implies, the BestMatch logic adapter selects a response based on the best-known match to a given statement. Let’s add it to the settings:

# settings/base.py

# Chatterbot
CHATTERBOT = {
    "name": "User Support Bot",
    "logic_adapters": [
        "chatterbot.logic.BestMatch",
    ],
}

If you use multiple adapters, the response with the highest calculated confidence score will be considered a valid response to the input. The confidence score returned by each logic adapter determines how valid or close the response is to the output.

The following diagram from ChatterBot documentation provides a very nice flow of what goes behind the scenes.

ChatterBot Training

In the beginning, a ChatterBot instance is like a blank slate. This means that it starts off with an empty database. You fill it with statements (a single string of text representing something that can be said) and gradually it learns to reply to your input with higher accuracy. This training process is going to take some time. In order to simplify this process, ChatterBot provides multiple ways to initially train your bot. In this tutorial, you will learn how to train your bot using sample list data.

Let’s create a simple custom management command where we will pass in a list of statements. Head over to the chat app and create a management directory. Within the management directory, create another directory named commands, and within that create 2 files __init__.py and train.py

Put the following script inside train.py

# chat/management/commands/train.py

from django.core.management.base import BaseCommand
from chatterbot import ChatBot
from chatterbot.ext.django_chatterbot import settings
from chatterbot.trainers import ListTrainer

class Command(BaseCommand):
    help = "Training the chatbot"

    def handle(self, *args, **options):
        chatterbot = ChatBot(**settings.CHATTERBOT)
        trainer = ListTrainer(chatterbot)
        trainer.train(
            [
                "Hello",
                "Hi there!",
                "How are you doing?",
                "I'm doing great.",
                "That is good to hear",
                "Thank you.",
                "You're welcome.",
            ]
        )
        self.stdout.write(self.style.SUCCESS("Successfull!"))

Next, run the following command to load the example dialog into your project’s database.

docker-compose run --rm web python manage.py train

Now, create a superuser:

docker-compose exec web python manage.py createsuperuser

and go to the admin panel http://localhost:8000/admin/ Go to the statements tab and voila, you will see a list of texts with their responses.

Offload Automated Response Generation to Celery

Needless to say, generating a response from ChatterBot is time-intensive. This is where Celery comes to the rescue. Celery will pick up queued tasks and manages a separate server to run them in the background. As mentioned before, we will use Redis as a message broker. It is already set up in Docker so let’s proceed to defining the task.

Create a file named tasks.py inside the chat app and put the following Celery task:

# chat/tasks.py

from asgiref.sync import async_to_sync
from celery import shared_task
from channels.layers import get_channel_layer
from chatterbot import ChatBot
from chatterbot.ext.django_chatterbot import settings

channel_layer = get_channel_layer()

@shared_task
def get_response(channel_name, input_data):
    chatterbot = ChatBot(**settings.CHATTERBOT)
    response = chatterbot.get_response(input_data)
    response_data = response.serialize()

    async_to_sync(channel_layer.send)(
        channel_name,
        {
            "type": "chat.message",
            "text": {"msg": response_data["text"], "source": "bot"},
        },
    )

Finally, update consumers.py with the following content:

# chat/consumers.py

import json

from asgiref.sync import async_to_sync
from channels.generic.websocket import WebsocketConsumer

from .tasks import get_response

class ChatConsumer(WebsocketConsumer):
    def receive(self, text_data):
        text_data_json = json.loads(text_data)
        get_response.delay(self.channel_name, text_data_json)

        async_to_sync(self.channel_layer.send)(
            self.channel_name,
            {
                "type": "chat_message",
                "text": {"msg": text_data_json["text"], "source": "user"},
            },
        )

    def chat_message(self, event):
        text = event["text"]
        self.send(text_data=json.dumps({"text": text}))

You have to restart the container so that Celery can pick up the task and add it to its queue. Press ctrl + c and run:

docker-compose up

Go to http://localhost:8000/ and type in hello and you will get the response back 🚀

Conclusion

This tutorial is intended to be a starting place. The ChatterBot documentation is very concise so make sure to check it out to implement more features. For instance, you can train your data with corpus data. You can use multiple logic adapters or even create your own. In addition, check out Django Channel’s documentation to understand more about consumers, channel layers, and so on.

If you got lost somewhere throughout the guide, check out the project on GitHub

Happy coding! 🖤

Start a Production-Ready Dockerized Django Project

Hana Belay — Tue, 01 Nov 2022 13:00:00 +0000

Making a Django app production-ready inside Docker is quite useful for developers. It minimizes the hassle of setup and deployment. This allows developers to focus on what’s important i.e. development and business logic.

Prerequisite
Introduction
Project Configuration
Split Settings for Different Environments
Environment Variables
Postgres Configuration
1. Ensure Postgres is healthy before Django is started
Celery and Redis Configuration
Tweak Docker Compose for Production
Conclusion

Prerequisite

This guide assumes that you are familiar with the following technologies:

Intermediate Django
Beginner to Intermediate Docker
Familiarity with Postgres, Celery, Redis, Nginx

Introduction

This guide is aimed at helping you start and organize your Django project to work in different environments mainly, development and production. You can then take this template, modify it to fit your specific requirements, and finally deploy it on your choice of a cloud service provider like AWS, Azure, or Digital Ocean to name a few.

Note:- If you encounter any issues throughout the tutorial, you can check out the code in the GitHub repository

Project Configuration

First, create a repo on GitHub. Initialize the repository with a README file and .gitignore template for Python.

Now, on your machine, open up a terminal and run the following commands to set up and open your project.

mkdir django-docker-template
cd django-docker-template
git clone <link-to-repo> .
code .

In the root directory of your project, create a file named requirements.txt

touch requirements.txt

and add the following dependencies:

celery==5.2.7
Django==4.1.2
gunicorn==20.1.0
psycopg2-binary==2.9.5
python-decouple==3.6
redis==4.3.4

Then, create the Dockerfile

touch Dockerfile

and add the following snippet:

FROM python:3.10.2-slim-bullseye

ENV PIP_DISABLE_PIP_VERSION_CHECK 1
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

WORKDIR /code

COPY ./requirements.txt .
RUN pip install -r requirements.txt

COPY . .

Then, create a docker-compose.yml file:

touch docker-compose.yml

and add a web service inside it:

version: "3.9"

services:
  web:
    build: .
    volumes:
      - .:/code
    ports:
      - 8000:8000

Finally, create a .dockerignore file so that Docker will ignore some files thus speeding up the build process of your image.

touch .dockerignore

Add the following inside it:

.venv
.git
.gitignore

Great, build your image by running the following command:

docker-compose build

This will take some time. You can now use this image to create the Django project.

docker-compose run --rm web django-admin startproject config .

Split Settings for Different Environments

It is important to take into account the different environments/modes your project will be running on: usually, these are development and production. However, you can apply a similar logic for other environments you may need to include.

You can split your settings to dictate which environment your project is running on, similar to what is presented below:

config
│
└───settings
│   │   __init__.py
│   │   base.py
│   │   development.py
│   │   production.py

base.py will contain the common settings used regardless of the environment. Hence, copy all the content of settings.py which Django created by default into settings/base.py and delete settings.py as it is no longer needed.

Then, import base.py in both environments. Environment-specific settings will be updated later.

# import this in development.py, production.py
from .base import *

Environment Variables

Using environment variables allows you to describe different environments. python decouple is one of the most commonly used packages to strictly separate settings from your source code. This package is added earlier in requirements.txt so just create a .env file in the root directory of your project:

touch .env

And add the following variables:

SECRET_KEY=

ALLOWED_HOSTS=.localhost, .herokuapp.com, .0.0.0.0
DEBUG=True

DJANGO_SETTINGS_MODULE=config.settings.development

Update your settings accordingly:

# base.py

from decouple import config, Csv

SECRET_KEY = config("SECRET_KEY")

DEBUG = config("DEBUG", default=False, cast=bool)

ALLOWED_HOSTS = config("ALLOWED_HOSTS", cast=Csv())

DJANGO_SETTINGS_MODULE tells Django which setting to use. By providing its value in an environment variable, manage.py will be able to automatically use the appropriate setting for different environments. Therefore update manage.py as follows:

# manage.py

from decouple import config

os.environ.setdefault("DJANGO_SETTINGS_MODULE", config("DJANGO_SETTINGS_MODULE"))

Also update the web service in docker-compose.yml file to pull in environment variables from the .env file:

version: "3.9"

services:
  web:
    build: .
    volumes:
      - .:/code
    env_file:
      - ./.env
    ports:
      - 8000:8000

Now, what are some of the potential environment-specific settings? Here are some of them:

1) Email

You can use the console backend in development mode to write emails to the standard output.

# development.py

from .base import *

EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend"

While in production mode, use an SMTP backend like SendGrid, Mailgun, etc…

# production.py

from .base import *

EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "'smtp.mailgun.org'"
EMAIL_PORT = 587
EMAIL_HOST_USER = config("EMAIL_USER")
EMAIL_HOST_PASSWORD = config("EMAIL_PASSWORD")
EMAIL_USE_TLS = True

2) Media and Static files

In production mode, you may want to use services like AWS S3 to serve your static and media files. Having multiple settings comes in handy in such scenarios.

# development.py

MEDIA_URL = "/media/"
MEDIA_ROOT = os.path.join(BASE_DIR, "../", "mediafiles")

STATIC_URL = "static/"
STATIC_ROOT = os.path.join(BASE_DIR, "../", "staticfiles")

And then you can add AWS-related configs in production.py

3) Caching

Ideally, you don’t need to cache your site in development so you can separately add a cache server like Redis in production.py file

# production.py

# Redis Cache
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": config("REDIS_BACKEND"),
    },
}

In addition, you can add apps, middleware, etc. separately for your environments.

Postgres Configuration

To configure Postgres, you first need to add a new service to the docker-compose.yml file:

version: "3.9"

services:
  web:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    env_file:
      - ./.env
    ports:
      - 8000:8000
    depends_on:
      - db
  db:
    image: postgres:13
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    environment:
      - POSTGRES_USER=${DB_USERNAME}
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=${DB_NAME}

volumes:
  postgres_data:

Next, update the .env file to include database-related variables:

# Database
DB_NAME=
DB_USERNAME=
DB_PASSWORD=
DB_HOSTNAME=db
DB_PORT=5432

Finally, update the settings to use Postgres RDBMS instead of the SQLite engine Django uses by default.

# base.py

# Remove the sqlite engine and add this
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": config("DB_NAME"),
        "USER": config("DB_USERNAME"),
        "PASSWORD": config("DB_PASSWORD"),
        "HOST": config("DB_HOSTNAME"),
        "PORT": config("DB_PORT", cast=int),
    }
}

Note:- You may want to use different databases for development and production. If that’s the case, you can remove the DATABASES setting from base.py and add different databases for development and production.

Great! Now, re-build the container to ensure what you have so far is working.

docker-compose build

Also, ensure that the migrations are applied:

docker-compose run --rm web python manage.py migrate

Ensure Postgres is healthy before Django is started

Usually, when working with Postgres and Django in Docker, the web service (Django) tries to connect to the db service even when db service is not ready to accept connections. To solve this issue, you can create a short bash script that will be used in the Docker ENTRYPOINT command.

In the root directory of your project create a file named entrypoint.sh

touch entrypoint.sh

Add the following script to listen to the Postgres database port until it is ready to accept connections and then apply migrations and collect static files.

#!/bin/sh

echo 'Waiting for postgres...'

while ! nc -z $DB_HOSTNAME $DB_PORT; do
    sleep 0.1
done

echo 'PostgreSQL started'

echo 'Running migrations...'
python manage.py migrate

echo 'Collecting static files...'
python manage.py collectstatic --no-input

exec "$@"

Update the file permissions locally

chmod +x entrypoint.sh

Now, to use this script, you need to have Netcat installed on your image. Therefore, update Dockerfile to install this networking utility and use the bash script as a Docker entrypoint command.

FROM python:3.10.2-slim-bullseye

ENV PIP_DISABLE_PIP_VERSION_CHECK 1
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

WORKDIR /code

COPY ./requirements.txt .

RUN apt-get update -y && \
    apt-get install -y netcat && \
    pip install --upgrade pip && \
    pip install -r requirements.txt

COPY ./entrypoint.sh .
RUN chmod +x /code/entrypoint.sh

COPY . .

ENTRYPOINT ["/code/entrypoint.sh"]

Rebuild the image and spin up the containers.

docker-compose up --build

Go to http://localhost:8000/

Celery and Redis Configuration

Celery does time-intensive tasks asynchronously in the background so that your web app can continue to respond quickly to users’ requests. Use Redis together with Celery since it can serve as both a message broker and a database back end at the same time.

Add Redis and Celery services to docker-compose.yml

redis:
    image: redis:7

celery:
  build: .
  command: celery -A config worker -l info
  volumes:
    - .:/code
  env_file:
    - ./.env
  depends_on:
    - db
    - redis
    - web

While at it, update the web service as well:

depends_on:
    - redis
    - db

Once that is set up, navigate to the config folder and create a file named celery.py

cd config
touch celery.py

Then, add the following snippet inside it:

# config/celery.py

import os

from decouple import config
from celery import Celery

os.environ.setdefault("DJANGO_SETTINGS_MODULE", config("DJANGO_SETTINGS_MODULE"))
app = Celery("config")
app.config_from_object("django.conf:settings", namespace="CELERY")
app.autodiscover_tasks()

Next, head over to base.py and add the following configuration at the bottom:

# settings/base.py

# Celery
CELERY_BROKER_URL = config("CELERY_BROKER_URL")
CELERY_RESULT_BACKEND = config("REDIS_BACKEND")

Update .env to include the above environment variables:

# Celery
CELERY_BROKER_URL=redis://redis:6379/0

# Redis
REDIS_BACKEND=redis://redis:6379/0

The final update goes into the __init__.py file of the config folder:

# config/__init__.py

from .celery import app as celery_app

__all__ = ('celery_app',)

Test it out again:

docker-compose up --build

Tweak Docker Compose for Production

Django’s built-in server is not suitable for production so you should be using a production-grade WSGI server like Gunicorn in a production environment.

In addition, you should also consider adding Nginx to act as a reverse proxy for Gunicorn and serve static files.

Therefore, create a file named docker-compose.prod.yml at the root of your project and add/update the following services:

version: "3.9"

services:
  web:
    build: .
    restart: always
    command: gunicorn config.wsgi:application --bind 0.0.0.0:8000
    env_file:
      - ./.env
    expose:
      - 8000
    volumes:
      - static_volume:/code/staticfiles
      - media_volume:/code/mediafiles
    depends_on:
      - redis
      - db
  db:
    image: postgres:13
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    environment:
      - POSTGRES_USER=${DB_USERNAME}
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=${DB_NAME}

  redis:
    image: redis:7

  celery:
    build: .
    restart: always
    command: celery -A config worker -l info
    volumes:
      - .:/code
    env_file:
      - ./.env
    depends_on:
      - db
      - redis
      - web

  nginx:
    build: ./nginx
    restart: always
    ports:
      - ${NGINX_PORT}:80
    volumes:
      - static_volume:/code/staticfiles
      - media_volume:/code/mediafiles
    depends_on:
      - web

volumes:
  postgres_data:
  static_volume:
  media_volume:

There are a couple of things worth noting from the above file:

The use of expose instead of ports. This allows the web service to be exposed to other services inside Docker but not to the host machine.
Static and media volumes to persist data generated by and used by web and nginx services.

Don’t forget to update .env to include the NGINX_PORT environment variable:

# NGINX
NGINX_PORT=80

Then, in your project root directory, create the following folder and files:

mkdir nginx
cd nginx
touch Dockerfile
touch nginx.conf

Update the respective files:

# nginx/Dockerfile

FROM nginx:stable-alpine

RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d

EXPOSE 80

The above file pulls the base Nginx image, removes the default configuration, and copies the one that you created i.e. nginx.conf with the following content:

# nginx/nginx.conf

upstream web_app {
    server web:8000;
}

server {

    listen 80;

    location /static/ {
        alias /code/staticfiles/;
    }

    location /media/ {
        alias /code/mediafiles/;
    }

    location / {
        proxy_pass http://web_app;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }

}

Worth noting in the above configuration is that static and media file requests are routed to the static files and media files folders respectively.

Test your production setup locally:

docker-compose -f docker-compose.prod.yml up --build

Go to http://localhost/ The static files should be loaded correctly as well.

Conclusion

This tutorial has walked you through containerizing your Django application both for local development and production. In addition to the ease of containerized deployment, working inside Docker locally is also time-saving because it minimizes the setup you need to configure on your machine.

If you got lost somewhere throughout the guide, check out the project on GitHub

Happy coding! 🖤

Class-Based Views in DRF are Powerful

Hana Belay — Mon, 03 Oct 2022 06:31:15 +0000

If you are starting out with Django Rest Framework, you may feel a bit overwhelmed by the different types of views that exist. However, you will start appreciating how time-saving and powerful the abstractions are once you understand what to use and when.

Here, I have compiled some tips on GenericViews and ViewSets you might want to refer to when building your REST APIs.

Prerequisite
Introduction
Using GenericViews
1. get_object(self)
2. get_queryset(self)
3. perform_create(self, serializer)
The Power of ViewSets
1. Different Serializers for Read and Write
2. Different Permissions for Different Actions
3. ReadOnlyModelViewSet
Conclusion

Prerequisite

This article assumes that you have a basic understanding on Django and Django Rest Framework (DRF). A decent understanding of serializers and views is also needed.

Introduction

You might be asking yourself, why should I even use class-based views when I can have more control of what is happening in function-based views? This section will answer that and highlight class-based views.

A view is a place where you can put the logic of your application. In general, we have 2 types of views in Django:

Function-based views
Class-based views

The major problem with function-based views is the lack of an easy way to extend them. You may see yourself using the same kind of code over and over again throughout your project which is not a good design principle.

In addition, function-based views use conditional branching inside a single view function to handle different HTTP methods which might make your code unreadable.

Class-based views aren’t a replacement for function-based views. However, they provide you with a way of writing views in an object-oriented fashion. This means that they can be really powerful and highly extensible by using concepts from OOP such as inheritance and Mixin (multiple inheritance).

Anyways, we have the following class-based views in DRF:

APIView
GenericView
ViewSets

APIView is similar to Django’s View class (It is actually an extension of it). You may have been using this approach to dispatch your requests to an appropriate handler like get() or post().

That being said, let's get started.

Using GenericViews

Can you think of some tasks that you repeat very often while working on a project? Tasks like form handling, list view, pagination, and many other common tasks might make your development experience boring because you repeat the same pattern over and over again. GenericViews come to the rescue by taking certain common patterns and abstracting them so that you can quickly write common views of data and save yourself time for a cup of tea🍵

Here are some of the methods you might often want to override when using GenericViews.

`get_object(self)`

Assume you want to have a view that will handle a user’s request to retrieve and update their profile.

class ProfileAPIView(RetrieveUpdateAPIView):
    """
    Get, Update user profile
    """
    queryset = Profile.objects.all()
    serializer_class = ProfileSerializer
    permission_classes = (IsUserProfileOwner,)

Simple right? you override the queryset attribute to determine the object you want the view to return, as well as your serializer class and permission class. Then, you define the path in urls.py file like this.

path('profile/<int:pk>/', ProfileAPIView.as_view(), name='profile_detail'),

This is the kind of pattern you may have used to achieve the goal. However, another way of doing the same thing is by overriding the get_object(self) method to return a profile instance without having to provide a lookup field (<int:pk>) in your path.

class ProfileAPIView(RetrieveUpdateAPIView):
    """
    Get, Update user profile
    """
    queryset = Profile.objects.all()
    serializer_class = ProfileSerializer
    permission_classes = (IsUserProfileOwner,)

    def get_object(self):
        return self.request.user.profile

This way, you can modify urls.py file to remove <int:pk> from the path:

path('profile/', ProfileAPIView.as_view(), name='profile_detail'),
.

`get_queryset(self)`

Want to return a queryset that is specific to the user making a request? You can do so using get_queryset(self) method

class OrderListCreate(ListCreateAPIView):
    """
    List, Create orders of a user
    """
    queryset = Order.objects.all()
    permission_classes = (IsOrderByBuyerOrAdmin, )

    def get_queryset(self):
        res = super().get_queryset()
        user = self.request.user
        return res.filter(buyer=user)

The get_queryset(self) method filters the response to include a list of orders of the currently authenticated user.

`perform_create(self, serializer)`

Assume you have a Recipe class. When users want to create a recipe, you need to hide the author field in your serializer:

author = serializers.PrimaryKeyRelatedField(read_only=True)

and then in your views, you can automatically set author to the currently authenticated user by overriding the perform_create(self, serializer) method.

class RecipeCreateAPIView(CreateAPIView):
    """
    Create: a recipe
    """
    queryset = Recipe.objects.all()
    serializer_class = RecipeSerializer
    permission_classes = (IsAuthenticated,)

    def perform_create(self, serializer):
        serializer.save(author=self.request.user)

Similar to perform_create(self, serializer), there are also perform_update(self, serializer) and perform_destroy(self, serializer) methods.

The Power of ViewSets

Say you want to perform CRUD operations on a user's order. Using ModelViewSet, doing so is as simple as:

class OrderViewSet(ModelViewSet):
    """
    CRUD orders of a user
    """
    queryset = Order.objects.all()
    serializer_class = (SomeSerializer, )
        permission_classes = (SomePermission, )

The above class provides you with everything you need for CRUD operations on the Order model. In addition, one of the main advantages of using ModelViewSet, or any other type of ViewSet, is to have URL endpoints automatically defined for you through Routers

# urls.py

from django.urls import path, include
from rest_framework.routers import DefaultRouter

from orders.views import OrderViewSet

app_name = 'orders'

router = DefaultRouter()
router.register(r'', OrderViewSet)

urlpatterns = [
    path('', include(router.urls)),
]

With just that, you have URL endpoints for list, create, retrieve, update, and destroy actions!

Different Serializers for Read and Write

Ever needed to separate your serializer for read and write operation? Perhaps because you have a lot of nested fields, but you only need a few of them for write operation? You can easily use a single view for both serializers by overriding the get_serializer_class(self) method.

class ProductViewSet(ModelViewSet):
    """
    CRUD products
    """
    queryset = Product.objects.all()

    def get_serializer_class(self):
        if self.action in ('create', 'update', 'partial_update', 'destroy'):
            return ProductWriteSerializer

        return ProductReadSerializer

Different Permissions for Different Actions

get_permissions(self) method helps you separate permissions for different actions inside the same view.

def get_permissions(self):
    if self.action in ("create", ):
        self.permission_classes = (permissions.IsAuthenticated, )
    elif self.action in ('update', 'partial_update', 'destroy'):
        self.permission_classes = (IsSellerOrAdmin, )
    else:
        self.permission_classes = (permissions.AllowAny, )

    return super().get_permissions()

Note: You can use methods like get_queryset(self), perform_create(self, serializer) et cetera inside Vewsets as well.

ReadOnlyModelViewSet

If you plan to make your view read-only, you can use ReadOnlyModelViewSet

class ProductCategoryViewSet(ReadOnlyModelViewSet):
    """
    List and Retrieve product categories
    """
    queryset = ProductCategory.objects.all()
    serializer_class = ProductCategoryReadSerializer
    permission_classes = (permissions.AllowAny, )

Conclusion

In general, you can see that ViewSets have the highest level of abstraction and you can use them to avoid writing all the code for basic and repetitive stuff. They are a huge time-saver! However, if you need to have more control or do some custom work, using APIView or GenericAPIView makes sense.

For instance, in the following code, I’m using APIView to create a Stripe checkout session. I think this is a good candidate for using APIView

class StripeCheckoutSessionCreateAPIView(APIView):
    """
    Create and return checkout session ID for order payment of type 'Stripe'
    """
    permission_classes = (IsPaymentForOrderNotCompleted,
                          DoesOrderHaveAddress, )

    def post(self, request, *args, **kwargs):
        order = get_object_or_404(Order, id=self.kwargs.get('order_id'))

        order_items = []

        for order_item in order.order_items.all():
            product = order_item.product
            quantity = order_item.quantity

            data = {
                'price_data': {
                    'currency': 'usd',
                    'unit_amount_decimal': product.price,
                    'product_data': {
                        'name': product.name,
                        'description': product.desc,
                        'images': [f'{settings.BACKEND_DOMAIN}{product.image.url}']
                    }
                },
                'quantity': quantity
            }

            order_items.append(data)

        checkout_session = stripe.checkout.Session.create(
            payment_method_types=['card'],
            line_items=order_items,
            metadata={
                "order_id": order.id
            },
            mode='payment',
            success_url=settings.PAYMENT_SUCCESS_URL,
            cancel_url=settings.PAYMENT_CANCEL_URL
        )

        return Response({'sessionId': checkout_session['id']}, status=status.HTTP_201_CREATED)

P.S. Check this out https://www.cdrf.co/ to get a reference of all the methods and attributes of any class-based view in DRF.

The snippets are taken from my projects on GitHub. You can check them out.

Happy coding! 🖤

An E-commerce API

Hana Belay — Mon, 26 Sep 2022 06:48:30 +0000

One of my most recent projects is an E-commerce API that has helped me solidify more advanced concepts in Django and Django Rest Framework. I learned to work in a dockerized environment and use Nginx, Gunicorn ... inside Docker to make my application production ready.

Basic Functionalities

Registration using either phone number or email
Basic E-commerce features.
Payment integration using Stripe.
Caching using a Redis backend.
Sending emails asynchronously using Celery and Redis as a message broker.
Custom permissions set for necessary endpoints.
Documentation using DRF Spectacular
Dockerized for local development and production

Technologies Used

Django Rest Framework
PostgreSQL
Celery
Redis
Nginx
Docker
Stripe

This project makes use of:

Viewsets
Custom permissions
Nested serializers and so on. If you would like to strengthen your skills, I highly recommend you to check it out

I used Docker for local development and it has been so great! And then, with some adjustments, the application is production ready.

Tip: you can export your database schema to a SQL file using the command below:

docker exec -i [container_id] pg_dump -U [postgres_user]  --schema-only [database_name] > [target_path]

And then use this tool https://dbdiagram.io/ to generate ER diagram while playing around with the SQL code.

Link to GitHub repo: https://github.com/earthcomfy/django-ecommerce-api

I welcome any suggestion. Follow me to get upcoming tutorials.

Build Authentication Using Firebase | React | Express

Hana Belay — Mon, 12 Sep 2022 07:03:12 +0000

Hi everyone, in this tutorial, we are going to fire up an authentication system using React, Firebase, and Express. We will also use Tailwind to create the user interface.

Introduction
React and Tailwind Set Up
1. React Router
2. Register and Login Components
Firebase Set Up
Firebase and React Integration
1. React Context
2. Error Handling
3. Profile
4. Logout
Enable Dark Mode
Navigation
Private Route
Express Server
1. Express Boilerplate
2. Enabling Cors
3. Using Environment Variables
Connect with React
1. Sending Firebase Token to Express
2. Creating the Middleware
Final Thoughts

Introduction

To set up a registration/authentication system, we will leverage Firebase, a Backend-as-a-Service (Baas). What’s a BaaS?

Cloud computing has transformed the way we use technology. The BaaS cloud service model allows developers to focus on the frontend of an application by abstracting away all the stuff that goes behind it. Through BaaS, developers outsource pre-written software for different activities such as user authentication, database management, cloud storage, hosting, push notifications, and so on. We are going to use the user authentication service provided by Firebase for this project.

Here is the workflow:

React will send a request to register and login a user to Firebase.
Firebase will give a token to React
React will use that token to send subsequent requests to an Express server.
The Express server will verify the token using the Firebase admin SDK and sends a response back to React.

Quick Note:

Technically you don’t need Express for this if you aren’t going to use a backend for your project. However, in our case, we need an Express server to later create the chat API endpoints and connect with MongoDB.
Also, if you encounter any issues throughout the tutorial, you can check out the code in the GitHub repository.

React and Tailwind Set Up

Let's create a React application first. Type in the following to create a React app.

npx create-react-app frontend

Remove git since we won’t use it inside the frontend app. If you are on Linux, you can remove it by running this:

cd frontend
rm -rf .git

Alright, we are going to use Tailwind CSS to create the components, so let’s install it.

Make sure you are inside the frontend folder, open up your terminal and install Tailwind CSS


# Installs tailwindcss and its dependencies
npm install -D tailwindcss postcss autoprefixer

# Generates tailwind.config.js and postcss.config.js files
npx tailwindcss init -p

Open tailwind.config.js and configure your template paths.

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./src/**/*.{js,jsx,ts,tsx}"],
  theme: {
    extend: {},
  },
  plugins: [],
};

Open index.css, remove the content and add the following Tailwind directives. Check this out to learn more about these Tailwind-specific at-rules.

@tailwind base;
@tailwind components;
@tailwind utilities;

Now, let’s delete files we won’t be using. The final structure should look something like this:

Your index.js file should look like this:

import React from "react";
import ReactDOM from "react-dom/client";
import "./index.css";
import App from "./App";

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

And finally to make sure everything is set up correctly, add the following to App.js and start the project.

// App.js

function App() {
  return (
    <div>
      <h1 className="text-3xl font-bold underline">Hello world!</h1>
    </div>
  );
}

export default App;

Start the project:

npm run start

Perfect! now inside the src folder, create another folder named components. Then, inside components, create a folder named accounts . We will put user auth-related components inside it.

Inside accounts, create 2 files named Register.js and Login.js

For now, put a boilerplate like the following. If you are on VSCode, you can generate this by using the rfc shortcut.

// Register.js

import React from "react";

export default function Register() {
  return <div>Register</div>;
}

// Login.js

import React from "react";

export default function Login() {
  return <div>Login</div>;
}

React Router

We will be using React router V6 for routing between different pages. Let’s go ahead and install it.

npm i react-router-dom

Open App.js and create the path for login and register.

// App.js

import { BrowserRouter as Router, Routes, Route } from "react-router-dom";

import Register from "./components/accounts/Register";
import Login from "./components/accounts/Login";

function App() {
  return (
    <Router>
      <Routes>
        <Route exact path="/register" element={<Register />} />
        <Route exact path="/login" element={<Login />} />
      </Routes>
    </Router>
  );
}

export default App;

Go to your browser and test the routes: http://localhost:3000/login and http://localhost:3000/register

Register and Login Components

Up until this point, we have been doing basic configuration. Let’s now get to creating the UI for account registration and login.

// Register.js

import { Link } from "react-router-dom";

export default function Register() {
  return (
    <div className="min-h-full flex items-center justify-center py-12 px-4 sm:px-6 lg:px-8">
      <div className="max-w-md w-full space-y-8">
        <div>
          <h2 className="mt-4 text-3xl text-center tracking-tight font-light dark:text-white">
            Register your account
          </h2>
        </div>
        <form className="mt-8 space-y-6">
          <div className="rounded-md shadow-sm -space-y-px">
            <div>
              <input
                id="email-address"
                name="email"
                type="email"
                autoComplete="email"
                required
                className="appearance-none rounded-none relative block w-full px-3 py-2 placeholder-gray-500 rounded-t-md bg-gray-50 border border-gray-300 text-gray-900 text-sm focus:outline-none focus:ring-blue-500 focus:border-blue-500 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500 focus:z-10 sm:text-sm"
                placeholder="Email address"
              />
            </div>
            <div>
              <input
                id="password"
                name="password"
                type="password"
                autoComplete="current-password"
                required
                className="appearance-none rounded-none relative block w-full px-3 py-2 placeholder-gray-500 rounded-t-md bg-gray-50 border border-gray-300 text-gray-900 text-sm focus:outline-none focus:ring-blue-500 focus:border-blue-500 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500 focus:z-10 sm:text-sm"
                placeholder="Password"
              />
            </div>
            <div>
              <input
                id="confirmPassword"
                name="confirmPassword"
                type="password"
                autoComplete="current-password"
                required
                className="appearance-none rounded-none relative block w-full px-3 py-2 placeholder-gray-500 rounded-t-md bg-gray-50 border border-gray-300 text-gray-900 text-sm focus:outline-none focus:ring-blue-500 focus:border-blue-500 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500 focus:z-10 sm:text-sm"
                placeholder="Password"
              />
            </div>
          </div>
          <div>
            <button
              type="submit"
              className=" w-full flex justify-center py-2 px-4 border border-transparent text-sm font-medium rounded-md text-white bg-sky-800 hover:bg-sky-900"
            >
              Register
            </button>
          </div>
          <div className="flex items-center justify-between">
            <div className="text-sm">
              <Link
                to="/login"
                className="text-blue-600 hover:underline dark:text-blue-500"
              >
                Already have an account? Login
              </Link>
            </div>
          </div>
        </form>
      </div>
    </div>
  );
}

We have 3 fields. One for Email, the other two for password and password confirmation respectively. And for Login.js we have 2 fields; Email and password.

// Login.js

import { Link } from "react-router-dom";

export default function Login() {
  return (
    <div className="min-h-full flex items-center justify-center py-12 px-4 sm:px-6 lg:px-8">
      <div className="max-w-md w-full space-y-8">
        <div>
          <h2 className="mt-4 text-3xl text-center tracking-tight font-light dark:text-white">
            Login to your account
          </h2>
        </div>
        <form className="mt-8 space-y-6">
          <div className="rounded-md shadow-sm -space-y-px">
            <div>
              <input
                id="email-address"
                name="email"
                type="email"
                autoComplete="email"
                required
                className="appearance-none rounded-none relative block w-full px-3 py-2 placeholder-gray-500 rounded-t-md bg-gray-50 border border-gray-300 text-gray-900 text-sm focus:outline-none focus:ring-blue-500 focus:border-blue-500 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500 focus:z-10 sm:text-sm"
                placeholder="Email address"
              />
            </div>
            <div>
              <input
                id="password"
                name="password"
                type="password"
                autoComplete="current-password"
                required
                className="appearance-none rounded-none relative block w-full px-3 py-2 placeholder-gray-500 rounded-t-md bg-gray-50 border border-gray-300 text-gray-900 text-sm focus:outline-none focus:ring-blue-500 focus:border-blue-500 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500 focus:z-10 sm:text-sm"
                placeholder="Password"
              />
            </div>
          </div>
          <div>
            <button
              type="submit"
              className=" w-full flex justify-center py-2 px-4 border border-transparent text-sm font-medium rounded-md text-white bg-sky-800 hover:bg-sky-900"
            >
              Login
            </button>
          </div>
          <div className="flex items-center justify-between">
            <div className="text-sm">
              <Link
                to="/register"
                className="text-blue-600 hover:underline dark:text-blue-500"
              >
                Don't have an account? Register
              </Link>
            </div>
          </div>
        </form>
      </div>
    </div>
  );
}

Don’t worry about the classes of the elements that are prefixed with dark. We will talk about them later when we enable dark mode.

Let’s now use the useState hook to store the form data. Inside Register.js, import useState at the top and add the following 3 states.

import { useState } from "react";

const [email, setEmail] = useState("");
const [password, setPassword] = useState("");
const [confirmPassword, setConfirmPassword] = useState("");

Then, add an onChange event listener to the input fields as follows.

onChange={(e) => setEmail(e.target.value)}
onChange={(e) => setPassword(e.target.value)}
onChange={(e) => setConfirmPassword(e.target.value)}

We now need a function that will handle the form submission.

async function handleFormSubmit(e) {
    e.preventDefault();

    // Here We will get form values and 
        // invoke a function that will register the user
}

Add the function as an onSubmit event listener to the form.

onSubmit={handleFormSubmit}

Do the same thing for Login.js. The only difference is that we don’t have a confirm password input field. The rest is the same. Now that our forms are ready, let’s move our attention to Firebase.

Firebase Set Up

If it’s your first time using Firebase, follow the following steps to create a project. Otherwise, you can move to the next section.

We first need to create a Firebase project using the Firebase console, so Log in and then click Create a project.

Give any name you like for the project and click Continue. You will then be prompted to enable Google Analytics for your project (optional). We don’t need that.

Once you have completed the steps, you will be presented with a Dashboard. Click on Authentication from the navigation panel and go to the Sign-in Method tab. Enable Email/Password method since that’s what we are going to use.

Firebase and React Integration

For React to communicate with Firebase services, we need to install the firebase package.

npm i firebase

After you have created a new project in Firebase, you need to create an application. Go to your Firebase Console dashboard, click on Project Settings, and select this icon (</>) to add Firebase to your web app. Doing so will give you config data.

Create a .env file inside the root directory of your project and store all these config data in it.

// .env

REACT_APP_FIREBASE_API_KEY = 
REACT_APP_FIREBASE_AUTH_DOMAIN = 
REACT_APP_FIREBASE_PROJECT_ID = 
REACT_APP_FIREBASE_STORAGE_BUCKET = 
REACT_APP_FIREBASE_MESSAGING_SENDER_ID = 
REACT_APP_FIREBASE_APP_ID =

When setting up environment variables, you should prefix them with REACT_APP_. In addition, make sure to put the .env file in your root folder. Finally, restart your server for the changes to take place.

Inside the src folder, create a folder called config and inside it, create a file called firebase.js This is where we will set up Firebase.

// firebase.js

import { initializeApp } from "firebase/app";
import { getAuth } from "firebase/auth";

const firebaseConfig = {
  apiKey: process.env.REACT_APP_FIREBASE_API_KEY,
  authDomain: process.env.REACT_APP_FIREBASE_AUTH_DOMAIN,
  projectId: process.env.REACT_APP_FIREBASE_PROJECT_ID,
  storageBucket: process.env.REACT_APP_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.REACT_APP_FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.REACT_APP_FIREBASE_APP_ID,
};

const app = initializeApp(firebaseConfig);

// gives us an auth instance
const auth = getAuth(app);

// in order to use this auth instance elsewhere
export default auth;

Now that we have Firebase setup, we can start doing authentication.

React Context

We are going to use React context to set up the authentication because we want to access the current user everywhere in our app. If you aren’t familiar with React context, don’t worry. We are going to walk through it together.

React context allows us to share data (state) across our components more easily. This is great when you are passing data that can be used in any component of your application.

Inside the src folder, create a folder named contexts and inside it, create a file named AuthContext.js and put the following to set up context.

// AuthContext.js

import { createContext, useContext } from "react";

const AuthContext = createContext();

export function useAuth() {
  return useContext(AuthContext);
}

export function AuthProvider({ children }) {
  const value = {};

  return (
    <AuthContext.Provider value={value}>
      {children}
    </AuthContext.Provider>
  );
}

What is going on? Well, let me explain

const AuthContext = createContext() will return a Consumer and a Provider component. Provider provides state to its children. It takes in the value prop and passes it down to its children components that might need to access them. The Consumer consumes and uses the state passed down to it by the Provider.
In the above case, the component that will wrap the Provider is AuthProvider We also exported it, so that we can use it elsewhere.
The custom useAuth hook will allow us to consume context in our application by returning a useContext instance of AuthContext

That is the basic setup for context. Let’s now add Firebase functions to register, login, and find the current user.

First, import createUserWithEmailAndPassword and signInWithEmailAndPassword that Firebase provides for user registration and login. Also, import auth from our earlier Firebase configuration.

// AuthContext.js

import {
  createUserWithEmailAndPassword,
  signInWithEmailAndPassword,
} from "firebase/auth";

import auth from "../config/firebase";

Users can create a new account by passing their email address and password. The functions return a Promise and we will consume that inside the register and login components.

function register(email, password) {
   // If the new account was created, the user is signed in automatically.
   return createUserWithEmailAndPassword(auth, email, password);
}

function login(email, password) {
   return signInWithEmailAndPassword(auth, email, password);
}

Alright, but how can we get the signed-in user details? We can set an observer on the auth object. Before that, however, let’s first create a state that will store the current user and pass it down in the value props.

import { useState } from "react";
const [currentUser, setCurrentUser] = useState();

const value = {
    currentUser,
};

We can now set the onAuthStateChanged observer on the auth object. This will notify us when the user is signed in and update the state.

import { useEffect } from "react";

const [loading, setLoading] = useState(true);

useEffect(() => {
    const unsubscribe = auth.onAuthStateChanged((user) => {
      setCurrentUser(user);
      setLoading(false);
    });

    return unsubscribe;
}, []);

return (
    <AuthContext.Provider value={value}>
      {!loading && children}
    </AuthContext.Provider>
);

The observer i.e. onAuthStateChanged is put inside a useEffect because we only want to render it once i.e. when the component mounts. When the component un-mounts, we unsubscribe from the event.
The loading state is initially set to true. When Firebase finishes its job and updates the user, we set it to false. This will prevent the children components from rendering while the action is taking place.

The final code for AuthContext.js should look like this:

// AuthContext.js

import { createContext, useContext, useState, useEffect } from "react";
import {
  createUserWithEmailAndPassword,
  signInWithEmailAndPassword,
} from "firebase/auth";

import auth from "../config/firebase";

const AuthContext = createContext();

export function useAuth() {
  return useContext(AuthContext);
}

export function AuthProvider({ children }) {
  const [currentUser, setCurrentUser] = useState();
  const [loading, setLoading] = useState(true);

  function register(email, password) {
    return createUserWithEmailAndPassword(auth, email, password);
  }

  function login(email, password) {
    return signInWithEmailAndPassword(auth, email, password);
  }

  useEffect(() => {
    const unsubscribe = auth.onAuthStateChanged((user) => {
      setCurrentUser(user);
      setLoading(false);
    });

    return unsubscribe;
  }, []);

  const value = {
    currentUser,
    login,
    register,
  };

  return (
    <AuthContext.Provider value={value}>
      {!loading && children}
    </AuthContext.Provider>
  );
}

Let’s now wrap our components inside of the AuthProvider so that we have access to the context.

// App.js

import { BrowserRouter as Router, Routes, Route } from "react-router-dom";

import { AuthProvider } from "./contexts/AuthContext"; // import this
import Register from "./components/accounts/Register";
import Login from "./components/accounts/Login";

function App() {
  return (
    <AuthProvider> // Wrap everything inside this provider
      <Router>
        <Routes>
          <Route exact path="/register" element={<Register />} />
          <Route exact path="/login" element={<Login />} />
        </Routes>
      </Router>
    </AuthProvider>
  );
}

export default App;

Now, to use the register and currentUser context, head over to Register.js and import the useAuth hook.

// Register.js

import { useAuth } from "../../contexts/AuthContext";

Then, import useEffect and useNavigate and add the following:

import { useEffect } from "react";
import { useNavigate } from "react-router-dom";

const navigate = useNavigate();
const { currentUser, register } = useAuth();
const [loading, setLoading] = useState(false);

  useEffect(() => {
    if (currentUser) {
      navigate("/");
    }
  }, [currentUser, navigate]);

const navigate = useNavigate(); React router hook that returns a function to navigate programmatically.
const { currentUser, register } = useAuth(); gets the currentUser and register contexts since those are what we will be using.
The loading state will be used to disable the button when the registration action is executing.
The useEffect hook is in place to prevent users from accessing the registration page while they are authenticated. It will redirect them to the home page if they try to do so.

Then inside the handleFormSubmit function we created earlier, we are going to handle the registration logic:

async function handleFormSubmit(e) {
    e.preventDefault();

    if (password !== confirmPassword) {
      return alert("Passwords do not match");
    }

    try {
      setLoading(true);
      await register(email, password);
      navigate("/profile");
    } catch (e) {
      alert("Failed to register");
    }

    setLoading(false);
  }

First, if the passwords don’t match we exit out of the function by alerting the error. For now, we are not managing the errors. Later, however, we will handle them using a state.
The register function returns a promise, so we are using the await keyword to wait for the call to be settled. And we are using the try…catch block for error handling. If the call is successful, the user will be redirected to the profile page (we haven’t created it yet). However, the flow will be sent to the catch block if it fails.

To disable the submit button when the action is executing, add disabled={loading} to the submit Button.

Cool! let’s test what we have so far. Start your server and go to http://localhost:3000/register and fill in the form with passwords that don’t match. You should get the following alert:

Now, fill in the correct credentials and you should be redirected to http://localhost:3000/profile. However, since we haven’t created this route yet, nothing will be displayed.

Do the same thing for the Login.js component. You only need to change the register call to login and remove the password confirmation check.

Error Handling

We want to use a single component that will handle and display errors (if there are any). For this, let’s use context.

Go to AuthContext.js and create this state:

const [error, setError] = useState("");

Add it to the value props:

const value = {
    error,
    setError,
};

Inside components, create a folder named layouts. And inside it, create a file called ErrorMessage.js We will use this component to display error messages from anywhere in our app.

First, let’s install herocions to use the X icon in our alert.

npm i @heroicons/react@v1

Then inside ErrorMessage.js:

// ErrorMessage.js

import { XCircleIcon } from "@heroicons/react/solid";

import { useAuth } from "../../contexts/AuthContext";

export default function ErrorMessage() {
  const { error, setError } = useAuth();

  return (
    error && (
      <div className="flex justify-center">
        <div className="rounded-md max-w-md w-full bg-red-50 p-4 mt-4">
          <div className="flex">
            <div className="flex-shrink-0">
              <XCircleIcon
                onClick={() => setError("")}
                className="h-5 w-5 text-red-400"
                aria-hidden="true"
              />
            </div>
            <div className="ml-3">
              <h3 className="text-sm font-medium text-red-800">
                Error: {error}
              </h3>
            </div>
          </div>
        </div>
      </div>
    )
  );
}

The above snippet checks if there is an error and displays it. When the X icon is clicked it will set the error to an empty string.

Then render this component inside App.js at the top.

import ErrorMessage from "./components/layouts/ErrorMessage"; // add this import

<AuthProvider>
      <Router>
        <ErrorMessage /> // add this
        <Routes>
          <Route exact path="/register" element={<Register />} />
          <Route exact path="/login" element={<Login />} />
        </Routes>
      </Router>
    </AuthProvider>

Now, let’s update Register.js to set the errors accordingly.

const { currentUser, register, setError } = useAuth(); // Get setError as well

async function handleFormSubmit(e) {
    e.preventDefault();

    if (password !== confirmPassword) {
      return setError("Passwords do not match"); // Replace the alert with this
    }

    try {
      setError(""); // Remove error when trying to register
      setLoading(true);
      await register(email, password);
      navigate("/profile");
    } catch (e) {
      setError("Failed to register"); // Replace the alert with this
    }

    setLoading(false);
  }

Do the same thing for Login.js and test it. Before testing it though, make sure to comment out the useEffect hook that checks if there is a current user so that it won’t redirect you to the home page.

You should get something like this:

Profile

Now that we have registration and login set up, let’s create a route to set a name and avatar for users.

The Firebase user object has basic properties such as displayName, photoURL, phoneNumber, etc. You can check this by logging the currentUser object on the console. We are going to update the user’s profile by using the updateProfile function from Firebase.

Open AuthContext.js and import this function:

import { updateProfile } from "firebase/auth";

Add the following function alongside register and login

function updateUserProfile(user, profile) {
    return updateProfile(user, profile);
}

The updateProfile function takes a user and any user information we need to update.

Add updateUserProfile in value props.

const value = {
    // ...
    updateUserProfile,
  };

We are going to update the display name and photo of the user. To generate cool avatars, we are going to use this API.

DiceBear uses the following URL as a source to generate images. https://avatars.dicebear.com/api/:sprites/:seed.svg

You can replace :sprites with male, female, human, identicon, initials, bottts, avataaars, jdenticon, gridyor micah. The value of :seed can be anything you like but don't use any sensitive or personal data here!

Inside the src folder, create a folder called utils. And inside it, create a file called GenerateAvatar.js

// GenerateAvatar.js

const generateDiceBearAvataaars = (seed) =>
  `https://avatars.dicebear.com/api/avataaars/${seed}.svg`;

const generateDiceBearBottts = (seed) =>
  `https://avatars.dicebear.com/api/bottts/${seed}.svg`;

const generateDiceBearGridy = (seed) =>
  `https://avatars.dicebear.com/api/gridy/${seed}.svg`;

export const generateAvatar = () => {
  const data = [];

  for (let i = 0; i < 2; i++) {
    const res = generateDiceBearAvataaars(Math.random());
    data.push(res);
  }
  for (let i = 0; i < 2; i++) {
    const res = generateDiceBearBottts(Math.random());
    data.push(res);
  }
  for (let i = 0; i < 2; i++) {
    const res = generateDiceBearGridy(Math.random());
    data.push(res);
  }
  return data;
};

The above function generates 6 random avatars and returns the array. We have exported the function so that we can use it elsewhere.

Now, create a file called Profile.js inside accounts. Most of the things in this file are going to be similar to Register.js and Login.js.

// Profile.js

import { generateAvatar } from "../../utils/GenerateAvatar";

const [avatars, setAvatars] = useState([]);

useEffect(() => {
    const fetchData = () => {
      const res = generateAvatar();
      setAvatars(res);
    };

    fetchData();
  }, []);

This will generate avatars using the utility function we created earlier and set them to the avatars state when the component mounts.

We will also have the following state to track the selected avatar.

const [selectedAvatar, setSelectedAvatar] = useState();

This is what Profile.js looks like now

// Profile.js

import { useState, useEffect } from "react";
import { useNavigate } from "react-router-dom";

import { useAuth } from "../../contexts/AuthContext";
import { generateAvatar } from "../../utils/GenerateAvatar";

function classNames(...classes) {
  return classes.filter(Boolean).join(" ");
}

export default function Profile() {
  const navigate = useNavigate();

  const [username, setUsername] = useState("");
  const [avatars, setAvatars] = useState([]);
  const [selectedAvatar, setSelectedAvatar] = useState();
  const [loading, setLoading] = useState(false);

  const { currentUser, updateUserProfile, setError } = useAuth();

  useEffect(() => {
    const fetchData = () => {
      const res = generateAvatar();
      setAvatars(res);
    };

    fetchData();
  }, []);

  const handleFormSubmit = async (e) => {
    e.preventDefault();

    if (selectedAvatar === undefined) {
      return setError("Please select an avatar");
    }

    try {
      setError("");
      setLoading(true);
      const user = currentUser;
      const profile = {
        displayName: username,
        photoURL: avatars[selectedAvatar],
      };
      await updateUserProfile(user, profile);
      navigate("/");
    } catch (e) {
      setError("Failed to update profile");
    }

    setLoading(false);
  };

  return (
    <div className="min-h-full flex items-center justify-center py-12 px-4 sm:px-6 lg:px-8">
      <div className="max-w-md w-full space-y-8">
        <div className="text-center">
          <h2 className="mt-4 text-3xl text-center tracking-tight font-light dark:text-white">
            Pick an avatar
          </h2>
        </div>
        <form className="space-y-6" onSubmit={handleFormSubmit}>
          <div className="flex flex-wrap -m-1 md:-m-2">
            {avatars.map((avatar, index) => (
              <div key={index} className="flex flex-wrap w-1/3">
                <div className="w-full p-1 md:p-2">
                  <img
                    alt="gallery"
                    className={classNames(
                      index === selectedAvatar
                        ? "border-4  border-blue-700 dark:border-blue-700"
                        : "cursor-pointer hover:border-4 hover:border-blue-700",
                      "block object-cover object-center w-36 h-36 rounded-full"
                    )}
                    src={avatar}
                    onClick={() => setSelectedAvatar(index)}
                  />
                </div>
              </div>
            ))}
          </div>

          <div className="rounded-md shadow-sm -space-y-px">
            <input
              id="username"
              name="username"
              type="text"
              autoComplete="username"
              required
              className="appearance-none rounded-none relative block w-full px-3 py-2 placeholder-gray-500 rounded-t-md bg-gray-50 border border-gray-300 text-gray-900 text-sm focus:outline-none focus:ring-blue-500 focus:border-blue-500 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500 focus:z-10 sm:text-sm"
              placeholder="Enter a Display Name"
              defaultValue={currentUser.displayName && currentUser.displayName}
              onChange={(e) => setUsername(e.target.value)}
            />
          </div>
          <div>
            <button
              type="submit"
              disabled={loading}
              className="w-full py-2 px-4 border border-transparent text-sm font-medium rounded-md text-white bg-blue-700 hover:bg-blue-800 focus:ring-4 focus:outline-none focus:ring-blue-300 dark:bg-blue-600 dark:hover:bg-blue-700 dark:focus:ring-blue-800"
            >
              Update Profile
            </button>
          </div>
        </form>
      </div>
    </div>
  );
}

Now, let’s create the route in App.js

import Profile from "./components/accounts/Profile"; // Add this to the imports list

<Route exact path="/profile" element={<Profile />} /> // Add this route

Finally, go to http://localhost:3000/profile and check if everything is working. You will get something like this.

When you update the profile, it will redirect you to a blank page, don’t worry we haven’t created a home page yet.

Logout

First, let’s add the Firebase function that will allow us to log out users. Inside your AuthContext.js, add the following

import { signOut } from "firebase/auth"; // Add this import

function logout() {
    return signOut(auth);
}

Simple as that!

Then create a file called Logout.js inside the accounts folder. We are going to create a modal that will ask for the user’s confirmation to log out and fires the logout function. We are going to use the Dialog and Transition components from Headless UI so let’s install it first

npm i @headlessui/react

// Logout.js

import { Fragment, useRef } from "react";
import { useNavigate } from "react-router-dom";
import { Dialog, Transition } from "@headlessui/react";
import { ExclamationIcon } from "@heroicons/react/outline";

import { useAuth } from "../../contexts/AuthContext";

export default function Logout({ modal, setModal }) {
  const cancelButtonRef = useRef(null);
  const navigate = useNavigate();

  const { logout, setError } = useAuth();

  async function handleLogout() {
    try {
      setError("");
      await logout();
      setModal(false);
      navigate("/login");
    } catch {
      setError("Failed to logout");
    }
  }

  return (
    <Transition.Root show={modal} as={Fragment}>
      <Dialog
        as="div"
        className="fixed z-10 inset-0 overflow-y-auto"
        initialFocus={cancelButtonRef}
        onClose={setModal}
      >
        <div className="flex items-end justify-center min-h-screen pt-4 px-4 pb-20 text-center sm:block sm:p-0">
          <Transition.Child
            as={Fragment}
            enter="ease-out duration-300"
            enterFrom="opacity-0"
            enterTo="opacity-100"
            leave="ease-in duration-200"
            leaveFrom="opacity-100"
            leaveTo="opacity-0"
          >
            <Dialog.Overlay className="fixed inset-0 bg-gray-500 bg-opacity-75 transition-opacity" />
          </Transition.Child>

          {/* This element is to trick the browser into centering the modal contents. */}
          <span
            className="hidden sm:inline-block sm:align-middle sm:h-screen"
            aria-hidden="true"
          >
            &#8203;
          </span>
          <Transition.Child
            as={Fragment}
            enter="ease-out duration-300"
            enterFrom="opacity-0 translate-y-4 sm:translate-y-0 sm:scale-95"
            enterTo="opacity-100 translate-y-0 sm:scale-100"
            leave="ease-in duration-200"
            leaveFrom="opacity-100 translate-y-0 sm:scale-100"
            leaveTo="opacity-0 translate-y-4 sm:translate-y-0 sm:scale-95"
          >
            <div className="inline-block align-bottom bg-white rounded-lg text-left overflow-hidden shadow-xl transform transition-all sm:my-8 sm:align-middle sm:max-w-lg sm:w-full">
              <div className="bg-white dark:bg-gray-700 px-4 pt-5 pb-4 sm:p-6 sm:pb-4">
                <div className="sm:flex sm:items-start">
                  <div className="mx-auto flex-shrink-0 flex items-center justify-center h-12 w-12 rounded-full bg-red-100 dark:bg-gray-200 sm:mx-0 sm:h-10 sm:w-10">
                    <ExclamationIcon
                      className="h-6 w-6 text-red-600"
                      aria-hidden="true"
                    />
                  </div>
                  <div className="mt-3 text-center sm:mt-0 sm:ml-4 sm:text-left">
                    <Dialog.Title
                      as="h3"
                      className="text-lg leading-6 font-medium text-gray-500 dark:text-gray-400"
                    >
                      Logging out
                    </Dialog.Title>
                    <div className="mt-2">
                      <p className="text-sm text-gray-500 dark:text-gray-400">
                        Are you sure you want to log out ?
                      </p>
                    </div>
                  </div>
                </div>
              </div>
              <div className="bg-gray-50 dark:bg-gray-700 px-4 py-3 sm:px-6 sm:flex sm:flex-row-reverse">
                <button
                  type="button"
                  className="w-full inline-flex justify-center rounded-md border border-transparent shadow-sm px-4 py-2 bg-red-600 text-base font-medium text-white hover:bg-red-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-red-500 sm:ml-3 sm:w-auto sm:text-sm"
                  onClick={handleLogout}
                >
                  Logout
                </button>
                <button
                  type="button"
                  className="mt-3 w-full inline-flex justify-center shadow-sm px-4 py-2  sm:mt-0 sm:ml-3 sm:w-auto sm:text-sm
                  rounded-md border border-gray-300 bg-white text-gray-500 text-base font-medium hover:bg-gray-100 focus:outline-none focus:ring-gray-200 focus:ring-2 focus:ring-offset-2 hover:text-gray-900 dark:bg-gray-700 dark:text-gray-300 dark:border-gray-500 dark:hover:text-white dark:hover:bg-gray-600 dark:focus:ring-gray-600
                  "
                  onClick={() => setModal(false)}
                  ref={cancelButtonRef}
                >
                  Cancel
                </button>
              </div>
            </div>
          </Transition.Child>
        </div>
      </Dialog>
    </Transition.Root>
  );
}

Done!

Enable Dark Mode

If you have been paying attention to the Tailwind classes of our component elements, you must have seen something like dark:text-white This kind of style pattern is applied to the elements when dark mode is enabled. We haven’t enabled it yet, so let’s do that now.

Open your tailwind.config.js file and add the following:

darkMode: "class",

Inside layouts, create a file called ThemeToggler.js and add a button that will toggle between light and dark mode.

// ThemeToggler.js

export default function ThemeToggler() {
  return (
    <button
      ref={themeToggleBtn}
      type="button"
      className="text-gray-500 dark:text-gray-400 hover:bg-gray-100 dark:hover:bg-gray-700 focus:outline-none rounded-lg text-sm p-2.5"
      onClick={() => handleThemeToggle()}
    >
      <svg
        ref={themeToggleDarkIcon}
        className="hidden w-8 h-8"
        fill="currentColor"
        viewBox="0 0 20 20"
        xmlns="http://www.w3.org/2000/svg"
      >
        <path d="M17.293 13.293A8 8 0 016.707 2.707a8.001 8.001 0 1010.586 10.586z"></path>
      </svg>
      <svg
        ref={themeToggleLightIcon}
        className="hidden w-8 h-8"
        fill="currentColor"
        viewBox="0 0 20 20"
        xmlns="http://www.w3.org/2000/svg"
      >
        <path
          d="M10 2a1 1 0 011 1v1a1 1 0 11-2 0V3a1 1 0 011-1zm4 8a4 4 0 11-8 0 4 4 0 018 0zm-.464 4.95l.707.707a1 1 0 001.414-1.414l-.707-.707a1 1 0 00-1.414 1.414zm2.12-10.607a1 1 0 010 1.414l-.706.707a1 1 0 11-1.414-1.414l.707-.707a1 1 0 011.414 0zM17 11a1 1 0 100-2h-1a1 1 0 100 2h1zm-7 4a1 1 0 011 1v1a1 1 0 11-2 0v-1a1 1 0 011-1zM5.05 6.464A1 1 0 106.465 5.05l-.708-.707a1 1 0 00-1.414 1.414l.707.707zm1.414 8.486l-.707.707a1 1 0 01-1.414-1.414l.707-.707a1 1 0 011.414 1.414zM4 11a1 1 0 100-2H3a1 1 0 000 2h1z"
          fillRule="evenodd"
          clipRule="evenodd"
        ></path>
      </svg>
    </button>
  );
}

Create a useRef hook to access the above theme toggle button, theme toggle light icon, and theme toggle dark icon.

import { useRef } from "react";

const themeToggleBtn = useRef();
const themeToggleLightIcon = useRef();
const themeToggleDarkIcon = useRef();

Add refs to the toggle button, dark icon, and light icon SVGs respectively like this:

ref={themeToggleBtn}
ref={themeToggleDarkIcon}
ref={themeToggleLightIcon}

For the button, add an onClick event listener:

onClick={() => handleThemeToggle()}

Let’s now create this function. When the button is pressed it will check whether or not the user has a color-theme set in local storage previously, add/remove the dark class, and update local storage.

const handleThemeToggle = () => {
    themeToggleDarkIcon.current.classList.toggle("hidden");
    themeToggleLightIcon.current.classList.toggle("hidden");

    if (localStorage.getItem("color-theme")) {
      if (localStorage.getItem("color-theme") === "light") {
        document.documentElement.classList.add("dark");
        localStorage.setItem("color-theme", "dark");
      } else {
        document.documentElement.classList.remove("dark");
        localStorage.setItem("color-theme", "light");
      }
    } else {
      if (document.documentElement.classList.contains("dark")) {
        document.documentElement.classList.remove("dark");
        localStorage.setItem("color-theme", "light");
      } else {
        document.documentElement.classList.add("dark");
        localStorage.setItem("color-theme", "dark");
      }
    }
  };

Next, when the component renders, we want to either set the dark or light mode by checking previous user preference or settings.

useEffect(() => {
    if (
      localStorage.getItem("color-theme") === "dark" ||
      (!("color-theme" in localStorage) &&
        window.matchMedia("(prefers-color-scheme: dark)").matches)
    ) {
      document.documentElement.classList.add("dark");
      themeToggleLightIcon.current.classList.remove("hidden");
    } else {
      document.documentElement.classList.remove("dark");
      themeToggleDarkIcon.current.classList.remove("hidden");
    }
  }, []);

Final code for ThemeToggler.js

// ThemeToggler.js

import { useEffect, useRef } from "react";

export default function ThemeToggler() {
  const themeToggleBtn = useRef();
  const themeToggleLightIcon = useRef();
  const themeToggleDarkIcon = useRef();

  useEffect(() => {
    if (
      localStorage.getItem("color-theme") === "dark" ||
      (!("color-theme" in localStorage) &&
        window.matchMedia("(prefers-color-scheme: dark)").matches)
    ) {
      document.documentElement.classList.add("dark");
      themeToggleLightIcon.current.classList.remove("hidden");
    } else {
      document.documentElement.classList.remove("dark");
      themeToggleDarkIcon.current.classList.remove("hidden");
    }
  }, []);

  const handleThemeToggle = () => {
    themeToggleDarkIcon.current.classList.toggle("hidden");
    themeToggleLightIcon.current.classList.toggle("hidden");

    if (localStorage.getItem("color-theme")) {
      if (localStorage.getItem("color-theme") === "light") {
        document.documentElement.classList.add("dark");
        localStorage.setItem("color-theme", "dark");
      } else {
        document.documentElement.classList.remove("dark");
        localStorage.setItem("color-theme", "light");
      }
    } else {
      if (document.documentElement.classList.contains("dark")) {
        document.documentElement.classList.remove("dark");
        localStorage.setItem("color-theme", "light");
      } else {
        document.documentElement.classList.add("dark");
        localStorage.setItem("color-theme", "dark");
      }
    }
  };

  return (
    <button
      ref={themeToggleBtn}
      type="button"
      className="text-gray-500 dark:text-gray-400 hover:bg-gray-100 dark:hover:bg-gray-700 focus:outline-none rounded-lg text-sm p-2.5"
      onClick={() => handleThemeToggle()}
    >
      <svg
        ref={themeToggleDarkIcon}
        className="hidden w-8 h-8"
        fill="currentColor"
        viewBox="0 0 20 20"
        xmlns="http://www.w3.org/2000/svg"
      >
        <path d="M17.293 13.293A8 8 0 016.707 2.707a8.001 8.001 0 1010.586 10.586z"></path>
      </svg>
      <svg
        ref={themeToggleLightIcon}
        className="hidden w-8 h-8"
        fill="currentColor"
        viewBox="0 0 20 20"
        xmlns="http://www.w3.org/2000/svg"
      >
        <path
          d="M10 2a1 1 0 011 1v1a1 1 0 11-2 0V3a1 1 0 011-1zm4 8a4 4 0 11-8 0 4 4 0 018 0zm-.464 4.95l.707.707a1 1 0 001.414-1.414l-.707-.707a1 1 0 00-1.414 1.414zm2.12-10.607a1 1 0 010 1.414l-.706.707a1 1 0 11-1.414-1.414l.707-.707a1 1 0 011.414 0zM17 11a1 1 0 100-2h-1a1 1 0 100 2h1zm-7 4a1 1 0 011 1v1a1 1 0 11-2 0v-1a1 1 0 011-1zM5.05 6.464A1 1 0 106.465 5.05l-.708-.707a1 1 0 00-1.414 1.414l.707.707zm1.414 8.486l-.707.707a1 1 0 01-1.414-1.414l.707-.707a1 1 0 011.414 1.414zM4 11a1 1 0 100-2H3a1 1 0 000 2h1z"
          fillRule="evenodd"
          clipRule="evenodd"
        ></path>
      </svg>
    </button>
  );
}

Finally, to apply dark mode to the body of our application, add the following in index.css. It will add our own default base styles for the body.

@layer base {
    body {
      @apply bg-white dark:bg-gray-900;
    }
  }

Let’s quickly add a navigation component and we will test the logout and dark mode functionalities.

Navigation

The navigation will contain theme toggler, logout and profile icons.

Inside layouts create a file called Header.js

// Header.js

import { LogoutIcon } from "@heroicons/react/outline";
import { useState } from "react";
import { Link } from "react-router-dom";

import { useAuth } from "../../contexts/AuthContext";
import Logout from "../accounts/Logout";
import ThemeToggler from "./ThemeToggler";

export default function Header() {
  const [modal, setModal] = useState(false);

  const { currentUser } = useAuth();

  return (
    <>
      <nav className="px- px-2 sm:px-4 py-2.5 bg-gray-50 border-gray-200 dark:bg-gray-800 dark:border-gray-700 text-gray-900 text-sm rounded border dark:text-white">
        <div className="container mx-auto flex flex-wrap items-center justify-between">
          <Link to="/" className="flex">
            <span className="self-center text-lg font-semibold whitespace-nowrap text-gray-900 dark:text-white">
              Chat App
            </span>
          </Link>
          <div className="flex md:order-2">
            <ThemeToggler />

            {currentUser && (
              <>
                <button
                  className="text-gray-500 dark:text-gray-400 hover:bg-gray-100 dark:hover:bg-gray-700 focus:outline-none rounded-lg text-sm p-2.5"
                  onClick={() => setModal(true)}
                >
                  <LogoutIcon className="h-8 w-8" aria-hidden="true" />
                </button>

                <Link
                  to="/profile"
                  className="text-gray-500 dark:text-gray-400 hover:bg-gray-100 dark:hover:bg-gray-700 focus:outline-none rounded-full text-sm p-2.5"
                >
                  <img
                    className="h-8 w-8 rounded-full"
                    src={currentUser.photoURL}
                    alt=""
                  />
                </Link>
              </>
            )}
          </div>
        </div>
      </nav>
      {modal && <Logout modal={modal} setModal={setModal} />}
    </>
  );
}

We used conditional rendering to display the logout and profile icons only when the user is authenticated.
The modal state will be used to render the Logout modal for confirmation.

Finally, let’s render Header.js inside App.js

// App.js

import Header from "./components/layouts/Header"; // Add this

<AuthProvider>
    <Router>
      <Header /> // And this
      <ErrorMessage />
      <Routes>
        <Route exact path="/register" element={<Register />} />
        <Route exact path="/login" element={<Login />} />
        <Route exact path="/profile" element={<Profile />} />
      </Routes>
    </Router>
</AuthProvider>

To test this go to http://localhost:3000/profile. You will get something like this when dark mode is enabled.

The logout modal (with light mode):

Great! moving on to private routes.

Private Route

Routes such as /profile should only be accessed if the user is logged in. To make such components private, let’s go ahead and create a higher-order component that will wrap them.

Inside the utils folder, create a file called WithPrivateRoute.js

// WithPrivateRoute.js

import { Navigate } from "react-router-dom";
import { useAuth } from "../contexts/AuthContext";

const WithPrivateRoute = ({ children }) => {
  const { currentUser } = useAuth();

    // If there is a current user it will render the passed down component
  if (currentUser) {
    return children;
  }

  // Otherwise redirect to the login route
  return <Navigate to="/login" />;
};

export default WithPrivateRoute;

We can now use this higher-order component to wrap Profile.js

The final look of App.js:


// App.js

import { BrowserRouter as Router, Routes, Route } from "react-router-dom";

import { AuthProvider } from "./contexts/AuthContext";
import Register from "./components/accounts/Register";
import Login from "./components/accounts/Login";
import Profile from "./components/accounts/Profile";
import WithPrivateRoute from "./utils/WithPrivateRoute";
import Header from "./components/layouts/Header";
import ErrorMessage from "./components/layouts/ErrorMessage";

function App() {
  return (
    <AuthProvider>
      <Router>
        <Header />
        <ErrorMessage />
        <Routes>
          <Route exact path="/register" element={<Register />} />
          <Route exact path="/login" element={<Login />} />
          <Route
            exact
            path="/profile"
            element={
              <WithPrivateRoute>
                <Profile />
              </WithPrivateRoute>
            }
          />
        </Routes>
      </Router>
    </AuthProvider>
  );
}

export default App;

You can test this by trying to access the profile page without logging in.

This marks the end of the frontend section for authentication. Let’s now get started with Express to verify users for subsequent requests.

Express Server

Express Boilerplate

The backend is going to be an independent app, so in a new terminal type in the following:

npm init -y

This will create a package.json file

Open it up and let’s modify a couple of things.

First, we are going to use ES 6 modules (import syntax), so let’s enable it.

"type": "module",

We are also going to use nodemon so that we don’t need to restart our server every time we make changes. If you haven’t already, install it globally:

npm install -g nodemon

Then add the following to the scripts (we will create server/index.js next)

"start": "nodemon server/index.js"

Your package.json should look like this

{
  "name": "chat-app",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "type": "module",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "nodemon server/index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.18.1"
  }
}

Now install Express:

npm i express

Create a folder named server, cd into it, and create index.js file. This is where we will set up our server.

mkdir server
cd server
touch index.js

Inside index.js let’s add a simple endpoint to fire up and test our server.

// index.js

import express from "express";

const app = express();

app.use(express.json());
app.use(express.urlencoded({ extended: false }));

app.get("/", (req, res) => {
  res.send("working fine");
});

const PORT = 3001;

app.listen(PORT, () => {
  console.log(`Server listening on port ${PORT}`);
});

To test it:

cd ../
npm start

Now, if you go to http://localhost:3001/ on your browser, you should see the “working fine” output.

Enabling Cors

We need to enable cors to allow React to send requests to Express.

Install cors:

npm i cors

And inside index.js

import cors from "cors"; // Add this to the list of imports

app.use(cors()); // Use the cors middleware

Using Environment Variables

To use environment variables, let’s install dotenv

npm i dotnev

Then create a .env file at the root of your project

touch .env

Open it and add the port

PORT=3001

Then in index.js import dotenv and access the PORT variable we just created.

import dotenv from "dotenv"; // Add to import list

dotenv.config(); // Configure dotenv to access the env variables

const PORT = process.env.PORT || 8080; // Use this instead of hardcoding it like before

Connect with React

Now that we have enabled cors, let’s test this by sending a request from React.

Go to the frontend folder and open up Header.js from components/layouts. Add the following useEffect hook. Note that this is just for testing purposes. You can get rid of it later.

useEffect(() => {
    const fetchData = async () => {
      try {
        const res = await fetch("http://localhost:3001");
        console.log(await res.text());
      } catch (e) {
        console.log(e);
      }
    };

    fetchData();
  }, []);

We are making a request to this http://localhost:3001 endpoint using the built-in fetch API and logging the response to the console. If you head over to your React app at http://localhost:3000/, you should see the “working fine” output in the console.

Dope! React can communicate with the backend now. However, what we want to do is prevent React from getting a response if a verified user token is not sent. We will do 2 things:

Send the Firebase token from the frontend to the backend
Create a middleware in Express to verify the token

Sending Firebase Token to Express

Again, open Header.js, and let’s modify the previous request to send the authentication token as a header Authorization: Bearer token. How can we get the token? Firebase makes this really easy.

// Header.js

import auth from "../../config/firebase";

useEffect(() => {
    const fetchData = async () => {
      try {
        const user = auth.currentUser;
        const token = user && (await user.getIdToken());

        const payloadHeader = {
          headers: {
            "Content-Type": "application/json",
            Authorization: `Bearer ${token}`,
          },
        };
        const res = await fetch("http://localhost:3001", payloadHeader);
        console.log(await res.text());
      } catch (e) {
        console.log(e);
      }
    };

    fetchData();
}, []);

First, we imported auth from our firebase config. We can use this to get the current user instance. getIdToken() returns the token if it has not expired or if it will not expire in the next five minutes. Otherwise, this will refresh the token and return a new one.

Now if you go to http://localhost:3000/ network tab, you can see the Authorization header being sent as well.

This is looking good. The next step is to verify the token in our backend.

Creating the Middleware

The middleware we are going to create will access the request to find the token. Then, we will verify it. How? Again, Firebase to the rescue! Firebase has a backend module that allows us to verify the token. Let’s install it.

Inside your root directory (where package.json and frontend folder are located):

npm i firebase-admin

According to the docs to use Firebase-admin SDK we need:

[x] A Firebase project.
[x] A Firebase Admin SDK service account to communicate with Firebase. This service account is created automatically when you create a Firebase project or add Firebase to a Google Cloud project.
[ ] A configuration file with your service account's credentials.

We have done the first 2. To get the service account go to your Firebase Dashboard and open Settings in the side panel. Then click the Service Accounts tab and click Generate New Private Key, then confirm by clicking Generate Key.

Once you download the JSON file containing the keys, go back to your project and navigate to the server folder. Create a folder called config and inside it, create a file called serviceAccountKey.json. This is where we will put the generated keys.

cd server
mkdir config
cd config
touch serviceAccountKey.json

After copy-pasting the keys into this file, create another file inside this config folder called firebase-config.js

touch firebase-config.js

Then open this file and,

//firebase-config.js

import { initializeApp, cert } from "firebase-admin/app";
import { getAuth } from "firebase-admin/auth";

import serviceAccountKey from "./serviceAccountKey.json" assert { type: "json" };

const app = initializeApp({
  credential: cert(serviceAccountKey),
});

const auth = getAuth(app);
export default auth;

We imported the JSON file with the Firebase configurations and used it to initialize the Firebase SDK. We then exported auth to use it elsewhere.

Next, inside the server folder, create a folder called middleware. Inside middleware, create a file called VerifyToken.js

Then, open VerifyToken.js and add the following:

// VerifyToken.js

import auth from "../config/firebase-config.js";

export const VerifyToken = async (req, res, next) => {
  const token = req.headers.authorization.split(" ")[1];

  try {
    const decodeValue = await auth.verifyIdToken(token);
    if (decodeValue) {
      req.user = decodeValue;
      return next();
    }
  } catch (e) {
    return res.json({ message: "Internal Error" });
  }
};

First, we imported the Firebase auth we created earlier.
const token = req.headers.authorization.split(" ")[1]; Here we are splitting the authorization header to get the token from the request.
auth.verifyIdToken(token); will decode the token to its associated user. Finally, we check if this decoded value is the same as the user sending the request.

Let’s now use this middleware in index.js


import { VerifyToken } from "./middlewares/VerifyToken.js";

app.use(VerifyToken); // Add this middleware

index.js will look like this:

// index.js

import express from "express";
import cors from "cors";
import dotenv from "dotenv";

import { VerifyToken } from "./middlewares/VerifyToken.js";

const app = express();

dotenv.config();

app.use(cors());
app.use(express.json());
app.use(express.urlencoded({ extended: false }));

app.use(VerifyToken);

const PORT = process.env.PORT || 8080;

app.get("/", (req, res) => {
  res.send("working fine");
});

app.listen(PORT, () => {
  console.log(`Server listening on port ${PORT}`);
});

Now, if you go back to http://localhost:3000/ and refresh, you will see “working fine” outputted on the console. However, if you replace the token with some random value or remove the header, Express will reject the request.

Perfect! Everything is working now.

Final Thoughts

Got lost somewhere throughout the process? No problem, check out the project on GitHub or ask your question in the comments section.

Feedback or comment? let me know down below. Thanks!

DEV Community: Hana Belay

Personal Finance Management App with Django, HTMX, Alpine, Tailwind, and Plaid

Features

Dependency Management with Poetry

Ruff and Pre-commit

Project Structure

Tests

The Frontend

Two-factor Authentication with AllAuth

Conclusion

Django Code Formatting and Linting Made Easy: A Step-by-Step Pre-commit Hook Tutorial

Table of Contents

Prerequisite

Configure a Django Project

Introduction to Pre-commit

Configure Black

Configure Isort

Configure Flake8

Bonus Tool: Djlint

Running Pre-Commit in Continuous Integration (CI)

Conclusion

From Problems to Solutions: Understanding Design Patterns

Why Design Patterns?

Elements of a Design Pattern

Types of Design Patterns

Introduction to Six Design Patterns

1. Singleton

2. Factory Method

3. Adapter

4. Decorator

5. Observer

6. Strategy

Conclusion

Reference

Elevate Your Django Projects with GraphQL Integration

Table of Contents

Prerequisite

Introduction

Project Configuration

Graphene-Django

GraphQL Schema

Load Data to the Database for Testing

Testing the Schema

GraphQL Mutation

Conclusion

Integrate Stripe Payments with Django By Building a Digital Products Selling App

Table of Contents

Prerequisite

Project Configuration

Building the Model

Setting Up the Views

Stripe Configuration

Stripe Checkout

Payment Confirmation Using WebHook

Give the Customer Access to the Product

Create Payment History

Conclusion

When to Use Functional Programming vs OOP

Object Oriented Programming

Functional Programming

Comparison

References

Build a Blog API With JWT Authentication Using Django Rest Framework

Table of Contents

Prerequisite

Project Configuration

Custom User Model in Django for Email-Based Auth

User Profile

JWT Authentication

User Registration and Login Endpoints

The Blog API

Build a ChatBot Using Python, Django

Table of Contents

Prerequisite

Project Configuration

WebSockets Using Django Channels

Tailwind CSS Configuration

Frontend - Create a WebSocket Connection

Enable a Channel Layer

Backend - WebSocket Consumers

`get_object(self)`

`get_queryset(self)`

`perform_create(self, serializer)`