Project Three: A MERN Stack Application As a Team:

Overview

You’ve come a long way, and it's time to show it.

You’ve already worked in small groups to accomplish various labs and exercises, but this time we’re going to challenge you to work in a small team on a project.

You and your teammates together will architect, design, and collaboratively build a full-stack web app.

This project will push you both technically and collaboratively!

You'll likely be working as part of a team in the workplace and this project will provide you with that important team development experience.

However, working on a project as part of a team can be more challenging due to logistical reasons, differing opinions, etc.

During this project, your instructors are going to be evaluating your ability to listen to and respect other opinions; to share and contribute your ideas with the team; and form a consensus and compromise when opinions differ.

In fact, your ability to work in a team during this project is more important to your instructors than the project itself.

Planning & Presentation Requirements

Working in a team is going to require more upfront planning to ensure the team is "on the same page"...

Pitch your project to the class with a pitch deck that includes:

• The application name.
• Your team members and their roles.
• The problem you are going to solve with your app.
• Check out previous decks: Tripio, Pantry, ArtWorld

Trello Board

This project also requires planning organized within a Trello board with the following lists:

• Icebox: Holds user stories that have yet to be moved to the Current/MVP list. All user stories are originally put into the Icebox, including both MVP and wish list stories.

• Current/MVP: Holds user stories that must be completed to meet the minimum project requirements (MVP). Once the MVP has been met, additional user stories may be moved from the Icebox.

• Completed: Hold completed user stories.

• Wireframes: Sketches of each screens's user interface for the major functionality of the application.

• Entity-Relationship-Diagram (ERD): A diagram of the app's models (one per data entity) and the relationships between them.

User stories need to be formed properly using this template:

As a <role>, I want <feature> so that <reason>.

The reason is optional if it's patently obvious.

2) Project Source Control & README

The project's source code must be hosted on a personal GitHub repository.

The repo is to contain frequent commits dated from the beginning of the project through its completion.

The project must include a README.md file with the following sections:

• Introduction: A paragraph used to introduce interested parties to the project and needs to include one or more screenshots.

• Technologies Used: A list of all technologies, libraries, APIs, etc. used in the project.

• Getting Started: Links to the project's planning (Trello board) and the deployed app on Netlify.

• Unsolved Problems: List any unsolved issues.

• Future Enhancements: Identify future features and enhancements planned for the project.

3) Application Technical Requirements/Deliverables

• A working full-stack, single-page application hosted on Heroku & Netlify.

• Incorporate the technologies of the MERN-stack:

  • MongoDB/Mongoose
  • Express
  • React
  • Node

• Have a well-styled interactive front-end that communicates with the Express backend via AJAX.

• Include at least two of the four CRUD (Create, Retrieve, Update & Delete) data operations/actions (having all four are optional)

• (OPTIONAL) you can try to implement one or more of the following:

  • Consume a third-party API.
  • Include admin features.
  • Client side routing to show multiple page-level components with React Router
  • Authentication, i.e. the ability of a user to log in & log out.
  • Authorization, by restricting functionality to authenticated users. Also, navigation should respond to the login status of the user.

5) Presentations

Your entire team must participate in the presentation of the project.

You will have approximately 10 minutes to present your project following these guidelines:

1. Introduce the Project:

   ☐ Intro your project by paraphrasing the README.

2. Demonstrate the Project:

   ☐ Launch the project by clicking the link in the README.

   ☐ Sign up a new user, then immediately log out.

   ☐ Log in with your preferred user and demonstrate the features of the app.

   ☐ Be sure to demo all CRUD data operations.

3. Show/discuss your code:

   ☐ Show the "main" data entity/model.

   ☐ Show your favorite component.

4. Share the experience:

   ☐ What was your biggest challenge? (besides Team Git Workflow)

   ☐ What are your key learnings/takeaways?

5. Q & A + Feedback

Project Assistance

• At this stage of SEIR, being able to find the the answers to your development issues is of paramount importance, this is especially important for the success of your team.

• Feel free to use all resources available including your own team.

• If you do seek assistance in Slack, explain the issue, include screenshots, and explain what you've done to solve the issue on your own.

Suggestions to Get Started

• Don’t get too caught up in too many awesome features – simple is better. Favor fewer features that look/feel impressive over numerous clunky/sloppy features.

• Implement the User model and authentication first. Then implement the "As a visitor, when I browse to the app, I want..." user story.

• Prioritize user stories and code them accordingly.

• When implementing a feature, think through the steps that it takes in plain language first. If necessary, write and/or diagram the steps to help guide your coding.

• Follow the steps we've done in class to implement features, beginning with the user's interaction, identifying the proper route, etc.

• Read the docs for whatever technologies / frameworks / API’s you use.

Best Practices

• Write DRY code.

• In a SPA, communication with the backend is via AJAX. Build RESTful APIs to CRUD your data entities (resources) and perform other functionality via AJAX. In a React app, those AJAX calls should be made from "service" modules, not components.

• Be consistent with your code style.

• Clearly name variables and functions - remember, variables are usually named as nouns and functions as verbs.

• Write well-formatted HTML/CSS/JS. Properly formatting your code makes it more readable. Improperly formatted code infers sloppiness.

• Comment your code where it makes sense. Most code is self-documenting, however, comments help explain complicated code.

• If you have any questions regarding these requirements, please feel free to contact your instructional team!