Becoming an Enterprise Django Developer E-Book

Michael Dinder

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 581

Veröffentlichungsjahr: 2022

Beschreibung

Django is a powerful framework but choosing the right add-ons that match the scale and scope of your enterprise projects can be tricky. This book will help you explore the multifarious options available for enterprise Django development. Countless organizations are already using Django and more migrating to it, unleashing the power of Python with many different packages and dependencies, including AI technologies.
This practical guide will help you understand practices, blueprints, and design decisions to put Django to work the way you want it to. You’ll learn various ways in which data can be rendered onto a page and discover the power of Django for large-scale production applications. Starting with the basics of getting an enterprise project up and running, you'll get to grips with maintaining the project throughout its lifecycle while learning what the Django application lifecycle is.
By the end of this book, you'll have learned how to build and deploy a Django project to the web and implement various components into the site.

Leseprobe

Becoming an Enterprise Django Developer

Discover best practices, tooling, and solutions for writing and organizing Django applications in production

Michael Dinder

BIRMINGHAM—MUMBAI

Becoming an Enterprise Django Developer

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Publishing Product Manager: Pavan Ramchandani

Senior Editor: Mark Dsouza

Content Development Editor: Divya Vijayan

Technical Editor: Simran Udasi

Copy Editor: Safis Editing

Project Coordinator: Ajesh Devavaram

Proofreader: Safis Editing

Indexer: Manju Arasan

Production Designer: Shyam Sundar Korumilli

Marketing Coordinator: Anamika Singh and Marylou De Mello

First published: June 2022

Production reference: 1240622

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80107-363-9

www.packt.com

To my father, Joe Dinder, and uncle, Tom Dinder, who continuously encouraged me throughout the long journey of writing this book, I thank you very much. To my many other friends and family who supported me throughout this journey, thank you very much. To some of my colleagues, past and present, such as Micah Mangione and Adam Straub, and others who are not mentioned, who allowed me to interview them prior to writing this book, thank you for all the knowledge you shared with me. The knowledge they shared helped me to decide which content to include in this book. Thank you very much, everyone!

Contributors

About the author

Michael Dinder works as a senior backend developer at Cart.com, Inc. Michael has helped to develop projects for large enterprises such as PayPal and other companies such as Corcoran Pacific Properties, and countless more either directly or indirectly. He has been programming for more than 15 years with a number of different languages and frameworks, with a focus on Python/Django for the past 5+ years.

About the reviewer

Luca Bezerra has been working with software development for over 12 years across a very diverse set of technologies, be it professionally, as a hobby or during the course of his Master's degree. With experiences ranging from .NET to Unity3D to Python, Luca enjoys finding out about new technologies and the feeling of starting a project from scratch. He also loves to give talks, having presented on DjangoCon US, PyGotham, PyBay, Python Brasil and a few others over the years. Finally, Luca believes bios can sometimes make a paper plane sound like a fighter jet, so he suggests people should read them with a grain of salt.

Python and Django have always held a special place in my heart, so reviewing this book served a personal goal to keep in touch with these technologies. I also feel that the Python community has always been very welcoming and eager to help, so being able to contribute back to it in some way is very rewarding. I'd like to thank Packt for the opportunity and especially the people close to me for enduring my lack of availability during this project.

Table of Contents

Preface

Who this book is for

What this book covers

To get the most out of this book

Download the example code files

Code in Action

Download the color images

Conventions used

Get in touch

Share Your Thoughts

Part 1 – Starting a Project

Chapter 1: Undertaking a Colossal Project

Technical requirements

Building an enterprise

Reasons to choose enterprise-level applications

Types of enterprise systems

Why Python/Django?

Types of APIs

Designing and planning

Requirements gathering

Visualization and interpretation

Hosting and deployment

Creating and configuring a Heroku plan

Configuring Heroku environments

Custom repositories

Advanced deployment

Domain Name System

Summary

Chapter 2: Project Configuration

Technical requirements

Choosing development tools

Text editors

Integrated development environments

Starting a project

Using the IDE

Using the command line

Creating a virtual environment

Configuring the requirements.txt file(s)

Using the IDE

Using the command line

Project configuration

Django settings.py file

Creating an environment file

Creating a Procfile

Django static files

Django media files

Creating a .gitignore file

Creating a Django app

Using basic database settings

SQLite

MySQL

MariaDB

Oracle

SQL Server

PostgreSQL

Preparing PostgreSQL for Heroku

Installing PostgreSQL

Using the PgAdmin tool

Environment connection settings

Building initial table structures

Remote data migrations

Heroku database push/pull operations

Summary

Chapter 3: Models, Relations, and Inheritance

Technical requirements

Preparing for this chapter

Writing model classes

Standard field types

Third-party field types

Model field validators

Working with model field relationships

Field arguments

Field type – ForeignKey

Field type – ManyToManyField

Mutable versus immutable objects

Using the Meta subclass

Meta options – verbose_name and verbose_name_plural

Meta option – ordering

Meta option – indexes

Meta option – db_table

Customizing models

Writing methods

Decorators

Extending models

Extending basic model classes

Extending the Django User model

Using the Django shell

Running basic Python scripts

Generating a SECRET_KEY variable

Saving data

Loading the chapter_3 data fixture

Performing queries

Model method – all()

Model method – get()

Model method – filter()

Aggregates

Writing model managers

Summary

Part 2 – Django Components

Chapter 4: URLs, Views, and Templates

Technical requirements

Preparing for this chapter

Configuring URL patterns

Basic path functions

Redirecting patterns

Using path converters

Mapping URL patterns

