Database Schema

• Contains correct datatypes
• Contains appropriate constraints/details
  • primary key
  • not null
  • unique
  • indexed
  • foreign key
• Contains bullet points after the table that state which foreign keys will reference to which table, or references to the associations which will be made
• foreign key and table name are lowercased, snake_cased and back_ticked
• Correctly formatted
  • schema is written in a table format
  • the table’s name are lowercased, snake_cased and back_ticked
  • the table header column names are bolded
  • columns names are lowercased and snaked_cased and back_ticked

Comments

1. Users
   1. Will Users add their first and last name when creating an account? Is this needed in your database? Is any other information needed as well?
2. Restaurants
   1. Not a huge issue, but do we want restaurant names to be unique on your backend (maybe to stop someone from adding multiple entries for the same restaurant)?
   2. Will you need to do data type conversion for your price range when retrieving that data?
   3. Description of restaurants? Or does that fall under cuisine?
   4. Will restaurants have photos? Is that a separate table necessitating joins?
   5. Just a suggestion, could we utilize an association here based on how many times a restaurant has been saved by users to dictate which restaurants are more popular?
3. Reviews
   1. Markdown formatting issues here with your table.
   2. Lots of ratings here. Are you planning on averaging out your detailed ratings for your overall rating or giving the user-controlled input for the overall?
   3. Also, will users only be able to leave one review for each restaurant or for each experience? If the former, should we use indexing here?
4. Reservations
   1. Should we index our foreign keys here?
5. Saved_Restaurants
   1. Timestamps?

Wiki Home Page

• Is the first page you see upon entering the wiki
• Contains a welcome message
• Contains a link/placeholder for a link to the live page
• All links in the right sidebar should contain each wiki page and link to the correct page
• Correctly formatted
  • each wiki page is listed in bullet points
  • all links route the correct page

Comments

Not a big deal, I'd just add some text under your welcome message indicating a link is pending. Otherwise, looks great.

MVP List

• Should have 7 MVPs.
  • 3 of those are User Auth, Heroku, and Production README.
  • The other 4 are from the MVP List or they have clarified them with you
• Contains a description sentence of the app
• Includes two to three detailed bullets on functionality and presentation of feature
• At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
• Estimates how long it will take the code each MVP
• Correctly formatted
  • MVPs are listed in an ordered list
  • Each MVP is broken down into bullet points

Comments

Please add CRUD specifications to all of your MVPs.
I would start with seeding Restaurant Data and Reservations MVP before attempting Search.

1. Heroku Hosting
   1. Should only take 1/2 day. Leaving you 1 full day to allocate to your schedule.
2. User Auth
   1. I would add Splash Page to this MVP as it is mostly styling and all functionality in it will point to User Auth.
   2. Also add error handling when it comes to user errors when attempting to sign up and sign in.
   3. I’d specify what users can do without logging in for this MVP.
   4. Demo/Guest Login is expected in this MVP and not considered a Bonus.
3. Restaurant Search
   1. You’ve nixed the Create Restaurants, which is okay, but I think you need to elaborate more on this section.
   2. What can Users see when it comes to Searching Restaurants and how can they interact in this MVP?
4. Restaurant Views & Reservations
   1. This is a big MVP as well, so I’d like some more elaboration on what users will see here and how they can interact with this MVP.
5. Reviews
   1. Will a user be able to leave a review for future reservations or only past reservations?
   2. How much CRUD is involved in this MVP?
6. Bonuses
   1. I would add more Profile functionality as a Bonus.

Frontend Routes

• Frontend routes contains wildcard variables written in camelCase
• Correctly formatted
  • Routes are displayed with inline coding text (backticks)

Comments

1. I would use general / path for splash and after a user has logged in? Thoughts?
2. Also, within your /index path, you have Restaurant Theme Components. Do these need Index and Item Components inside? Seems like that’s how OpenTable implements them.
3. Will you need a Photos Component within your RestShow Component?

Backend Routes

• Contains the following sections: HTML, API Endpoints(Backend)
• Each route has a description
• API Endpoint routes contains wildcard variables written in snake_case
• Routes does not contain superfluous routes
• Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
  • probably doesn’t need a GET likes api endpoint because that info comes through the post show

Comments

restaurants

1. Do you need a general GET route for all of your restaurants before a user has searched for a specific one?

reviews

1. For the POST /api/restaurants/:rest_id/reviews, we should have the restaurant id available to us, but do we need our route to be nested here? Could it just go to POST /api/reviews ?

reservations

1. Same as above for reviews POST.

saved restaurants

1. Same as above for saved restaurants POST and DELETE, do we need these routes nested under restaurants in our backend?

Sample State

• State shape is flat!
• State’s keys are camelCased
• All keys within the values in the state are accessible in the schema
• Correctly formatted
  • Sample state is rendered with triple backticks, and the language ```javascript...```). This will display the state as a code block instead of a giant line of text
  • Top level slices
    • entities
    • session
    • errors (here or in ui)
    • ui (if needed)
  • Should NOT have nested slices, aka comments inside of posts
  • Some info from other tables is ok, for instance:
  • the author username and imageurl for a post. basically any info that the user can’t change
  • like count and a boolean on whether the user likes the post instead of a likes slice

Comments

Your date and time keys within your reservation slice of state should match the column names res_time, res_date in your schema. You’re also missing party size in your sample state.