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 practices
Add Makefile to abstract repetitive commands
Updated 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()
os.getenv("DEBUG")
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 in src folder of the repository. In order to see more detailed step-by-step guide, please refer to README>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 distribution
Write 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
bash ./script_1.sh
bash ./script_2.sh
bash ./script_3.sh
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 project
help - To get help
migrate - To migrate the database
run - To run local server for development
test - 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.
References
dotenv
What is dotenv?
dotenv tutorial by "neuralink"
Learn Makefiles by the tastiest examples
About releases on GitHub
Releasing projects on GitHub
Tutorial | How to Release Code With Github