Using simple views

Using kwargs in views

Working with conditional responses

Linking models to views and templates

Resolving URLs

Naming URL patterns

Using the reverse() function

Using the {% url %} template tag

Processing trailing slashes

Resolving absolute URLs

Creating a context processor

From the request object

From within a model class

Working with complex views

Class-based views

Extending class-based views

Asynchronous views

Working with templates

Template tags

Template filters

Custom tags and filters

Error page templates

Summary

Chapter 5: Django Forms

Technical requirements

Preparing for this chapter

Types of forms

Form class – Form

Form class – ModelForm

Using form fields

Common field arguments

Field widgets

Field validators

Cleaning forms

Method – clean_{{ your_field_name }}()

Method – clean()

Creating custom form fields

Field class – Field

Using a custom field

Working with form views

View class – FormView

HTTP request methods

Rendering forms in templates

Render form – as_p

Render form – as_table

Render form – as_ul

Render form – using template_name

Render demo

Linking a model to a form

View class – CreateView

View class – UpdateView

Adding inline formsets

Formset function – formset_factory

Using inline formsets in the view class

Rendering inline formsets in the template

Dynamic inline formsets

Summary

Chapter 6: Exploring the Django Admin Site

Technical requirements

Preparing for this chapter

Using the Django admin site

Activating the Django admin site

Logging into the Django admin site

Writing admin classes

Registering models

Configuring admin class options

Changelist view-related options

Change/add view-related options

Add view-related options

Adding admin class methods

Method – get_form()

Method – save_model()

Method – delete_model()

Writing custom admin form classes

Initializing an admin form

Using the Django authentication system

Adding a seller

Granting permissions

Permission groups

Summary

Chapter 7: Working with Messages, Email Notifications, and PDF Reports

Technical requirements

Preparing for this chapter

Creating a Mailtrap account

Using the Django messages framework

Enabling the Django messages framework

Creating a message

Displaying messages

Configuring email notifications

As plain text emails

As HTML emails

As HTML emails with a plain text alternative

With file attachments

That fail silently

Writing custom email templates

For plain text emails

For HTML emails

Providing template context

Generating PDF reports

As template-based PDFs

Adding context

Summary

Part 3 – Advanced Django Components

Chapter 8: Working with the Django REST Framework

Technical requirements

Preparing for this chapter

Installing the Django REST framework

Serializing objects

The serializer classes

The viewset classes

Using URL routers

Using the Browsable API

Building SPA-like pages

Creating the view

Building the template

Writing the JavaScript

Mapping the URL pattern

First demo

Writing custom API endpoints

Creating the view

Building the template

Modifying the JavaScript

Mapping the URL pattern

Second demo

Authenticating with tokens

Project configuration

Creating the view

Building the template

Modifying the JavaScript

Mapping the URL pattern

Third demo

Summary

Chapter 9: Django Testing

Technical requirements

Preparing for this chapter

Understanding automated testing in Django

Getting started with unit testing

Basic unit test script

Testing Django models

Testing HTTP view requests

Testing method-based views

Testing class-based views

Testing authenticated view requests

Using the Client() class

Testing Django REST API endpoints

Creating an object test case

Updating an object test case

Using the DjDT

Installing the DjDT

How to use the DjDT

Summary

Chapter 10: Database Management

Technical requirements

Preparing for this chapter

Exporting data into a data fixture

Using the dumpdata command

Importing data from a data fixture

Using the importdata command

Using the select_related() method

Creating the view

Building the template

Mapping the URL pattern

First demo

Using the prefetch_related() method

Vehicles view

Sellers view

Using the Prefetch() class

Modifying the view

Modifying the template

Fourth demo

Summary

Why subscribe?

Other Books You May Enjoy

Share Your Thoughts

Preface

Django, a backend framework with frontend tools built in, is designed to help developers build apps quickly and easily. It is designed to take much of the hassle out of web development so that developers can focus more on the features they are building and not the problems they are facing. Loaded with dozens of tools and combined with countless third-party Python packages, Django provides many features and components that work right out of the box.

The Django framework has been built with scalability and versatility in mind. As demand and traffic grow, so can your project. This allows developers to build onto an existing system easily. Security is also something that Django takes seriously by building many different security measures directly into its framework. This has been done to help developers avoid common mistakes when it comes to security. It even has its own user authentication system to help manage your users.

In this book, we will learn about the fundamental components of the Django framework and how it relates to web development. From small websites to large, enterprise-level applications, this book will dive in and discuss the essential components for building a website or app of any size.

Who this book is for

This book focuses on full-stack enterprise-level application development. If you are looking to build a web app, API, or website or maintain an existing project, this book is for you. The book assumes intermediate-level knowledge of the Python programming language and it has been carefully fine-tuned for those who are new to the Django framework. Whether you are new to web development or have years of experience working with other technologies, this book is for you.

What this book covers

Chapter 1, Undertaking a Colossal Project, gives you an understanding of how to prepare for a large project.

Chapter 2, Project Configuration, covers virtual environments, hosting, and deployment.

Chapter 3, Models, Relations, and Inheritance, covers database table structures.

Chapter 4, URLs, Views, and Templates, covers rendering HTML with Django.

Chapter 5, Django Forms, covers rendering HTML forms with Django.

Chapter 6, Exploring the Django Admin Site, looks at Django's built-in administration site.

Chapter 7, Working with Messages, Email Notifications, and PDF Reports, covers using Django to send emails and create documents.

Chapter 8, Working with the Django REST Framework, covers building APIs with Django.

Chapter 9, Django Testing, covers writing test scripts with Django.

