Requirements

What is a full-stack application?

A full-stack application is an app that has a front-end/client component that runs on a personal device (computer, phone), and one or more back-end components that run on a remote system (server) to provide additional capabilities.

There are multiple reasons to design a software system this way:

• We might have data that needs to be shared across multiple devices, and backend services can manage access to that data.
• We might need additional capabilities that a backend service provides.

Image from Jake Northey, “Should We Use a Full Stack Development Team or Specialists?”

Many of the applications that you use are full-stack applications!

• A web browser is a front-end client for a remote web server that contains shared data/pages.
• A Twitter client pulls tweets from a number of online sources and presents them in a local client.
• Microsoft Word is mostly a local application, but it integrates with OneDrive (Microsoft’s remote storage solution) for document storage.
• Even a text editor like Visual Studio Code integrates with a number of remote services for automatic updates, maintaining extensions and so on.

You and your team will propose, design and build a full-stack application that runs locally but leverages one or more remote services (at least one of which you must design and write yourself).

What are your project requirements?

You can choose a project idea from the list below, or come up with your own idea. Regardless of which project you choose, you MUST meet some common requirements:

1. You are required to use our technology stack, which are the technologies that we will discuss in lectures and support in-class. Deviation from this list requires explicit instructor permission (typically an email thread that you include in your project documentation).
2. Your application needs to include at least one client and one service, that work together to provide functionality.
   • Your client can be an Android or a Desktop application (macOS, Windows or Linux). (Building a web client or iOS client requires instructor permission).
   • Your service should be a web service that processes client requests: typically this means storing, processing and returning data that is required by the client applcation. Optionally, you may find that your application needs multiple services (e.g. fetching data from an existing service, and storing data on a second service that you create).; this will vary based on the needs of your particular problem.
3. Your client application must adhere to the conventions of that platform.
   • Desktop applications should support min/max/resizing; user functions should be clear and easy to find and use (through menus, toolbars, keyboard shortcuts); standard features like copy/paste, undo/redo should be implemented.
   • Mobile applications should use conventions for that platform: touch for selection, other gestures as appropriate; popup menus or hamburger buttons that expand to list functionality and so on.
4. Your application must save and restore data between sessions. This typically means saving user preferences for the client on the local filesystem (e.g. window position and size), and shared data in database on your remote service (e.g. for a notes application, notes would reside in some database so that they were not lost if you rebooted the system).
5. All other functional requirements are to be determined by you and your team. A significant portion of your final grade will be based on (a) how well you solve the problem for your user, and (b) how well your design “fits” the target platform. You are expected to propose (and design and implement) additional features to meet the needs of your users and the problem you are attempting to solve.
6. You will be required to submit a proposal early in the course, describing your proposed features, and get feedback/approval for a custom specification before you can proceed with implementation.

Suggested projects

Create your own project

Alteratively, you and your team are free to choose your own project topic. As a starting point you should:

1. Review the project requirements above! You are required to meet these in all cases.
2. Identify target users. Make sure that you are solving a a real problem for them. The interview process can help you define problems and areas to investigate.
3. Identify the purpose of your application. e.g. devise a better way to store code snippets for a developer; build a e-book reader that stores books and user ratings; a system for UW students to plan courses using UW Open API data.
4. Determine the basic requirements and features that would be required to address this problem. Look at competing products to get ideas. Brainstorm with your team and try to be original in solving the problem in a unique and better way!
5. Identify local and remote functionality - make sure that you are dividing features across both a client and service.

How these requirements contribute to your grade

Your grade will be based on your progress through the term.

• Did you make progress at each step of your project? Did you and your team work effectively together?
• How well you meet these requirements. Did you complete everything described above?
• How well designed your application is. Did you ensure that you built a compelling, useful and usable application? Did you take short-cuts?
• Did you go beyond the bare-minimum requirements? e.g. adding a second client, or expanding the requirements.
• How complex is the problem that you were attempting to solve? Was this a challenge for you and your team?
• Did you follow the prescribed process, including design, testing, and deployment?

Project Submission

As part of your project activities, you will be creating project documents and other artifacts. Together they comprise your final project submission. See assessment for details.

1/ GitLab Project

Your GitLab project must be setup as described in the Getting Started section, and should minimally include:

• A project landing page (aka README, see below).
• All related documentation and source code (see below).
• Release pages for each sprint (see below).
• Milestones corresponding to each sprint.
• Issue lists for each sprint, including issues closed as part of that sprint.
• Unassigned issues representing incomplete work.

2/ Documentation

2.1. README (Project Landing Page)

You should have a markdown file in the root of your source code repository named README.md. This will serve as a landing-page for your project (i.e. its the first thing that users will see when visiting your project page!). It should contain the following sections.

# SUPER-COOL-PROJECT-NAME

## Goal
A brief description of your project. What is it? What does it do?

## Team Members
List each person's name and email address.

## Screenshots/Videos
Optional, but often helpful to have a screenshot or demo-video for new users.

## Quick-Start Instructions
Instructions. Details on how to install and launch your application. 

## Project Documents
Include a link to your Wiki pages, see below.

## Software Releases
Include a link to your Wiki pages, see below.

2.2. Wiki

Your GitLab project has a built-in Wiki, where you can store more complex documents and project executables. It should contain the following documents:

• Project proposal
• Meeting minutes
• Anything else you feel would be helpful to document.

3/ Software Releases

Each sprint should produce an installable and runnable version of your project, which should contain the features that were completed during the sprint. The output from a sprint should be a release-quality build of your product, which you will store in this section of your project repository.

Your README.md file (from above) should include links to the components of each software release. Your software release should include:

• Release notes: a markdown or text file, containing at least:

  • the release date (which should be the sprint demo date)
  • the version of this release (which you increment for each release)
  • a list of changes that were included.

• Installers: this is a packaged version of your application that a user could use to install your software. You should support and test installation on at least 2 platforms (pick two from Linux, Windows, macOS - whatever you have available for testing).

  Acceptable forms of packaging include:

  • a zip or tar file that, when extracted, contains bin/ and lib/ directories, and a script that launches the application.
  • an exe, dmg or pkg file that, when executed, installs the application.

4/ Source Code Repository

Source code and other assets required to build your application should be stored in your project’s source code repository. The structure should look something like this by the end of the term.

.
├── .gitignore
├── .gitlab-ci.yml
├── LICENSE.txt
├── README.md
├── application
│   ├── build.gradle
│   └── src
│       ├── main
│       │   ├── java
│       │   └── kotlin
│       └── test
│           └── java
├── buildSrc
│   ├── build.gradle
│   └── src
│       └── main
│           └── groovy
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── releases
│   └── v0.1-release-notes.md
│   └── v0.1-installer.dmg
│   └── v0.1-installer.exe
│   └── v0.2-release-notes.md
│   └── v0.2-installer.dmg
│   └── v0.2-installer.exe
├── server
│   ├── build.gradle
│   ├── gradle.properties
│   └── src
│       ├── main
│       │   ├── java
│       │   ├── kotlin
│       │   └── resources
│       └── test
│           └── kotlin
├── settings.gradle
└── shared
    ├── build.gradle
    └── src
        └── main
            ├── java
            └── kotlin

Most of your repository contains the source code and related documents for your project. It is recommended that you follow the structure provided above, which will build properly in GitLab CI/CD.

Gallery

Here’s a gallery of some projects that were created in past offerings of this course. Teams have a lot of leeway in choosing what to design and build, so each project is unique! Screenshots and videos are posted here with the author’s permission.

Editors

Inkwell, a rich-text note-taking application. Copyright (c) 2023 Benjamin Du, Yuying Li, Charles Shen, and Andy Yang.

Zircon, a markdown editor with syntax highlighting. Copyright (c) 2023 Eddy Guo, Joshua Johnson, Mihran Mashhud, Tony Tascioglu, and Mrugank Upadhyay.

Notes, an app for organizing short notes. Copyright (c) 2023 Hoang Dang, Inseo Kim, Guransh Khurana, Abhay Menon, Anshul Ruhil.

Real-Time Collaboration

Whiteboard, a collaborative drawing space. Copyright (c) 2023 Terry Zheng, Jonathan Wang, Seth Hammell, and Alan Lee.

Whiteboard, a collaborative space with real-time synchronization. Copyright (c) 2023. Anh Huy Nguyen Do, Chirag Jindal, Mayank Devesh Shrivastava, Pranav Sai Vadrevu. (video)

Whiteboard, a collaborative drawing space. Copyright (c) 2023. Kevin Chen, Franklin Gao, Catherine Tao, Andrew Zhang. (video)