Data flow

Data flow

understanding were all the data is coming from and how it moves through through the C0D3.com app

The Data

• Lesson Material - currently hosted on notion.io docs *Also have unlinked mdx versions
• Lessons - metadata for each lesson (js0, js1 , js2 ...)
• Challenges - the instructions for each challenge (ie js0/problem 1)
• Submissions - users answers to challenge questions with status (open/passed/needMoreWork,overwritten)
• Comment - a message connected to a submission review
• User - user identification information (name, id, email, ect)
• UserLesson - track when user passed lesson and star status
• Star - tracks stars given to mentors by students
• Session - User, submissions, lessonStatus (UserLesson)
• Alerts - admin added notification messages for all users

Sources

We currently have two sources of data in the code app. One is the github repo with all the mdx document pages and the other is the database with all the user submitted data. Below is a rough breakdown of all the layers of abstraction along the way.

1. Github repo <- stores all full page lesson docs and extra learning docs (along with all the app source code)

   • MDX - An extension to markdown that allows react jsx components to be embedded in markdown documents
     • @mdx-js/loader - webpack plugin that converts mdx to jsx pages at build time

2. PostgreSQL Database - Stores all user generated data, lesson material and challenge material

   • Digitalocean - hosts all our docker images
     • Docker - lightweight, portable, self-sufficient container
       • caprover - manages our docker containers
         • Prisma - ORM (Object–relational mapping) package for node/typescript apps
           • schema.prisma - prisma generated source of truth for all database stored data
             • graphQL - Query Language used to access the database data
               • apollo graphql - the library we use to implement server/frontend graphQL api
                 • Reslovers - source of all the queries/mutations
                 • typedefs - source of graphql type contracts *Must keep in sync with prisma schema file
                   • graphql-code-generator - CLI tool to generate typescript types from graphql scheme
                     • graphql/index.tsx - outputs from codegen

---

Routes

Below is a heavily abbreviated / sudo code version of each page. Mostly highlighting the data that is being accessed via global context providers.

Key: <ComponentName {propName} /> providerValue <~ providerName(action)

---

_app.tsx

Base for all routes, Next.js first loads this file then injects the page routes into that component tree. *sub route do not directly share data IE: /curriculum and /curriculum/[lesson] are not related data wise.

<ApolloProvider> // all query and mutation hooks use this provider
  <MDXProvider> // provides all MDX pages with defined jsx components
    <ContextProvider> // provides session & setContext
       <Component>  // Entry point of all other route page components

---

/curriculum

ISR 300 second Props: lessons, alerts - <~Apollo(getApp)
*Only page with Apollo persist activated, meaning it will check localstorage first before using network for graphql queries

<Page {lesson} {alerts} /> session <~Apollo(getSession)
  <Layout {title} />
    <AppNav /> session <~Apollo(getApp)
    lesson.map(<LessonCard {lesson} /> submissions <~Apollo(GET_SUBMISSIONS, lesson.id))

---

/curriculum/[lesson]

<Page />` **lessons, session, alerts**<~Apollo(getApp) [LOADING SPINNER]
  session ~> GlobalContext
  <Layout {title} />
    <AppNav /> **session** <~ Apollo(getApp)
    <LessonTitleCard {lesson} />
    <Alerts {alerts}/>
    <ChallengeMaterial {lesson} {session} />
       ↳~~> Apollo(useAddCommentMutation)
       <ChallengeQuestionCard {lesson} />
         <ChallengeQuestionCardDisplay {lesson}/> session <~ContextProvider, previousSubmissions <~Apollo(GetPreviousSubmissionsQuery) 
           ↳~~> Apollo(useAddCommentMutation)
           <Diffview {submission} />
           <ReviewStatus {submission} />
           <MdInput />
       <StarCard {lesson} {session}/> <~ Apollo(GET_LESSON_MENTORS, lesson.id) [LOADING SPINNER]
         ↳~~> Apollo(useSetStarMutation)

---

Definitions

ISR (Incremental Static Regeneration): Built once per provided revalidation time limit. Default is to server stale while rebuilding but can be set to wait for new build