# Building Educational CMS API - Part 2: Perks for fast development

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](https://jkhasizada.hashnode.dev/building-educational-cms-api-part-1-project-setup)

> Link to repository: [github@khasizadaj/edu\_cms\_api](https://github.com/khasizadaj/edu_cms_api)

## Here goes v0.0.2

> You can access to the changes with this [link](https://github.com/khasizadaj/edu_cms_api/compare/v0.0.1...v0.0.2).

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:

1. Moved sensitive values to `.env` file to follow one of the best practices
    
2. Add `Makefile` to abstract repetitive commands
    
3. Updated [`README.md`](http://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.

```plaintext
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.

```python
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` 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`](http://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:

1. Install `make` utility in your Linux distribution
    
2. 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`](http://script.sh) that performs these steps for you. It can look like this.

```bash
#!/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
bash ./combined_script.sh
```

#### 2\. Use `Makefile`

You can achieve the same by having these in your `Makefile`.

```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.

```bash
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](https://github.com/khasizadaj/edu_cms_api/blob/4c15ea27fac941a84f092e81350a6e7d9081be09/Makefile).

## `README.md` update

I updated the `README.md` file to use `make` commands instead of `python manage.py` commands.

## References

1. `dotenv`
    
    1. [What is `dotenv`?](https://www.linkedin.com/posts/javid-khasizada_enhance-your-python-projects-by-integrating-activity-7151161275740270592-mWJ7?utm_source=share&utm_medium=member_desktop)
        
    2. [`dotenv` tutorial by "neuralink"](https://youtu.be/8dlQ_nDE7dQ?si=upzPQ3M9XeN1UkZU)
        
2. [Learn Makefiles by the tastiest examples](https://makefiletutorial.com)
    
3. About releases on GitHub
    
    1. [Releasing projects on GitHub](https://docs.github.com/en/repositories/releasing-projects-on-github)
        
    2. [Tutorial | How to Release Code With Github](https://youtu.be/Ob9llA_QhQY?si=_Z7T_ffdxUr3suWn)