Design Docs

[kinkatse]

Hey Rokas! Great work so far! I see that you are still in the planning stages and I've given the feedback from what I see here. I know we talked beforehand and you said you would polish it up a lot more today. Feel free to meet with me as well and we can go over some of that planning for you to be set up in the right direction!

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

​

MVP List

​

• Should have 7 MVPs.
  • 3 of those are User Auth, hosting on Render, 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

• Admittedly, it was hard to figure out what types of functionalities each of these are, but it seems like they are like:
  Tails -> Posts/Articles
  Comets -> Comments
  Stars -> Likes
  Charts -> Subscribe/Follow
  Constellations -> Group
  Spaces -> Save/Bookmark
• Do let me know if I got any of this wrong, but this looks well thought out and great!
• Only thing I would change is to move one of the main MVPs to Bonus since we only have 7 total MVPs (Also, you skipped the number 5 in the ordered list)

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

• There should be bullet points under each table for indexes, what foreign keys are referencing, and associations
• The profile table seems unnecessary since you could have those columns in the user table and have that represent the profile of the user as well
• I was assuming the Stars was a Like table, which you have as a joins but with two user_id columns, if this is meant to be a like, then one of these columns should be the tail_id
• I see your Follows table here has two user_id's as well. While this is a self joins with the user table, you should distinguish between the two column names so it's clear who is following who. (Is this meant to be called Charts table?)
• Spaces has the same issue
• The template table is incomplete
• A lot of this does seem like a rough sketch and planning but we can meet to talk about how you want to design your tables and what we think our best course of action is.

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

• Don't forget the route for GET / - StaticPagesController#root
• Wildcards should be in snake_case

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

• Since we are in JavaScript land, we use camelCased keys. Change all keys that are snake_cased into camelCased

Frontend Routes

​

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

Comments

[rjeriomenko]

Updated the MVP List and Schema. Should make a bit more sense now. Got some questions so we will definitely meet.