Create a CV/Resume Builder using the Django Rest Framework (part 2)
Tags: python, django, beginners, resume
Published: 2020-12-13 15:55:02

> ### If Django was a superhero, it would be Superman
~ Laptop and the Lady named Lois

**Table of content**
1. Introduction
2. Assumptions about readers
3. Getting Started
4. Django commands: Startproject vs Startapp
5. What are migrations?
  - Makemigrations vs migrate
6. Creating an admin user

**Introduction**  
This tutorial is a continuation of [Part 1](https://dev.to/phen_e/create-a-cv-resume-builder-using-the-django-rest-framework-part-1-1acb). In this part, we shall begin by setting up our Django environment.

**Some assumptions made in this tutorial**:
1. Readers have set up a virtual environment.
2. Readers are conversant with _pip_.
3. Readers are comfortable working with Git and Github (Doesn't matter much).

**Getting started**  
The name of our CV Builder application is **CVeate**, a combination of *CV and Create* (oh shoot, Sherlock!😁).  
Our CV builder requires Django and Django Rest Framework installed via `pip` on your preferred virtual environment.

```
>> pip install django djangorestframework
```
In order to begin with our Django project, we need to have it in a folder. Of course, we could have easily just created a new folder on our laptops and begin. Fortunately, Django provides a convenient way of creating a Django folder (literally the project).

We use this command `django-admin startproject cveate` which takes the form `<django command> <command to create folder> <folder name to be created>`.  
This works if you already have Django installed as a package on your computer.

We create our project titled **cveate** using the command just stated and change our current directory (fancy word for "folder") to **cveate**. 
```
>> django-admin startproject cveate
>> cd cveate
```
You can run the command below if you use Visual Studio Code (VS Code). This opens a new VS window of the current Django project. Note the trailing dot ("**.**"):

```
>> code .
```
Your folder structure should be similar to this (Do not worry about **db.sqlite3** not being available in your own folder structure):

![cveat_root.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1606247779803/m3BhTZp0i.png)

The above folder structure includes the **setting.py** and **urls.py** which we would be modifying in our project. In practice, these are the files usually modified in the root app or directory. Root App or directory are the folders that are created when one runs `django-admin startproject <root-directory/project folder/ folder to be created>`.

To create a new application that will host our actual CV/Resume builder, we run the following command. This takes the form `python manage.py <command to create app> <app name to be created>`:
```
>> python manage.py startapp cv
``` 
A new app (folder) named "**cv**" would be created. 

**Django Commands: Startproject vs Startapp**  
You may be wondering *"What is the difference between **startproject** and **startapp**?"*.   
*`startproject`* is the base for every Django application to reside, think of a folder inside another folder or a parent folder. Most of Django's setup happens in the settings.py file of the root folder.  
*`startapp`* creates the child folder, here, you as the developer, go about your business on this folder level. Little Django setups are found in folders created using `startapp` command.

An example of our current setup should look like this on your computer:

![cveat_initial_setup.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1606078532123/Kjimisos2.png)

You can quickly notice that **settings.py** and other files in the root folder are not seen in the **cv** folder (we shall refer to this as *app* from now) neither do we see many prewritten codes compared to the parent file.

In order to have Django acknowledge that **cv** is used in the project, it should be added into `INSTALLED_APPS` in **cveate/settings.py**

```
# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    
    # Local app
    'cv',     # <---- new
]
```
To have routes (URL paths) from **cv**, create a new file named `urls.py` in the **cv** folder and include the following:

```
from django.urls import path
from cv import views

urlpatterns = [
    
]
```

To let Django know that it should look for routes (URL paths) in **cv** app, in **_cveate/urls.py_**, include the following:

```
from django.contrib import admin
from django.urls import path, include # <--- new

urlpatterns = [
    path('admin/', admin.site.urls),
    path('resume/', include('cv.urls')), # new
]

```

With all those done, we run migrations. 

**What are migrations?**

Migrations are a way to keep track of changes made to a database schema (Django models). 

> ### One can think of migrations as mini version control for databases.  

Similar to version control systems like Git and Subversion, migrations can be reverted to a previously known working version also known as *rollback*.

**Makemigrations vs Migrate**  
The command `makemigrations` creates the migration files in children apps which reflect changes made in their **models.py** whereas the `migrate` command implements the changes in the migration files to the database:

```
>> python manage.py makemigrations
>> python manage.py migrate
```

**Creating an admin user**  
Let's create a superuser, AKA an Admin, in order to see how things work behind the scenes. The command `createsuperuser` creates a new user which is labeled as an _admin_.

```
>> python manage.py createsuperuser
Username: admin
Email address: admin@gmail.com
Password: 
Password (again): 
Superuser created successfully.
```

Django applications run on default IP port **localhost:8000/**. To start a local server on your computer, run the following command on a different command line window:
```
>> python manage.py runserver
```

Recall in **cveate/urls.py** we have a line `path('admin/', ...)`, which shows the URL paths used in the browser. For example, `http://localhost:8000 **/admin/** `. Similarly, all routes (URLs) will take the same form, for `path('resume/', ...)`, the browser will use `http://localhost:8000 **/resume/** `.  
Our local server runs on http://localhost:8000/admin/ check it out. You should see something similar to this:

![admin_login_screen.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1606249886918/nRASQwMlh.png)

Input the login details you recently signed up with when you ran `createsuperuser` command. On successful login, you should see a similar screen:

![admin_login_success.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1606250063928/wxuLOf4aH.png)

You're welcome to play around with the *admin site*! Django comes battery included with features like this. Of course, one can build a different admin site or extend this already existing version. However, we will be using the default admin site.

Okay, that seemed like a lot to do! But thank goodness we are done with it. Time to get started with the actual application in Part 3😁🥳. We shall begin by creating our models based on the existing ER-diagram designed using [dbdiagram.io](www.dbdiagram.io) tool.