Design Docs

[gorterd]

Excellent work on your design docs, Isaac! Apologies for the slowness of my feedback. I split feedback into 'To Revise' (things you should change, or chat with me about if you don't want to change) and 'Suggestions' (take it or leave it advice). If you have any questions, please feel free to Slack me!

MVP List

To Revise:

• [x] Your first feature MVP (after user auth) should be displaying videos (a videos index and show page)
• [x] With displaying videos getting added as an MVP, Playback location save should probably be a bonus MVP
• [x] You'll need your 7th MVP to be a production README
• [x] I'd advise against having a paid accounts bonus feature (this site will primarily be visited by recruiters)
• [x] Frontend design: should not be a separate MVP; rather, an MVP won't be considered complete until its frontend design is pixel perfect

  Suggestions / Thoughts:

• [x] Consider doing a Genre MVP before user profiles (more integral to the core Netflix experience, I would say)

Database Schema

To Revise:

• [x] You probably don't need a subscription field since your clone won't involve subscriptions
• [x] No need for an image_url. If you want users to have images, then you'd want to store those using ActiveStorage and AWS. ActiveStorage uses its own database tables behind the scenes to store url information. However, I'd recommend making profiles (and profile pictures) a bonus.
• [x] For same reason, media does not need url columns
• [x] password digest does not need to be indexed and unique (you never search by password_digest)
• [x] profiles: should probably have a foreign key pointing to whichever user the profile belongs to

  Suggestions / Thoughts:

• [x] media: you might not need a views column. if you include it, it should be real (not fake data, which casts doubt on how much your app is actively functional), and tracking that would probably be a bonus MVP

Sample State

To Revise:

• [x] Unfortunately, this one will need to be reworked a bit. Your sample state should have top level keys of entities, ui, errors, and sessions.
  • Under entities, you should have slices of state for every entity / resource you need data for on the frontend. It'll correpond closely with your database schema, but you might exclude or add fields (example: add fields for media urls, no need for password digest fied).
  • ui includes fields relating to the current state of your app ui, such as which modal is currently showing (if any), and whether a loading spinner should be active.
  • errors includes fields for each possibly user action that could result in error messages (usually forms), each pointing to an array of currently active error messages
  • session includes information about which user is the current user
  • See this example sample state

Backend Routes

To Revise:

• [x] Need to add routes relating to lists (adding to a list, removing from a list, viewing everything in list)
• [x] neet a media show route as well, for a particular media

  Suggestions / Thoughts:

• [x] If filtering profiles index by user, consider making it a nested route (the alternative is you'll need to use a query string to include the id of user whose profiles you're fetching)

Frontend Routes & Components

To Revise:

• [x] You'll want to break things down into more components, for some of the routes. For example, at video/:id, you' need a component for the actual video, but another component or components for all the information about the video.
• [x] If you include categories (genres) here, you'll need to work that into your MVP list, database schema, etc
• [x] Need route / component for my list page

[theonewei]

I think I got everything in the list. I may have missed a few things that we talked about concerning the frontend and backend routes