Skip to content

Project P3: Backend Development

Learning Objectives

Students will be able to...

  • Transform development specifications into a working backend.
  • Collaborate with LLMs to generate backend code, while refining and debugging the output, with a real or stubbed frontend.

Instructions

In P1, you created requirements, UX storyboards and wireframes, and an architecture document for your project. In P2, you used an LLM to implement the frontend of your application based on these artifacts while stubbing the backend. In P3, you will implement the backend of your application and integrate it with the frontend.

Part 1: Implement the Backend

Begin by considering the user stories for which you implemented frontend features in P2. Consider the architecture plans you used an LLM to generate for these features. Make sure that the architecture plans and diagrams are well harmonized to ensure that the LLM knows you are building a single backend for the application that can support all the user stories.

For each module in your architecture, decide whether it will be part of the frontend or backend. Recall that frontend components usually handle the application's user interfaces and the business logic. The backend often handles data storage (separate data stores for each tenant), compute-intensive algorithms (e.g., machine learning, audio/video codecs, path routing), calls out to external backend services (e.g., speech transcription, image recognition, authentication, cryptography), and networking to and from other frontend UIs connected to the same backend. In P3, you only need to specify and implement the backend modules.

By the end of this sprint, you'll have a working backend implementation plus loads of documentation describing how it works. Recall that every module lives in a single backend and should make the same technical choices to minimize the number of redundant internal and external dependencies.

