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

  • Users: Students that need to take course notes or wish to track their course information.
  • Purpose: Allow users to import and track information on courses that they’ve taken. e.g. ratings, lecture notes, grades on assignments, prof’s birthday. Store this information along with other related infomration such as PDF handouts, typed/written notes, pictures and so on.
  • Similar: Noteability, UWFlow
  • Functionality:
    • Local: Browse available courses, import and display course information from UW Open API. This could include course title, description, and when it’s offered. Save/edit text or rich-text notes.
    • Remote 1: Imports course information from UW Open API (read-only) to support these features.
    • Remote 2: Store notes and course comments in a custom service (read-write).
    • Remote 3: Integrate with UWFlow (read-write) – optional, long-term objective!
  • Users: Professionals that collaborate visually (students, designers, developers, architects).
  • Purpose: Provide a large canvas where people can sketch (e.g. virtual whiteboard), and changes are shared across multiple clients. Support freehand drawing, preformed shapes (that users can add, resize, move around the canvas), the ability to connect shapes and draw “box-diagrams”.
  • Similar: Miro
  • Functionality:
    • Local: Shape editor that allows you to drag/drop shapes, connect them, add text to a large canvas.
    • Remote: Stores drawings (“source-of-truth”) in a custom service and keeps multiple clients synchronized, so that multiple users can share a diagram in real-time.
  • Users: Anyone that wants to track recurring information.
  • Purpose: Have a single multi-purpose application to track day-to-day information (e.g. medication journal, work tasks, TODO lists).
  • Similar: Notion, DayOne, Obsidian
  • Functionality:
    • Local: Create, view, organize collections of notes; support rich formatting (rich-text, markdown or similar); integrate a calendar, ability to browse notes.
    • Remote: Store notes on a custom service, where they can be loaded across multiple devices. Multiple collected clients should remain synchronized as changes are made. This could (eventually) support synchronization across mobile and desktop applications.

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.

Here’s some APIs that might inspire you for a project idea.

  1. UWaterloo Open API:
  2. Notion API:
  3. Pokemon API:
  4. Marvel Developer Portal:
  5. REST Countries:
  6. NASA Open APIs:
  7. Weather API:
  8. Market Data API:
  9. News API:
  10. YouTube API:
  11. OMDb (Open Movie Database) API:
  12. DeckOfCards API:
  13. Open Library API:

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?