Chapter 10, Database Management, covers optimizing database queries.

To get the most out of this book

You will need the latest version of Python. All code examples in this book have been tested using Python version 3.9 on Windows 11 using Django 4.0. However, they should work with future version releases as well.

Each chapter will provide additional installation and configuration instructions as the book progresses, such as in Chapter 2, Project Configuration, when we install an optional integrated development environment software suite, or in Chapter 9, Django Testing, when we install a productivity and testing tool.

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book's GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Becoming-an-Enterprise-Django-Developer. If there's an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

The code provided in this book's GitHub repository includes every example from every chapter. Much of the code is commented out except for the first exercise found in each chapter. If you are using the code provided with this book, it is intended to comment and uncomment code as you progress throughout the book. If you jump ahead, you may need to uncomment the necessary code that was skipped in order for the project to work. Each chapter has been organized into its own chapter app within the project as a whole. Project apps will be introduced and discussed in Chapter 2, Project Configuration.

Code in Action

The Code in Action videos for this book can be viewed at https://bit.ly/3HQDP9Z.

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781801073639_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Be sure to also include this app in your INSTALLED_APPS variable found in the settings.py file."

A block of code is set as follows:

# /becoming_a_django_entdev/chapter_5/forms.py from django.forms import Form class ContactForm(Form):     pass

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

# /becoming_a_django_entdev/chapter_5/forms.py from django.forms import Form, ModelForm class VehicleForm(ModelForm):     pass

Any command-line input or output is written as follows:

RuntimeError: Conflicting 'vehicle' models in application 'chapter_3':

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: " We can see the chapter_3_engine and chapter_3_practice_engine tables in the preceding screenshot."

Tips or Important Notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Author: If you would like to get in touch with the author directly, you may find and message him on LinkedIn here https://www.linkedin.com/in/mikedinder/.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you've read Becoming an Enterprise Django Developer, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Part 1 – Starting a Project

In this part, you will begin by learning what enterprise development is, understanding the requirements gathering process, and creating a free hosting plan with Heroku. You will create a local, development, staging, and production environment for the code to live and run in. You will then create a Django project and push that code to those environments.

We will discuss configuring the project files and settings to work with a Heroku-hosted app. We will also create and configure a database to work with the project we are building. Then, we will build models that relate to the tables within that database. Heroku is not necessary for the rest of the book. The majority of this book can run locally on your machine.

This part comprises the following chapters:

Chapter 1, Undertaking a Colossal ProjectChapter 2, Project ConfigurationChapter 3, Models, Relations, and Inheritance

Chapter 1: Undertaking a Colossal Project

Considering the increasing complexity of applications and websites these days, this chapter will introduce you to what it takes to tackle a colossal project of your own. We will explore the concepts of enterprise-level development, and then take a peek at the many different paths we could take. We will discuss methods and tools that help us to draft plans for a project, essentially building the blueprints that we will need to get started. Every project also needs hardware for its software to live on, so we will be exploring what service options are available to provide the hardware we need. Of the options provided, we will settle upon one choice for a hosting provider and demonstrate working with that provider throughout this book.

The project itself can be used with any hosting provider or even run on a self-built server; however, keep in mind that certain settings may be configured specifically for the host that we will be using. By the end of this chapter, we will have created a hosting account with the provider chosen and picked the simplest, free plan for use with this book. We will also be creating and configuring multiple working environments on that hosting plan for the code to run in. We will also connect each environment in that hosting plan to a remote repository, keeping the code in a safe place.

In this chapter, we will be covering the following topics:

Building an enterpriseDesigning and planningHosting and deployment

Most people would suggest using a UNIX- or Linux-based operating system, such as Ubuntu or macOS, when working with Django. Django is built to be so versatile that the concepts and code examples that will be demonstrated throughout the course of this book can run on all three major platforms (Windows, Mac, and Linux) and beyond. Personally, I have been using Django on a Windows-based machine ever since I started to learn and work directly with this framework. I did so because I came from a Windows background; about half of my jobs provided the equipment or mandated the use of certain software on a Windows-based machine. Later on, more and more companies started to give developers the choice to work on whatever machine they were most comfortable with. I continued to choose Windows because I was already familiar with it.

Technical requirements

Whether you are using a Windows, Mac, or Ubuntu system, Python will need to be installed. Python version 3.9.0 is the latest version available at the time of writing this book. It is highly likely that this code will still work with future versions of Python but there is no guarantee that all of the code will continue to work and there could be some hiccups in future versions. You can find the Python installation files for all platforms on their website here: https://www.python.org/downloads/. For non-Windows users, the most straightforward way of installing Python is with Homebrew, which creates for you a symlink to the package that you installed.

For Windows users, an easy way to install Python is through the Microsoft Store. Search for Python and select 3.9 from the list. During installation, if you see the Add Python to Environment Variables option, select the checkbox to include it! This sets a path to your global library of Python packages/libraries on your development machine. These are different from the packages that are included in your project, which we will discuss in Chapter 2, Project Configuration.

A command-line tool is needed to execute commands that interact with and use Django. PowerShell is a common command-line shell that comes standard in Windows today. This command-line utility comes packed with some of the coolest features from an assortment of other existing shells, all merged into one. It is also available on the Mac and Linux operating systems. However, iTerm2, or the built-in Terminal app, is what most developers tend to gravitate toward using. Regardless, PowerShell has become a popular tool used by many developers for automating the management of various systems today.

