A request journey

Introduction

This document's goal is to help you understand the inner workings of the codebase by explaining what happens when a request is sent to https://c0d3.com.

https://c0d3.com/

What happens when you type https://c0d3.com into your browser url bar and hit enter?

1. When you type https://c0d3.com/ (notice how www is not in the url) in your browser and hit enter, DNS resolution will resolve to our Digital Ocean application server, the same one that hosts our curriculum's demo apps. The request will be sent there
   • Our application server's caprover application has an nginx redirection (if you login to caprover, the redirection application is called redirect-to-www) to send back a 301 HTTP response code for https://www.c0d3.com.
2. Browser sends a request to https://www.c0d3.com (notice the www in the url). DNS resolution for this url will resolve to a server owned by Vercel, and the request will be sent to the vercel instance that hosts our application.
   • Take a look at our nextjs config. If a route is defined there, nextJS will immediately respond with those rules first.
   • For our example, vercel will send back HTML and assets from their CDN, which contains our landing page. Keep in mind, this page is static, which means during deployment the page is built and put into their CDN for faster response times.
3. When browser receives the index page, the first code that runs is _app.tsx. This file is a container for every page.
   • Sentry (used for our error monitoring) Posthog (used for our front end analytics), and Apollo (used for sending GraphQL requests) are initialized.
   • Since the index page is served by CDN and is client side rendered, _app.tsx will be running on the browser so it is run on the client side. This is important because if you track down the Apollo setup helper function, useApollo, you will see that it needs to account for server side generated (SSG), server side rendered (SSR), as well as client side rendered pages (which is the case for our current example).
     • Pages that have getServerSideProps function defined are server side rendered, so _app.tsx would run on the server side.
4. After running _app.tsx, the browser renders the index page component. The first thing it does is to try to predict user login status by checking localstorage.
   • This is done to have a faster loading page. Alternatives were to send request to check for login status (slow), or server side render (then we can't use cdn)
   • If user is not logged in, the landing page is rendered.
5. Let's assume the user is logged in, in that case the curriculum page is rendered. Keep in mind we are using client side routing so this page change does not result the browser to send a new request to /curriculum.
   • /curriculum page has a getStaticProps, which means the page is getting server side generated (SSG) by vercel and then uploaded to their CDN every five minutes. More info with NextJS documentation.
     • We choose to do this because lesson content and challenges do not change often so it did not make sense for every user to send a request to fetch an additional request to get lesson and challenge descriptions on every page load. Instead, we build this page once every 5 minutes and push to the CDN so every user will get the lesson and challenge data along with the page.
   • Since _app.tsx already ran when loading the index page, it does not run again.
6. As the curriculum page loads, a graphql request is sent to the server by calling useGetSessionQuery.
   • The useGetSessionQuery is autogenerated by graphql code generator by running yarn generate.
     • The reason why we use code generator is because it is tedious to write out our graphql front end queries and then write out the types (for typescript) for it. Codegen will take our queries and autogenerate hooks and typescript types.
   • This query request is sent to the server.
7. When server receives the graphql query at /api/graphql, which is handled by /pages/api/graphql.ts
   • The request object goes through a few middlewares, which gives you logging functions like req.warn and user info with req.user
8. The request continues to the session query resolver, which queries our database using prisma and returns the data to the browser.
   • We use prisma for our database queries so we don't have to write SQL and typescript types manually. For example, if we were to get the stars using SQL, it would look something like SELECT * FROM USERS WHERE .... INNER JOIN ... , which is complicated! Prisma allows us to query our database easily using JavaScript syntax and then generates optimized SQL for us along with types for typescript.
9. The browser continues to render the curriculum page and renders LessonCard components for each lesson. For each card, if the user has passed a lesson a request would be sent to retrieve the submissions for the lesson.
10. The request goes to /api/graphql (mentioned above) and makes its way to submissions resolver, where Prisma is used to query the submissions for the given lesson.

Done! Page is now completely loaded!

CLI

Keep in mind the CLI is in a different repo!

c0d3 login

What happens when you type c0d3 login into the terminal to login?

1. You are prompted for your c0d3 credentials.
2. A graphql request is sent to www.c0d3.com/api/graphql with a login mutation.
3. The request goes through the middlewares first and then arrives at the login mutation.
   • In the login mutation, if the user does not have a cliToken, one would be generated for the user and stored in the database.
4. When cli receives the response, the token is written into ~/.c0d3/credentials.json

c0d3 submit

What happens when you type c0d3 submit into the terminal to submit your code?

1. The CLI gets the token that is generated by the c0d3 login command, gets the diff between the current branch and master branch, prompts for lesson and challenge, and prompts for confirmation.
2. The CLI sends a submission graphql request to www.c0d3.com/api/graphql with a create submission mutation.
3. The request goes through the middlewares first and then arrives at the createSubmission mutation.

Security Bug needs to be fixed asap