Full-Stack: Back-End | Django
Now that we’ve finished up the basics of front-end web development, it’s time to finally pull that curtain back and see how all this front-end stuff runs. That’s where back-end development comes in. Front-end loads and runs on the user’s browser; back-end runs on the server that the browser is accessing. There are two major parts to back-end development I want to discuss here, the framework and the database.
The framework sets a standard way to build and deploy websites. The framework determines what programming language to be used when developing a website. For example, here at Neo Solutions I am fairly proficient at the language Python, so running my sites off of the Django framework was the obvious choice. Once you initialize a project using Django, it builds the starting blocks to a working site that can be ran and viewed locally (as in not on the internet yet).
Django has the benefit of compartmentalizing different portions of any site into separate ‘apps.’ Not to be confused with what you would traditionally call an app, this is basically a separate set of instructions for a specific set of pages within a site. For example if you have a site that hosts both a group of pages for photos and a group of pages for a blog that allows for comments, they would function differently on the back-end. Because of this, it makes sense to separate them into separate apps for easy building, deployment and management.
From a broad perspective, what Django does is access a settings.py file (Python file) within the projects folders. This file tells the server where to access all the other files to be pulled and sent to the web browser. It will reference a url.py file that holds all the URLs to be accessed on the site. When a browser requests a particular URL, the server searches the url.py file to see if it exists and what to respond with. Generally in the url.py file, it will have instructions to refer to a views.py file or a separate url.py file within one of the separate apps in the project.
Every page would have its own view in views.py. The view is there to link the instructions from the HTML file to the server or simply refer the server to the HTML file. What I mean by ‘link the instructions’ is, suppose you have a page for allowing your visitors to send you an email. The HTML would hold the code to display name, contact, message, etc. boxes. The view takes the information put into those boxes and processes them accordingly. Whether that is storing their information in a database for future use or sending the information to an email automation service to get their message to your inbox.
There are a handful of files and folders in a Django project that are required by default or optional depending on what the app is used for. One such file is models.py. This file holds the format for a particular item that would be stored in the database. Let’s say there is a music database. It could have a model called song. Inside this song model would be fields for artist, song title, length, album, etc. So when you access the database to find a particular song to display on a webpage, it will come packaged with all the information stored with it. Models can also be interlinked or nested within other models as well. The album field could reference another separate model called album. This album model would hold all the songs within a particular album as well as the artist as fields. Same for an artist model holding all that artist’s albums or songs.
As always, it gets much bigger than this but this is just an overview of what the back-end does and how it works. This concludes the Full-Stack series! All of these topics will be referenced and built upon in later posts. From here, the posts will cover tips and tricks that I’m currently learning with coding sites as well as running the business.