You will also need to install the PIP Python Package Manager, if it was not already installed during your Python installation. Starting with Python 3.4 and after, pip is included by default with the Python binary installers; thus, it is likely it was already installed on your machine. If Python was installed using Homebrew, then pip is not included, and you will need to install it separately. Install pip via the official installation guide found here: https://pip.pypa.io/en/stable/installation/. Since this is a package manager, it is likely that any version of pip in the future will continue to work with the rest of the code and concepts discussed in this book. However, not every third-party package discussed in this book is guaranteed to be supported in the future by that provider. Regardless, the concepts of using a third-party package and how they would be configured and used in a project are taught in this book and can be used to find a package of your own.

Tip

Whatever operating system you are working on, if you get an error message while working with any command throughout this book, such as pip/python is not recognized as an internal or external command, it means that you need to configure environment variables on your system to point to the corresponding file directories. To manually configure your environment variables in any of the three major platforms, visit these links:

• Windows: https://phoenixnap.com/kb/windows-set-environment-variable

• macOS: https://phoenixnap.com/kb/set-environment-variable-mac

• Ubuntu: https://help.ubuntu.com/community/EnvironmentVariables

If a command is not recognized as an internal or external command, you may need to add the path to where that item was installed on your machine. In Windows, this is commonly the Path variable. For example, if python is not recognized as a command, add the path to where Python was installed on your machine to your global Path variable in Windows. The same applies to Linux or Mac but is most commonly a problem on Windows.

All of the code created and used in this book can be found here: https://github.com/PacktPublishing/Becoming-an-Enterprise-Django-Developer. This chapter doesn't actually dive into any code at this time. However, for those of you who are already familiar with Django or are new to Django who have already read through Chapter 2, Project Configuration, and come back to this chapter, an app called chapter_1 is included with the code of this book to demonstrate a diagramming package introduced in the subsection titled Entity relationship diagrams of this chapter.

Check out the following video to see the Code in Action: https://bit.ly/3OfagBj.

Building an enterprise

Building an Enterprise Application Software (EAS) is not an easy task to tackle. The task requires many different technical specialists all working together with a high level of collaboration and preplanning to complete. Failure to perform adequate planning can result in the project taking far more time and money than anticipated. Important features that your business model relies on could be left out of the equation, resulting in disruptions in everyday flow when a new system turns on.

Enterprise-level software is geared toward satisfying the needs of a business as a whole. EAS takes all of the business logic of an organization and encompasses that into one system, thought of as a collection of many smaller subsystems. The software eliminates the need for paperwork, reduces the steps involved in completing a task, and provides self-automated or even artificially intelligent solutions to all kinds of problems in the world today. The website itself is only a small fraction of what the entire system actually comprises.

Reasons to choose enterprise-level applications

Enterprise-level software is usually thought of as a solution for organizations that already have a system in place and need to improve upon that. Whether or not that system is something digital or a manual process, as in paper in filing cabinets, companies are always searching for ways to simplify everyday tasks. Thus, enterprise-level software can consist of one or a collection of many different consumer-level applications. If you need more than just a website and need a system that also takes on your business management tasks, you will likely need to scale up to the enterprise level. However, Django can still be used for the simplest of websites as well as large-scale projects beyond your wildest dreams. Applications can also be broken down into individual Django projects.

Let's say you have an organization with many departments and many users, all consisting of different permission roles. You need a way to connect them all so that they may generate and share reports, send notifications, store and manage customer/user data, create invoices, and work with other systems. Maybe you found that your organization needs to connect employees working remotely from home to be more productive and efficient at their job. The idea is that each user type will interact with the system in a completely different way and even have different permission levels granting them access to different parts of your system.

Generally speaking, when someone thinks enterprise level, they also think of something that is unique and custom crafted. Such software is termed proprietary or closed-source software and is not intended to be redistributed to the public by any means. However, not all EAS has to be proprietary; the distribution license can be set to anything you desire it to be. For example, the main system may be branded for one parent company and yet parts of the system may be branded for its subsidiaries, or copies can be distributed and rebranded per your license agreement. It may also be a good idea to speak with a technical lawyer to help write your software license agreement should your project(s) be extremely complex. Inviting the help of a technical lawyer at the beginning is a good way to prevent lawsuits later on.

Next, we will discuss some of the major types of enterprise systems.

Types of enterprise systems

There are many different kinds of enterprise-level systems but we can consolidate them into six major categories, as follows:

Customer Relationship Management (CRM)Enterprise Content Management (ECM)Enterprise Asset Management (EAM)Enterprise Resource Planning (ERP)Supply Chain Management (SCM)Enterprise Information System (EIS)

In this book, we will not actually be building any of these systems in their entirety. Instead, we will touch on the key Django programming concepts that, when combined, will get you part of the way to the end zone. Not every concept can fit into this book but Django is fully capable of handling all of the features that each of these types of systems includes. It is really up to your team to take on each of the rest of the concepts discussed in this book and use them as another tool in your toolbox when building your system. Let's discuss briefly what each of these six major types of enterprise-level systems is and what they are primarily used for.

Customer Relationship Management

CRM systems can typically be thought of as lead management, marketing communications, sales and inventory control, retail management, and so much more. The systems can be thought of as everything but the actual selling of products and services. They can even go further to include customer support and data analytics. These systems are designed to develop better relationships with your business partners, customers and potential customers, and anyone else in the equation.

Enterprise Content Management

An ECM system can best be described as a system for people working in fields that deal with creative and other intellectual property in some kind of way. Newspapers, magazines, and other news companies today have a great deal of content that they make available to the internet on a daily basis. A Content Management System (CMS) provides a less technical and rapid way to build new pages and enter that content onto the web. Enterprise level just means you are adding more and more tools to your toolbox for your organization to use.