Use LLMs to build up your project's backend implementation in increments. For each increment to be built, include the relevant user stories, wireframes, and architecture information in the LLM's context. The aim here is to do something akin to spec-driven development.

  • LLM-Driven Coding: Remember, use the LLMs as much as possible to generate the deliverables. You may not modify any generated graphics or code directly, only by prompting the LLM.
  • Git/GitHub: Use Git for version control for your team's sourcecode and other artifacts. Create repositories in the course GitHub organization to push your work to. Use GitHub pull requests (PRs) to submit code to your team's project.
  • Code Review: Make sure that each PR is reviewed by at least one team member other than the author before the it is accepted. Reviewers should use LLMs to assist them.
  • Collaborative Development: Each team member must take the lead on the creation of at least one substantive pull request. It is acceptable to pair program throughout the project.
  • Evolving Specs: It is expected that your project's specs will change and evolve as you work on the project. Be sure to manage the spec artifacts (e.g., with respect to version control and collaboration) the same way you would your code artifacts.
  • Be Vigilant: Watch out for duplicated functionality, inconsistent class names, and incomplete interfaces.
  • README: Be sure to include a README.md in the top-level repository directory. Among other sensible content (project title, contributors, etc.), be sure to include instructions (for the instructors) regarding how to initialize and run the app. If there are external dependencies (e.g., libraries/packages), be sure to mention those as well.
  • AI Chat Transcripts: For each PR, attach or link to all AI transcripts that produced the code and other artifacts being submitted in the PR.
  • 10 Concurrent Users: Make sure your backend supports 10 simultaneous frontend users. Simultaneity means that all of those users' frontend UIs are talking to the backend at the same time. Do not attempt to make your backend scale to more users.
  • Optionally Stub Frontend: Consider whether you need to have a working frontend to tell if your backend works or not. It is ok to stub the frontend (from the backend's point of view) if it helps you make timely progress.
  • Assume Amazon AWS: Assume that your backends will (eventually) be deployed to Amazon Web Services (AWS), and let that influence your choice of external backend services, especially if the cost is zero or minimal. In P3, you need to stub any calls to external services. However in P4, you will be able to create an AWS account with $100-200 free credits and will be usable for 6 months (or until the credits are exhausted) to call those services.

Backend Modules:

For every backend module in the architecture, do the following (with assistance from the LLM):

  • Module Features: Specify the module's features. What can it do? What does it not do? These should be written to be understandable by a professional backend developer.
  • Module Architecture: Design the internal architecture for the module. Write down a text description to describe it and draw it as a Mermaid diagram. Justify your design choices as if you were speaking to a senior architect with your company.
  • Data Storage: Determine the stable storage mechanism for the module (i.e., you can't just use an in-memory data structure because your app might crash and lose its memory—customers really hate data loss!)
  • Data Schemas: Define any data schemas required to communicate with any storage databases.
  • Module API: Define a clear, unambiguous API for external callers of this module. We suggest employing a REST API for any services accessible over the web.
  • Class Diagram: Draw a Mermaid class hierarchy diagram that shows the module-internal view of each class.
  • Module Implementation: Use the LLM to generate the code for each class.

Part 2: Demo and Reflection Video

Once all team members have submitted their contributions, record a demonstration and reflection video as follows.

  • Record Teams Meeting: To create the video gather your team together in a Teams meeting and record the meeting. Use screen sharing to capture app demos and slide presentations in the recording. Everyone must have their webcams on, so it can be seen that everyone is present and participating.
  • Backend Demo: To begin the video, one team member must give a demonstration of the app's backend features. Limit the demo to no more than 8 minutes. Demonstrate using various backend features to demonstrate that the backend is working as expected. This demonstration may involve showing backend log messages. You may also show and run automated tests to show that the backend components work. Demo a variety of error and edge cases to help build confidence as to the completeness of the implementation.
  • Reflection: Take turns with your teammates presenting answers to the reflection questions below. You may optionally use slides or your app as visual aids to support the reflections. Each team member must present the reflection for at least one question. As a team, agree ahead of time as to what the response to each question will entail.

Reflection Questions:

  • How effective was the LLM in generating the backend code? What did you like about the result?
  • What was wrong with what the LLM first generated? What were you able to fix it easily? What problems were more difficult to fix?
  • How did you convince yourself that the implementation was complete and accomplished your user stories? Did you use the LLM to help?

How to Submit

  • Push all of the spec and code artifacts to your team's GitHub repository (or repositories).
  • Save your video to OneDrive (or Microsoft Clipchamp). Give instructors read permissions. Remove expiration (if relevant).
  • In Canvas, submit the URL(s) of the repository (or repositories) and the video.

Grading Rubric

Project assignments are graded as High-Pass/Low-Pass/Fail.

  • High-Pass: Pass score on all parts with High-Pass on half or more.
  • Low-Pass: Pass score on all parts.
  • Fail: Fails to meet requirements for Low-Pass.

Part 1 Rubric: Implement the Backend

  • High-Pass: Pass score on all subparts with High-Pass on half or more.
  • Low-Pass: Pass score on all subparts.
  • Fail: Fails to meet requirements for Low-Pass.

Subpart 1-1 Backend App with Integrated and/or Stubbed Frontend:

  • High-Pass: Runnable backend was implemented with features that cover most or all core requirements and that are of good quality. Frontend was stubbed and/or integrated with the backend such that backend functionality can be tested. The team's app can be successfully initialized and ran by following the instructions in the top-level README.md Markdown file.
  • Low-Pass: Runnable backend was implemented, but a few glaring issues with the quality and/or quantity of functionality were evident. Instructions in the README.md file contained a few glaring omissions or errors.
  • Fail: Fails to meet the requirements for Low-Pass.

Subpart 1-2 Collaborative AI-Assisted Development:

This subpart is graded individually for each team member.

  • High-Pass: The team member led at least one substantial PR that was reviewed and merged into the main branch. The PR included all relevant AI chat transcripts. The team member reviewed at least one PR created by another team member.
  • Low-Pass: The team member led a substantial PR, but there were a few glaring issues with the quality of the PR and/or with the AI chat transcripts. The team member failed to review another team member's PR.
  • Fail: Fails to meet the requirements for Low-Pass.

Part 2 Rubric: Demo and Reflection Video

  • High-Pass: Pass score on all subparts with High-Pass on half or more.
  • Low-Pass: Pass score on all subparts.
  • Fail: Fails to meet requirements for Low-Pass.

Subpart 1-1 Backend Demo:

  • High-Pass: Video demonstration of the team's backend app is presented such that the features are well covered, a variety of happy-path, edge, and error use cases are demoed, and the demo is 8 minutes or less in length.
  • Low-Pass: Video demonstration of the backend is presented; however, there are a few glaring issues with the feature coverage, and/or the demo is noticeably longer than 8 minutes (but not longer than 16).
  • Fail: Fails to meet the requirements for Low-Pass.

Subpart 1-2 Reflection Presentation:

This subpart is graded individually for each team member.

  • High-Pass: The team member presents answers to a subset of the reflection questions such that the presentation is clear, thoughtful, and connects to the team members' experiences.
  • Low-Pass: The team member presents answers to reflection questions; however, there are minor deficiencies with the quality of their presentation.
  • Fail: Fails to meet the requirements for Low-Pass.