This project consisted of the creation of a website which acts as a platform to showcase projects, web applications, and guides using the Django framework. The project utilizes an AWS Elastic Beanstalk instance to run the website and is connected to a private GitHub repository through AWS CodePipline. Updates that are made locally can be pushed to the GitHub, and a new version of the site can be uploaded automatically. An AWS S3 bucket is used to house resources such as pictures, media, and data.Finally, a PostgreSQL database is used to store links to resources and content for the website.
A web application was thought as an appropriate platform to house various types of content and maintain accessibility. Utilizing the Django framework and AWS services, such an application was created. The underlying framework and various services Amazon offers allows for a great deal of flexibility for updates and feature to be added in the future.
The file structure differs from the default structure that is created when creating a new Django project. The main difference is a single settings directory was created to house various configuration files; apps were kept in a single folder. Inside the configuration directory under settings, different config files were kept here. These config files would be used when rotating the application between local, staging, and production states. These states would contain different settings or resources the application would use:
- Base.py contains global settings that other files import or override themselve
- Local.py contains local settings, information to connect to a local database and directories. Mainly used when flexibility and control over resources is required.
- Staging.py contains local and production settings, and acts as a bridge between a local and production release. Mainly resources that production would use are implemented here however access information is read from a secrets.json rather than environmental variables set in the Elastic Beanstalk instance.
- Production.py contains production settings and information to access production resources. Access information is added in as environmental variables which are created using a config file used by the Elastic Beanstalk instance upon update.
Apps are located in the django_blog directory, and contain separate migrations, static, and template directories. The containerization of individual apps was desired so related resources are kept together. In production, these resources are collected into a single static directory which is uploaded to the S3 bucket. Media files are kept under a directory called media, however in production, media files migrate over to the S3 bucket similar to the static directories. Finally, a utility directory is created to house various functions used by different apps within the whole application.
Several apps were created to redirect a user to different pages and allow the site to access information from the PostgreSQL database depending on the function of the page.
The About app is a simple app that displays a personal image and some background information. The image and background information can be changed using the admin console. The app also allows users to send an email to a personal email address, users can enter in a return email, subject, and content to be sent.
The blog app displays blog posts in two different views found in the views file. The first view is a list view which displays a captivating image and all the posts that have been created. The posts in this view only show a small image and a brief summary associated with the post. The detail view displays a post in greater detail and contains all the content associated with the post. Posts can be added through the admin console, where the image, content, data, summary, tags, and geographic data can be set. If there is geographic data, then a web map will be created and the data displayed. In the models file, two pieces of custom functionality were created. The first function is used to extract the first 250 characters from the content attribute; only if there is no summary set up upon creation of the post. The second function makes use of a signal to process and upload geographic data if any was passed. It makes use of other functions and a parser found in the utilities directory and dumps the data into the S3 bucket as a geojson. A path to the file is created and inserted into the PostgreSQL database for when the post and its associated data need to be pulled up in the future.