Deploy basic API routes

[VietAnh1010]

All scripts and files to copy server into client/lib and client/pages/api have been moved to server. Only necessary files for the deployment will be copied.

I will keep the server directory.

Currently, the api/users/[uid] routes support getting users' information, updating users, and deleting users. POST and DELETE requests will only be allowed only if the request is authenticated. Call user.getIdToken() to get the id token of the user, then add authorization: 'Bearer ${idToken}' to the headers of these POST and DELETE requests.

The api/users/[uid]/sites list all sites of a particular user, using a GET request.

The api/sites and api/pages routes are used to create sites and pages, respectively. The model for these request are to be changed as we progress, so currently any fields sent in the request body will be stored.

In this PR, we will concentrate on testing the api/users/[uid] routes and the usage of id token to authenticate POST and DELETE requests.

[joulev]

I will keep the server directory.

Come on... WHY??? How on this f*cking actual earth does this make any sense whatsoever? 😭

Disadvantages to using a monorepo to develop one single app

• We never know how Vercel actually builds the site (which script is ran, in what order, what is the file system, what is uploaded to AWS and what is not, etc.) (yes it is not simply running yarn build). Vercel can simply change how they deploy and all of this will go to waste.
• We are simply doing a workaround, in a scenario where an simpler, official, standard solution is available.
• You have to manually handle tsconfig and everything. Bugs will certainly come, this is literally a written invitation to bugs.
• What if I want to import some configuration from the backend? Or if you want to import some configuration from the frontend?

Advantages to using a monorepo to develop one single app

[joulev]

Move everything away from packages/server so that we can convert the whole monorepo to a normal repo immediately after merging.

See reasons in #90 (comment). Although they should already be painfully obvious already that I don't need to write them all down.

[VietAnh1010]

Move everything away from packages/server so that we can convert the whole monorepo to a normal repo immediately after merging.

Done, removed it.

[joulev]

Okay sorry for the outburst earlier, I was really angry but I have calmed down now.

Nevertheless, I would like the Orbital code to be as clean and low of workarounds as possible. Something that I can be proud of, even years into the future, instead of workarounds that will inevitably spiral into pieces of spaghetti.

Therefore I do not and will not allow code not meeting my personal standard to be merged to [main] and [prod]. And my personal standard is quite high.

[codecov]

Codecov Report

Merging #90 (9bd562a) into main (313baea) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #90   +/-   ##
=======================================
  Coverage   98.75%   98.75%           
=======================================
  Files          30       30           
  Lines         403      403           
  Branches       95       95           
=======================================
  Hits          398      398           
  Misses          5        5           

Impacted Files	Coverage Δ
packages/client/lib/client/generateCommentHTML.ts	100.00% <ø> (ø)
packages/client/lib/client/getOgImage.ts	100.00% <ø> (ø)
packages/client/lib/client/prism.tsx	100.00% <ø> (ø)
...ages/client/lib/client/tests/setupMediaViewport.ts	100.00% <ø> (ø)