This app is a culmination of everything we've learned about React, plus server-side web applications. It is an open-ended project, meaning you will build something based on your unique needs.
As much as possible, create milestones so you know whether you are on track, and to prioritise features when you are short on time. We expect half or more of our time to be spent on polish after finishing our apps' core functionalities. We encourage refactoring or rewriting some or most of the app for clear communication. Treat this as a portfolio project that you would show to prospective employers.
At least 1 full set of CRUD routes (create, retrieve, update, delete)
At least 2 SQL tables
At least 1 one-to-many and 1 many-to-many SQL relationship
Your app must be complete in the sense that it cannot rely on the theoretical existence of another system, e.g. an API that doesn't exist. You are free to use any 3rd-party APIs available on the internet, e.g. NPM libraries.
You are responsible for any seed data your app would need to run. The final version of your app must be populated with data that looks at least semi-realistic. For example, a social media app would have more than 1 post, 1 comment and 1 like in the system.
Since the focus of this project is on React, try not to create a database that is too complex or has too many complicated relationships. This will simply make it more complex to send and fetch data from the server.
Start: Ideation Phase 1. Introduce project, post project ideas in Slack for feedback.
Instructor to share feedback on project ideas in Slack.
Start: Ideation Phase 2. Create planning docs: user stories, wireframes, and DB ERD.
Due: Ideation Phase 2. Finalise project idea and share planning docs in GitHub repo over Slack.
Due: Peer Planning Review.
Start: Project Start.
Instructor to review planning docs over Slack and Zoom if necessary.
Begin Project Implementation.
Due: MVP deadline.
Users should be able to perform the primary user story. Please deploy your app to Heroku. Students to review code in pairs during class.
Instructor to review code on GitHub, share feedback in Slack and Zoom if necessary.
Due: Feature freeze.
No more developing new app functionality. Use remaining time to focus on polish, i.e. fixing UI/UX, refactoring code.
Quick project review in class to discuss improvements post-feature freeze.
Due: Project presentations.
30-minute post-mortem with instructor. Instructor to review code on GitHub, share feedback in Slack and Zoom if necessary.
Project Peer Review exercise.
Video demo due.
Recommended Order of Implementation
Implement the core user story first. What are users coming to your app to do? Make sure they are able to accomplish that, before adding authentication and nice-to-have features.
Any stretch functionality, e.g. AI APIs or file uploading
Ideation Phase 1
Brainstorm app ideas. What problem does the app solve, for whom? How does the app solve the problem? What data does the app handle? Feel free to use Rocket's project planning template, and share your ideas with your SL in Slack to get feedback.
Ideation Phase 2
Plan the app implementation with the following planning docs.
Please answer the project post-mortem questions before the post-mortem meeting with your instructor. These questions will be similar to the presentation questions, but we will dig deeper into your code.
Once done with your project, please submit it by adding it to the Rocket Bootcamp Projects spreadsheet in your batch-specific sheet. Feel free to view past student projects in previous batches' sheets.
Multiple Pages that Load React
Code splitting allows us to have multiple pages that each load separate React bundles. To keep our apps simple, Rocket recommends creating a single page application for Project 4, but if you feel strongly about having multiple pages, each of which load a separate React bundle, feel free to try out code splitting.
Setting a Path to Public Resources in Webpack Config
If our app contains multiple routes that each load separate resources compiled by Webpack, we will want to specify the Public Path attribute in our Webpack config so that the path to those resources can be absolute and not relative to the routes.
For example, for an app with route /post/:id that returns an HTML file that loads a Webpack bundle, if we do not specify public path in our Webpack config, that HTML file will look for our compiled Webpack bundle at mysite.com/post/my.bundle.js instead of mysite.com/my.bundle.js.