(Work in progress; Tusky certainly isn't ready to scale to 10,000 users)

• Two workflows, dubbed teacher and student. A user is both a student and a teacher, depending on if they have teacher permissions in a room.
• A user creates a room (and begins the teacher workflow) The room is the core part of user interaction
• From the room, the teacher can create / edit / administer quizzes
• Students can enter a teacher's room and take a quiz that is being administered.
• Teachers can edit a quiz while it is being administered. This is done in a way that is guaranteed not to harm students by both making it clear to the student that the question has changed and barring the teacher from including the particular result in the final grade.
• The teacher has several views of a quizzes responses
  • A real time, room specific aggregate view
  • A view of a specific student's responses
  • An all-time view of aggregate responses
  • Future: Class (as in a collection of students) based view.

• Tech stack: Linux / ... / Postgres / Python (FastAPI)
• Easy to build using Docker

There are 4 important parts of a FastAPI application:

• scheams Pydantic schemas
• models Database models (SQL Alchemy)
• crud (create / read / update / delete)
• routes The actual API Endpoints.

• VueJS (With Axios)

The frontend contains low quality code. I am not a JavaScript developer, and I just needed a minimum-viable-product. Hiring an actual front-end dev would go a long way for this project.

The backend contains maintainable, mostly idiomatic Python.

Exceptions are a work in progress. Initially, an attempt was made to treat errors like values (in a similar vain to Go and Rust). Although forcing the caller of a function to deal with the error made the code very explicit, the code felt extremely un-pythonic.