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/

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.