Design Docs - MVPs/Schema/Backend Routes/Sample State/Frontend Routes

[dsuh93]

Hey Kira, great job with design docs so far!! Here are a few comments I think you can address to better help you when planning out your full stack! 🐜

#Wiki Page Home
​

• 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

• beautifully done!
  ​

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 ones clarified with the PM
• 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

• splash and auth will take around 2 days, given that you have multi-page auth for signing up, and your splash page needs to look 'pixel-perfect'
• Will you be using Monday's 'survey' upon sign-up? While very pretty, maybe limiting it to one form with 3-4 selections for each drop-down would be better than the multi-page effect it has, just to save time and move onto other MVPs
• I think we'll have to re-arrange some of your MVPs and change some of what we want to accomplish, your current MVPs are trying to cram a lot into a single MVP which I'm worried you won't get to, so here's a breakdown of what I think could be a doable option, lmk your thoughts:
  • 3. Board CRUD, include bullets for creating, reading, editing, and deleting boards, should take about 2 days
  • 4. Tasks and Groups CRUD, focus on making sure the functionality of creating a new group and individual tasks per group is clean and smooth, this may take the longest (3 days)
  • 5. Columns CRUD, have a set number of types (i think 3 to start) and have each column type have a set number of values, 2 days
  • 6. Search functionality OR Likes and Comments for tasks (the search functionality would be more impressive, especially if you can get the highlight functionality)
  • Bonus: timeline view and everything else you've mentioned
  • feel free to respond to this issue thread if you have any questions or have other suggestions
    ​

Database Schema

​

• Contains correct datatypes
• Contains appropriate constraints/details
  • primary key
  • not null
  • unique
  • indexed
  • foreign key (missing these in the details for your schema)
• 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

• don't need a workspace_id if workspaces already references users with leader_id
• add bullets under tables for indexes

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:
  • i.e. probably don't need a GET likes api endpoint because that info comes through the post show
    ​

Comments

• missing : for GET /api/boards/board_id/users under users, and for task_id in columns
• your cells route is missing a table in your schema
• you might need a boards index route for a user so they can see all their boards on the

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

• looks great!
  ​

Frontend Routes

​

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

Comments

• amazing job!

[kierxin]

Hi David! Thank you for the feedback - I really appreciate it!!

For the signup survey, I was planning to skip that (so then for signup I would just have a text-input for email, then a form for full name and password on the second page). I had also been thinking I would consolidate the login auth into one page (as opposed to two pages, where the user enters their email and then their email + password).

For users being able to see the list of boards they have access to, since I'm just allowing each user to belong to one workspace, I figured I'd show the boards via the user's workspace association. (Their accessible boards would be displayed in the workspaceSidebar.)

For the MVPs, I revised the list - please let me know if you think I should continue revising it! If it looks good, then I will work on fixing up my other design docs to reflect the MVP changes and your other feedback.

Thanks again! 😁

[kierxin]

@dsuh93 Ooh also, I forgot to ask, for things that are now bonuses instead of part of my main MVPs, should I still keep the schema tables, routes, etc. for them in my design docs?