Design Docs Review - MVP/Schema/Backend Routes

[dsuh93]

Hey Julian, good job on your design docs so far, here are some notes and comments about stuff to work on!

Wiki Page Home

​

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

    Comments

• [x] fill out your wiki home page! ​

  MVP List

  ​

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

    Comments

• [x] For the User Auth MVP, demo user should be able to upload images (demo users are for recruiters, they should have access to all functionality of your website), also, include the Splash page as part of that MVP.
• [x] add more details about functionality for Uploads, will you be able to edit photos? delete?
• [x] Profile MVP should not include the Homepage, Homepage goes under Galleries(Feed)
• [x] Move the Profile MVP to be last, we want to work on getting as much functionality done first before we work on presentational pages, i.e. be able to upload photos/like photos by the time you work on profile page.
• [x] fix formatting for Other possible MVPs, have the bonus MVPs listed as bullets and provide detail for them in case you actually get to them ​

  Database Schema

  ​

• [x] Contains correct datatypes
• [x] Contains appropriate constraints/details
  • [x] primary key
  • [x] not null
  • [x] unique
  • [x] indexed
  • [x] foreign key
• [x] 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
  • [x] foreign key and table name are lowercased, snake_cased and back_ticked
• [x] Correctly formatted
  • [x] schema is written in a table format
  • [x] the table's name are lowercased, snake_cased and back_ticked
  • [x] the table header column names are bolded
  • [x] columns names are lowercased and snaked_cased and back_ticked ​

    Comments

• [ ] you probably won't need birthday or age for users, doesn't seem like the website requires that for signing up, if you have any particular reason for this let me know
• [x] fix formatting for table names, should look like this: snake_case
• [x] fix formatting for index bullets under users table
• [x] change user_id for the likes table to liker_id for something more semantic
• [x] maybe also author_id to uploader_id or photographer_id
• [x] fix bullets under follows table, include the foreign key references and add indexes to foreign keys, try and use photographer_id instead of followed_id for something more semantic, reminder that each foreign key will still reference users and to add the bullet for each
• [x] gallery should be plural, change to galleries (these are tables in the db)
• [x] add title column to galleries
• [x] images should be associated with galleries as well

Backend Routes

​

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

    Comments

• [x] missing routes for likes
• [x] for session POST /api/session, the redirect doesn't happen in the backend, so you don't need that part, instead say something like 'logs in a user'
• [ ] according to your gallery route description, it sounds like you want to have 'liked galleries'? You would have to include that in your schema as a foreign key as well as your sample state to show examples of that association. Being able to like multiple items by the same user would mean using polymorphic associations, so look into that as well!

[Juka1031]

Thanks for the detailed feedback david!

For birthday/age, 500px has age restricted content so I put the age/birthday as a way to filter restricted content, but I may not implement that in the clone.

As for likes I was thinking of doing a polymorphic association as a way to like both galleries and artworks, but that was something I planned on working at the end. So for now, I'll an an extra column in the like table as like_type as a way to have that polymorphic association and change image_id to liked_id that can be either an image or gallery