Enterprise Asset Management

In an EAM system, products and inventory of all kinds can be entered into a system in the same way as a CMS. This is often known as an e-commerce or shopping cart website. It's where you make your physical goods and assets available online. These systems allow the tracking of inventory, project management, and document control, such as contracts and other legal documents. These systems may even consist of physical assets, such as real estate, automobiles, and music records.

Enterprise Resource Planning

An ERP system is typically thought of as a way to manage people, the employees of the company, or what is commonly known as the Human Resources (HR) department. The system can handle on-boarding and off-boarding procedures and store all personnel records. It could serve as a tool for project management, risk assessment, and record keeping. It can even serve as a knowledge base such as in the form of the Frequently Asked Questions (FAQs) area. A knowledge base is often used to point people to and have them find common questions and answers in order to reduce the workload on your staff. These can also be used for training purposes, such as generating quizzes or asking trivia questions and playing tutorials.

Supply Chain Management

SCM systems are similar to CRM and EAM systems. These are systems that manage inventory in every aspect of its development in the supply chain. These systems manage inventory on a national or even a global scale. They communicate with suppliers, connect to buyers, track packages, predict future supply orders, and may even automatically place those orders. One way to look at the difference between a CRM and SCM system is that a CRM is mostly used for sales and marketing while an SCM is mostly used for production and distribution. Both deal with products but in different ways and a large company or a conglomerate would need both.

Enterprise Information System

An EIS is a system that generally combines a CRM and SCM system to handle a wider range of business needs. An EIS may even integrate some or all of an ERP system and act as one giant central nervous system. Depending on the needs, this may consist of numerous databases and even numerous development projects all working together, comprising the brains of everything. These systems are known for storing and processing large volumes of data and connecting many different systems all together into one.

We will now take a look at why people gravitate toward using Python and Django when they are building any of these enterprise-level systems. We'll see why it suits a variety of projects and what features it is best known for.

Why Python/Django?

Python was created in 1991 by Guido van Rossum. He came up with the name Python after reading the script for Monty Python's Flying Circus. The language was created primarily for the purpose of code readability and reliability. Python has been growing in popularity as the preferred backend framework for several years now. Python plays an important role in some very popular websites today, such as Google, NASA, Netflix, Spotify, Uber, and Dropbox, just to name a few. The Python language has become desirable among many developers for its ease of use, quickness to learn, and overall adaptability of the code written.

Django came into existence in late 2003 by the newspaper publisher Lawrence Journal-World in Lawrence, Kansas. Similar to Python, it had one goal in mind: to create complex database-driven websites in a simple and easy-to-read way. Along with readability, it was designed with rapid development and a Don't Repeat Yourself (DRY) code structure in mind. Readability is why Python was chosen as Django's foundation for the framework. Django is best referred to as a backend framework because of how it works to build and manage databases. It comes with many concepts built in surrounding the architecture of websites, which makes it appealing to most web developers.

Many people use Django today for their backend; but the framework can also serve as your frontend. If you have ever used Shopify's Liquid template language, otherwise known as Liquid syntax, or even ASP.NET's Razor syntax and how that is used in conjunction with C# .NET or Visual Basic .NET, you will notice commonalities with the Django template language, which is Django's method of using Python to build HTML files. Django uses context when the page is rendered to serve up user-generated content or database-driven data onto that page. The template language syntax is fairly easy to read and quick to learn. Some examples of sites that use Django are Bitbucket, Instagram, National Geographic, Spotify, The Washington Post, and YouTube.

Django's features include the following:

Caching frameworkData serializationExtensibilityForm handling and validationScalabilitySecurityTemplate languageTesting framework

Of these features, extensibility means that Django is built to allow easy integration of other third-party services. Your developers can spend more time focusing on the specific needs of the project versus trying to figure out how to connect your project to a third-party servicer's system. Django makes it easy to connect to virtually anything that exists today. If a functionality doesn't already come built in, there is usually a pip package for it.

