I started to build an API using Django and I will be documenting all the processes that I go through for myself and maybe others who are interested.
In every new article, we'll go through what I have changed in the new release and explain them as we go. You can read the first article here: Building Educational CMS API - Part 1: Project Setup
Link to repository: github@khasizadaj/edu_cms_api
Here goes v0.0.2
You can access to the changes with this link.
From the name of the blog, you can already assume that there are no big changes. The main idea behind these is to have cleaner and better development. I have made 2 main code changes and some documentation updates in this release:
Moved sensitive values to
.env
file to follow one of the best practicesAdd
Makefile
to abstract repetitive commandsUpdated
README.md
to for new changes
Let's go over them one by one.
.env
file
.env
file is used to store sensitive values and environment variables that are needed to run your application. It's recommended not to have such values hard-coded in the codebase. On top of that, when the environment changes or this code goes to production, there won't be any code change to run the code with a different configuration.
At this stage of the project, there were few candidates to transfer there and they were, SECRET_KEY
of Django application (the most important of them all at the moment), DEBUG
and ALLOWED_HOSTS
variables.
SECRET_KEY = "my_shiny_secret_key"
DEBUG = 1
ALLOWED_HOSTS ="127.0.0.1, localhost"
In the code, you can just use python-dotenv
library to load variables from .env
the file and add system environment variables.
import os
import dotenv
dotenv.load_dotenv() # extends system environment variables
os.getenv("DEBUG") # prints 1
Explanation of these variables
The SECRET_KEY
in Django is a long, random string that's crucial for your project's security. It's used to keep data safe and to generate unique values for various security features. You should always keep this key a secret, especially when your project is live on the internet. If someone gets this key, they could potentially break the security of your site. It's like a special password for your project's safety features.
The DEBUG
setting in Django is a true/false option that controls whether detailed error information is shown when something goes wrong. When it's true, you get a lot of helpful error details, which is great for when you're working on building your project. However, it's really important to turn it off (set it to false) when your project is live for everyone to use because those detailed errors can give away sensitive information about your project.
ALLOWED_HOSTS
in Django is a list of website addresses (like domain names or IP addresses) that you set up. It's like telling your Django app, "Only show information if the request comes from these addresses." If someone tries to access your app using an address not on this list, Django won't respond to them. This helps keep your app secure by blocking unknown addresses, especially when your app is available to everyone online.
If you want to set up the project on your machine, please create
.env
a file from.env.example
insrc
folder of the repository. In order to see more detailed step-by-step guide, please refer toREADME>md
.
make-ing something fancy
I got introduced to make
when I was at the boot camp of School 42, at the time it was so complex (it still is :)) thing for me. But if you get the hang of it, it's so cool!
A make
utility, typically used in programming to automate compiling code, can also be utilized in Django projects to simplify routine tasks. It allows you to run commands like starting the server, migrating databases, or installing dependencies with simple make commands, instead of typing out longer Django manage.py
commands. This streamlines your workflow, saving time and ensuring consistency in project management, especially useful in larger projects or teams. In order use make
you should:
Install
make
utility in your Linux distributionWrite down commands you would like to have in
Makefile
Before checking what changed, let's see one example.
Example
Let's say you want to run multiple scripts one after another and then move the output to another folder on your machine. To achieve this you have three options
1. Write bash
script
You can write a bash script called combined_
script.sh
that performs these steps for you. It can look like this.
#!/bin/bash
# running first script
bash ./script_1.sh
# running second script
bash ./script_2.sh
# running third script
bash ./script_3.sh
# moving file to new destination
mv ./output.txt ~/destination/
Then you can call it like this:
bash ./combined_script.sh
2. Use Makefile
You can achieve the same by having these in your Makefile
.
generate_report:
bash ./script_1.sh
bash ./script_2.sh
bash ./script_3.sh
mv ./output.txt ~/destination/
Then you can run this to achieve the same result.
make generate_report
3. Run the combined script from Makefile
#TO_BE_ADDED :)
Nah, I think you can imagine it yourself, or it's a small exercise for you to do. You can make
it.
To read rore on the topic, please check out [[#References]] section.
Makefile
for this project
As there are some commands that I keep repeatedly running, I moved those commands to Makefile
access it much faster and get autocompletion as well. Here are commands that the current version has and it will surely grow over time.
install
- To install the projecthelp
- To get helpmigrate
- To migrate the databaserun
- To run local server for developmenttest
- To test the project
See the file in here.
README.md
update
I updated the README.md
file to use make
commands instead of python manage.py
commands.