Lab: FastAPI App

This lab is different from the auto-graded labs earlier in the course. There is no starter repository to fork and no doctest grader to turn a badge green. Instead you build a small FastAPI app from scratch inside your own GitHub repository, and that repository is the one that becomes your final project, the Twitter clone. Every route you write here you will extend in the final project, so treat this as laying the foundation rather than a throwaway exercise.

Because this is the seed of your final project, it is graded by hand from the branch you submit rather than by an autograder. Get the five routes working and the home page reading from the database; making the code clean now saves you real work when you extend it in a few weeks.

Requirement 0: a reasonable repo

Your project should live in a “reasonably structured” GitHub repo.

We are being intentionally vague about “reasonably structured” so that you get practice organizing a repo without step-by-step rules. Look back at the repos from previous assignments to get a sense of what makes a project layout reasonable: a clear place for your Python, your templates folder, and your data.

Requirement 1: five routes

Your webpage should have five routes:

  1. /
  2. /login
  3. /logout
  4. /create_message
  5. /create_user

Each route should have a corresponding HTML file in the templates folder, and each of these templates should extend a base.html template that contains the menu for your webpage. The base.html template should have an <h1> tag that is the title of your webpage, and the template for each route should contain an <h2> tag that is the title for that route.

Requirement 2: the home route reads the database

The / route must open a connection to a database created by db_create.py and display all of the messages, sorted with the most recent message at the top. For each message, you must display:

  1. the text of the message,
  2. the timestamp it was created at,
  3. the username of the user who created it,
  4. and the age of the user who created it.

Divide this task into two steps.

Step 1. Create a list of dictionaries, where each dictionary holds one message and has the four key/value pairs above. Pass this list to your template, and write the Jinja2 loop that renders it. Get this working on hard-coded “fake” data first, so you can see the template work before the database is involved. The RealPython primer on Jinja2 templating covers all the syntax you need, including lists, dictionaries, and for loops.

Step 2. Once fake data renders correctly, replace it with real data pulled from the database. Use the two-table join from the SQL reading, attaching the users table to the messages table so each message comes with its author’s username and age. (The reading’s example filtered to adults with a WHERE clause; drop that clause and you get the messages for every user.) Remember to use ? placeholders for any value that comes from the user, so your queries are not open to SQL injection.

Requirement 3: static files

We will not cover in class how to complete this requirement. Instead you should use this reference on serving static files in FastAPI. Leaving this uncovered is intentional, to give you practice using references; ask if you get stuck.

Your Python file should contain a route for static web resources served from a static folder. This folder should contain:

  1. an image,
  2. a CSS file.

You must modify your / route to display this image somewhere.

You must modify your base.html template to include the style sheet. This should result in every route being styled through the template.

One of the optional tasks in the final project is to create a nice-looking webpage with good navigation and styling. Now would be a good time to start on that.

Submitting

Uploading to GitHub is always committing and then pushing, but the submission for this lab uses a branch rather than your main line of work:

  1. Add a screenshot that demonstrates the working / route to your README.
  2. Create a new branch lab-submission that contains all of the code for this lab.
  3. Submit a link to this branch on Gradescope.

After submitting, you should not modify the lab-submission branch. Do all of your later work on the main (or master) branch instead. Your final project will lose points if the lab-submission branch gets updated after you submit it. Keeping one branch frozen while you keep building on another is a normal part of real programming, and getting practice with it is part of the point of this lab.