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 our index page 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 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 lo