Django does not need to be used to build only websites. It can be used to build an API that stands as the central hub for anything, communicating with a REpresentational State Transfer (REST) framework, which is a common architecture for standardizing communication between computer systems on the internet. From here, you can use any variety of common existing tools to build an iOS app for iPhones or even Android apps. Depending on your particular business requirements, deciding to tap into smartphones can be beneficial in many ways. With somewhere around 85% of Americans owning a smartphone today, some companies might want to build an app where a user can install that app on their personal phone (https://www.pewresearch.org/internet/fact-sheet/mobile/), versus the company having to purchase additional hardware to distribute devices to all of their employees. APIs can be used for many other things as well, from microservices to large-scale external web systems and databases.

Personally, when it comes to using the Django template language and a JavaScript-based framework such as React or Angular together, I would recommend against doing that as it can get far too complex to work with. If you are using React, Angular, Vue.js, or Handlebars.js, to name a few, to work as your frontend, then Django would just serve as your backend where context is served up through your API. You can still keep your frontend and backend files in the same Django project folder.

I have a few recommendations to help you choose. If you want to build an Android or iOS app or a Single-Page App (SPA) website, use Django as an API on the backend. Then, for the frontend, you can use a common JavaScript-based framework to build mobile apps. For multipage websites, just use the Django template language along with your context to work as your frontend. There are ways to build an SPA website without the use of React or Angular and just rely on Django alone, but even then, you will still need something such as jQuery, AJAX, or vanilla JavaScript to help you process triggers and events that send requests to your API. I often resort to preloading my base .html file with jQuery, which I will discuss how to do in Chapter 4, URLs, Views, and Templates. Many people prefer to use vanilla JavaScript so that they can write simple tasks without loading the entire jQuery library. When it comes to adding bells and whistles on the frontend of things, in all of the projects that I have worked on, I find that I can pretty much do everything that I need to do with just the Django template language and jQuery. I may be biased on this one but it is really simple to use. However, there are a lot of benefits of using ECMAScript, which is actually a set of international standards for building and compiling JavaScript, such as ES8, ES9, or ES10. Using ECMAScript is something I should be focusing on more in my projects.

Tip

When working with Django and Python, ask your developers to adopt the Python Enhancement Proposal 8 (PEP-8) style guide for Python code. This is an officially adopted formatting guide to keep code consistent among developers. This can be strict or relaxed. Personally, I like to choose a more relaxed version where I can make things a bit more broken down and readable. If you are building something proprietary, for internal use, it is not necessary to follow this exactly and you may prefer to choose a style that your team will be happy with. If you are building a package that will be shared publicly with anyone, I would recommend you follow the PEP-8 format exactly. It may actually be a requirement for submitting a package to the Python Package Index (PyPI) library. You can find out more about the official style guide here: https://www.python.org/dev/peps/pep-0008/.

PyPI is the official repository for third-party Python package libraries both public and private. It's a wonderful resource when looking for new packages to play around with and it provides information on how to work with the code as well: https://pypi.org/.

A package called Black can be used as a code linter to help developers make sure they are following PEP-8 style formatting. You can learn about Black here: https://pypi.org/project/black/.

Next, let's explore what the different types of Application Programming Interface (API) are and why we might need to know about these when planning for a project.

Types of APIs

An API is a means for two systems to communicate with each other through what are known as endpoints or a URL.

We can categorize APIs into three main categories:

Figure 1.1 – Types of APIs

In the following sections, we will discuss what each of these API types is and what they are used for. Depending on the requirements of the project, we may need to choose one or the other as a type of system that we want to build.

Open APIs

Open APIs are open to the public and are sometimes referred to as an external API. This typically means there are no restrictions and anyone can be granted access. Sometimes, a simple registration or API key may be required before developers can gain access but they usually have the freedom to do with it as they wish. These APIs can be open bidirectionally as well, meaning the system is open for all GET, POST, PUT, PATCH, and DELETE requests coming to and from your system.

Partner APIs

Partner APIs are commonly found in business-to-business relationships. The general public cannot gain access and permission is only granted to strategic partners who need to use your API in order to do business with you. Limitations can be defined depending on your agreements with each party. These are fairly common in the world today when business mergers occur and your team is tasked with making two external systems communicate with each other. Sometimes, you have to build a central database in between the two existing systems for various reasons, such as your business model is based on granting access to your API in order for companies to sell their goods on your platform. A common example of this is the Amazon Selling Partner API (SP-API), which is used for selling goods on the Amazon Marketplace.

Private APIs

Private APIs are the most secure; these APIs are locked down because they are intended to be used internally by that company or organization only. Large financial institutions or corporate retail entities may use these to manage any aspect of their internal functions. The public and any other external sources may not be granted access unless a specific need for it is warranted. Common examples are government organizations using APIs to connect to systems that keep legal records and documents. Another example could be a university granting an educational department access to student and class records.

By now, we have brushed up on what enterprise-level software is, in terms of what types of enterprise-level systems exist today and how we can classify them. We also discussed how Python and Django play a role in enterprise-level software. Now that we have learned about these various concepts, let's begin designing and planning for a project of our own.

Designing and planning

Every project, however big or small, needs a clear plan for what it is and how it will be built. The larger the project, the more work should be put into the beginning phase of preparing for development. It is no surprise that enterprise-level development should also require a great deal of preliminary work before actual development begins. Whether you are working for a company or are a company providing a solution to a client, you should have a clear plan of what needs to be done. There is a lot of flexibility here based on factors such as cost, lack of developers, and deadlines. Prepare as much as possible and try to stick to the timelines that are set to keep you on track to completion. Remember that too little planning could come back to haunt you later.

Developers should be given as much information as possible to help them understand what they are building. If your developers are not provided with enough documentation, blueprints, and other materials, then they will be left to make assumptions on their own, assumptions that later on are found in the testing and Quality Assurance (QA) phases of development as bugs in your application. When this happens, you may discover that a particular feature needs to be rebuilt, requiring major foundational changes that will take a great deal of time to refactor. If we think about something other than programming for a moment, such as building a house, we all know a foundation needs to be built before a team can frame the house. In turn, that foundation needs to be completed before a team can build the roof, wire up the electrics, install plumbing, and so on. You can't start building a roof without a frame, and you can't build a frame without a foundation to put it on.

Let's discuss how to gather requirements for your project.

Requirements gathering

Gathering requirements is important to help document the build process and to allow both parties, the developer and the owner of the software, to reference it at any time during development. This ability is essential in order to ensure things stay on track until completion and are also completed on time. There should be an initial brainstorming phase to get a feel for the scope of the project. One good trick is to have all the stakeholders get together and debate the needs of the system, while you record any key points raised during the debate and include them in your requirements findings. You should always start by asking questions, and you should ask alternate questions for different sets of people. After you have spoken to stakeholders, move on to directors, project managers, developers, and employees, known as end users. Interview as many different types of users as possible. For extremely large entities, you could create a questionnaire, distribute that questionnaire to a number of users, and then come to a conclusion based on the results.

If there is a legacy system currently in place, even if it's a manual versus digital process of some kind, you should try and get a feel for how it works and identify any pain points within that process. My favorite tactic is User Observation, where I watch a user as they go through the flow of an everyday task and then try to identify things that may slow them down. The next thing I would do is try Role Playing , which is a method where you jump in and use the system as a user would perform a task. You could also ask two different kinds of users to swap positions and ask them what was easy or hard about doing the other person's task or what they think could improve the workflow. There must be bottlenecks of some kind or else there wouldn't be a need to build something better. These are things that bog down your everyday tasks and end up costing the company a lot of money in terms of time and resources. You need to keep an eye open and identify the pain points that your client could not identify themselves or they will have a difficult time communicating with you. Your client won't always know the best solution to a problem, and they may not even know a particular problem is even a problem until you reveal a way to improve that process for them.

Research and discovery

Find out whether this will be an internal, partner, or public project. If it is a partner project, you may have certain limitations based on the partner's specific needs. This is when we get into the difference between business requirements and functional requirements. Functional requirements are things such as determining what hosting plan and server to live on, a backend framework, a frontend framework, and a set of pages. Business requirements, on the other hand, encompass the vision, goals, and objectives of the business as a whole. They are specific to the needs of the organization or the partners they are working with. The structure of a set of web pages or API endpoints may be defined by the business model of that company versus some other logical reason that may otherwise be chosen. Do your stakeholders have any goals, suggestions, or requests that you need to consider? Here are 15 common questions that can help you formulate your set of questions. You shouldn't limit yourself to just these questions alone; use them for brainstorming:

Do you have business-specific requirements?Why do you need a new system?What does your current system prevent you from doing; are there any bottlenecks?What new features would you like to add; do you need any improvements?What old features would you like to keep or remove?Who will you interact with in the system; what types of users and roles?Will you need reporting, email messaging, or any other kind of notification system?Will the system connect with any third-party or partner systems in any way?What kind of traffic or load on the server are we predicting?When does this new system need to be operational?What kind of budget have you allocated toward completing this project?Will data need to be migrated from the old system to the new system?How will development be divided up among the development team members?What skills does the development team have; what are the team's strengths and weaknesses?How should the User Interface (UI) flow work; should it be multipage or single page?

Decision making

From the common questions listed previously, you can formulate dozens, if not hundreds, of other questions to fit your unique set of needs. Then, these questions can be grouped into several categories of development, each category with a unique set of requirements and guidelines. You will want to focus heavily on usability, data migration, performance, security, scalability, and reliability. It's good to know this information beforehand so that you can choose the best direction that your development should move forward with.

These will be decisions such as what frontend framework you will choose, who you will go to for hosting, whether you will be building your own servers or renting space at a data center in the cloud, and how your server will be configured. There are countless possibilities to consider. When it comes to the UI, there is a number of questions that need to be asked regarding form field layout, form field validation (server side and client side or both), placeholders, labeling placement, and the flow from start to finish. Flow here refers to whether the user should complete part or all of a form before proceeding and/or whether those parts should be included in a separate form.

Keep in mind that when it comes to form field validation, Django will only validate your data on the server side. Your project does not need both server- and client-side form field validation. However, a healthy website will implement both. So, when a postback error occurs, anomalies will emerge, such as not displaying your form or the field errors that are present, if your form is not visible when the page first loads, for example, when a user needs to scroll down really far on the page or perform several actions before the form becomes visible to the user. Client-side form field validation solves this problem by checking for data to be valid before it is sent to the server, known as data integrity. This validation also reduces work for the server to process and provides for event handling, letting you write functions to help you format HTML and CSS on your page. When it comes to decision making, you can choose whether or not field validation will take place on the client side or the server side, or both. If client-side validation will take place, then you can choose what tools will be used, which are usually JavaScript based.

For example, take input attributes such as required, minlength, and maxlength, which can exist in your HTML. These are usually generated by Django when rendering form fields that have specific field arguments set, such as the following example. We will discuss rendering forms in detail in Chapter 5, Django Forms:

# Demo Code <input type="text" name="field" id="field-id" class="form-input" maxlength="150"minlength="5"required="">

Most browsers will natively restrict a user from submitting a form if these attributes are present and the data does not satisfy them. All browsers will handle and style these error states differently from one another as well, like Mac versus Windows or Chrome versus Safari. The reason for this is that they are developed by separate entities competing against each other in the market and as a result have different branding. This difference hinders the ability of Django to serve up a postback displaying the error message that was defined in your code for that field. If for some reason the user is able to submit a form with invalid data, the postback may not display the form if, as I mentioned previously, the form is hidden from sight on page load. This is why your project may require both client- and server-side form validation.

Handling error state messages between your server-side code where you define your form fields and your client-side implementation can be tricky as well, meaning you have to store the same error message in two different locations within your source code: one for server-side validation and one for client-side validation. Over time, and with many different developers, this will get very messy, especially when someone remembers to change one but not the other when edits, additions, or deletions are made to these messages. If you have a strict need to make sure they are both worded exactly the same, it might be necessary to create a data dictionary that your source files could access, allowing you to put all your error messages in one spot. How you do that will take some thinking. This file will also need to be accessible via both Python and JavaScript.

Visualization and interpretation

When it comes to the actual design of how the UI will look, there is a number of factors involved. Large corporations may have specific branding guidelines that they mandate for marketing and other legal reasons that can restrict the overall design of your frontend. Sometimes, these corporations will have an in-house creative and marketing department or they may outsource to a third-party creative company to mock up a set of Illustrator or Photoshop documents to assist your frontend developers in doing their jobs. For smaller projects, you are free to design something yourself, but that often takes up time and developers often experience a type of writer's block when tasked with actually designing something versus building something.

One big misconception about frontend developers is that everyone automatically assumes they are designers, which is not always the case. Similar to how a construction worker reads blueprints to build a house, someone else usually drafts the blueprints for them. For this reason, you can use open source templates and boilerplates in the form of HTML, CSS/SCSS, or even JavaScript from online suppliers such as Envato Market, formerly known as ThemeForest (https://themeforest.net/), or Nicepage (https://nicepage.com/html-templates). I have resorted to using design templates from sources such as these in my own Django projects before. Each of these templates and template providers is different. Some are free, while others can be used for a price, and usage licenses vary. Independent research will have to be done on your part before deciding whether any of these sources can work for you. These design templates may also require a bit of digging around in order to make sure they fit in your project nicely, but they can still save a lot of time and provide a stylish-looking site that may be far better than what someone who lacks a creative eye for designing something from nothing could create for you.

Many of these HTML, CSS, and JavaScript templates may resort to the use of the Node Package Manager (NPM) for you to build source files into production-ready files. Similar to PyPI, NPM is used to store and distribute JavaScript libraries that are used in development. They rely on Node.js to run them. There are even pip packages that you can use within your Django project to help you build source files using an NPM package. I will discuss managing pip packages and dependencies further in Chapter 2, Project Configuration. There is a number of Python packages that can help you transpile SCSS, auto-prefix, bundle, and minify files. I have played around with a lot of different Python packages and out of them, I have found only a select few resorting to the use of NPM to do the heavy lifting at the end of the day. This means, as a requirement for your project, your developers may need to have NPM installed on their machine or even on their server depending on how you want to use Node.js. For the examples in this book, I will gravitate toward Python packages as much as possible and you are free to integrate these into your project as you see fit. I'll try to avoid going into code examples pertaining to NPM packages, but I encourage you to use the packages in your development environments.

Tip

The latest and most stable version of Node.js and NPM can be found here: https://nodejs.org/en/download/. For Windows users, there is an easy-to-use installer file that will install both Node.js and NPM for you.

You can find the Gulp installation guide here: https://gulpjs.com/docs/en/getting-started/quick-start/. Gulp requires that the Gulp Command-Line Utility (CLI) is installed first, then install Gulp itself. Gulp is considered a task runner and helps to automate a vast majority of development tasks, such as SCSS transpiling, CSS linting, vendor prefixing, minification, and bundling; ECMAScript compiling; and other code linting.

Designing doesn't mean how the project should look; the process should also focus on how it will work or rather the nuts and bolts of the engine. When it comes to designing a project, use as many diagrams as possible to visualize each process. Visualization can be broken down into two main categories: Behavioral Diagraming and Structural Diagraming. Once you have created a set of diagrams, those can be used for collaboration with your stakeholders to ensure that you have everything needed. Your developers will also use these as blueprints for what they will be building.

There are many different diagram types in the Unified Modeling Language (UML), as listed here:

Activity diagramClass diagramCommunication diagramComponent diagramComposite diagramDeployment diagramEntity relationship diagramFlowchartInteraction diagramObject diagramPackage diagramProfile diagramSequence diagramState diagramTiming diagramUse case diagram

Discussing each of these diagrams in depth can be rather lengthy. In the following subsections, we will discuss only six of the most commonly used diagrams today and how they can help you build a project of any size and type.

Class diagrams

A class diagram is used to illustrate the different classes or components of a system and how they relate to each other. A class is best known as a group of objects with shared or similar roles within your system. Similar to an Entity Relationship Diagram (ERD), class diagrams depict the objects that would be tables in a database, the interactions that could take place, and any other main elements of your system. This diagram is usually structured in a way where the top compartment is the class name, the middle compartment contains all the attributes, also known as the fields, and the bottom compartment shows any functions or actions that could take place.

The following figure shows the relationship between a user, team, and award. The class diagram shows how a team can have a collection of users and a team may also have a collection of awards issued to them. In this example, awards are given to teams and not individual users themselves. A Team model object can have a function called getAwards(), where it will get a collection of all the awards that the team has earned:

Figure 1.2 – Class diagram

Deployment diagrams

A deployment diagram is used for high-level planning. This is how developers will collaborate and code will be updated between different environments. Network engineers will use the diagram to map out physical nodes that will be used within their configuration. Developers will use it to have a better understanding of how code will update between different environments and where they may need to push or pull that code to and from when updates need to be made. The primary components of a deployment diagram include artifacts, devices, and nodes:

An artifact is a digital asset, such as a file or an executable script of some kind.A device is a node that represents a computational resource, such as the application server or the domain server. A node is a physical entity that executes a component, subsystem, or process. Nodes can comprise a physical hardware component or a virtual, cloud-based component.

Entity relationship diagrams

An ERD visualizes the relationships between objects within your system. It's best used for mapping how different tables are linked within a database and is sometimes called an entity relationship model after modeling relationships in a database. These are used by your backend to help create the structure of the database and what fields should be included. On the other hand, these can be created by accessing existing databases to help map the current structure of a system and help you to see how best to rebuild it. It's like accessing blueprints of an existing building. Auto-generating these can mean they are so accurate that they even tell you about renovations done to that building after those initial blueprints were first drafted.

There are many ways to automatically generate an ERD. I'll share with you two of my favorite ways to go about doing that, assuming you already have a Django project up and running when reading and following along with this chapter. If not, I explain how to start a Django project from scratch as well as how to install the pgAdmin tool in the next chapter, Chapter 2, Project Configuration