Skip to content

Latest commit

 

History

History
137 lines (108 loc) · 6.14 KB

README.md

File metadata and controls

137 lines (108 loc) · 6.14 KB
Raw

General Assembly Logo

Building a SPA with an Express API with Your Team

Required Reading

  1. Group Guidelines
  2. Working in Groups
  3. Group Roles
  4. Team Project Prompts

Overview

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

Not only will you be asked to exercise additional creativity in designing your own project, your consultants will partner you with other classmates to architect, design, and collaboratively build an API of your own design.

While your last project taught you how to get started with Ruby, SQL, and Ruby on Rails, this project you'll be building something exciting with Express and MongoDB.

This is meant to push you both technically and collaboratively. It’s a lot harder to work in a team than to work by yourself, but that's most likely what you’re going to find yourself doing in your first development job after WDI, and it's important to learn how to work together.

Make it work, and make it awesome.

Technical Requirements

Your project must:

  • Use MongoDB and Express to build an API.
  • Create an API using at least 2 related models, one of which should be a user.
  • Include all major CRUD functions in a RESTful API for at least one non-user model.
  • Consume your own API by making a front-end with HTML, Javascript, and jQuery
  • Use authentication in your API to restrict access to appropriate users.
  • Craft thoughtful user stories together, as a team.
  • Manage team contributions and collaboration using a standard Git flow on Github.
  • Layout and style your front-end with clean and well-formatted CSS.
  • Deploy your application online so it's publicly accessible.
  • Not have any obvious user facing errors.

Necessary Deliverables

  • A working API, built by the whole team, hosted somewhere on the internet.

  • A client app that consumes your API, built be the whole team, hosted somewhere on the internet.

  • At least two Git repositories (front-end and back-end) hosted on Github, with frequent commits from every team member dating back to the very beginning of the project.

  • The README.md file inside your front-end repo should have:

    • A short description of your application.
    • A brief explanation of the technologies (Node modules, Express middleware etc) used.
    • A couple of paragraphs detailing the general approach you took.
    • Notes on any unsolved problems or major hurdles your team had to overcome.
    • Installation instructions for any dependencies.
    • A link to your user stories – who are your users, what do they want, and why?
    • A link to your ERD - what data models does your app use?
    • A link to your wireframes – sketches of major views / interfaces in your application.
    • A link to the deployed front-end app.
    • A link to the repo for your back-end.

  • The README.md file inside your back-end repo should have:

    • A short description of your application.
    • A catalog of routes (paths and methods) that the API expects.
    • A link to the deployed back-end app.
    • A link to the repo for your front-end.

Overall Score

Your consultants will give you a total score on your project as an aggregate across all feedback categories:

Score Expectations
0 Does not meet expectations.
1 Meets expectations - good job!
2 Exceeds expectations, you magnificent creature, you!

This will serve as a helpful overall gauge of whether you met the project goals. But more important than your overall score is your feedback, particularly in individual categories - this will help you identify where to focus your efforts for future projects.

Getting Started

Eager to get moving? Here are some good resources that you might want to refer back to.

Some other suggestions and best practices:

  • Don’t hesitate to write throwaway code to solve short term problems.
  • Read the docs for whatever technologies / frameworks / API’s you use.
  • Write your code DRY and build your APIs RESTful.
  • Be consistent with your code style. You're working in teams, but you're only making one app per team. Make sure it looks like a unified effort.
  • Commit early, commit often. Don’t be afraid to break something because you can always go back in time to a previous version.
  • Keep user stories small and well-defined, and remember – user stories focus on what a user needs, not what development tasks need accomplishing.
  • Write code another developer wouldn't have to ask you about. Do your naming conventions make sense? Would another developer be able to look at your app and understand what everything is?
  • Make it all well-formatted. Are you indenting, consistently? Can we find the start and end of every div, curly brace, etc?
  • Comment your code. Will someone understand what is going on in each block or function? Even if it's obvious, explaining the what and why means someone else can pick it up and get it.
  • Write pseudocode before you write actual code. Thinking through the logic of something helps.

Good luck and happy hacking!

License

Source code distributed under the MIT license. Text and other assets copyright General Assembly, Inc., all rights reserved.