video upload

[Firgrep]

• [x] basic functionality (upload to bucket, update database with entry)
• [x] refactored inital code to use tRPC to get the signedPostUrl; also collapsed two mutations into one
• [x] delete old file when new one is uploaded on the same lesson
• [x] create preview area when there is an existing video on lesson

The idea is to use a bucket (Google Cloud Platform) to store the contents, and for consumption signedUrls will be generated via the app. This makes it so that the content cannot be extracted by link to another place (e.g. users sharing a link to people who haven't purchased the content).

[Firgrep]

Devlog:

• lost a lot of time trying to fix the API route when I was looking at the wrong docs on nextjs. I was looking at the old pages router api model, not the app router one which is very different
• needed to edit the CORS permissions on the bucket for it to accept localhost (this is only temporary for development. regardless, we won't use the same bucket for production)
• forgetting that anything that crosses the network boundary between client and server needs to be packaged through json() on both ends

the next step will be to hook this up with the database, such that when an upload is successful, the details of the file are stored on the model related to the lesson, such that it can be retrieved

• i also just realized that I didn't actually need to make that api route as using nextjs--the reason I thought I did was because I assumed I would be transferring bytes over this route (which you cannot do over tRPC), but it actually turns out that this route only passes a string to the GCP storage which sends back a signed URL, which is then used to transfer the actual file in a second api request. So we can use our usual tRPC for this one, and I'll refactor that next time

[Firgrep]

Devlog:

The current pattern of the upload mechanism is that when the client submits an upload, a signedPostUrl (with short lifetime) is generated from the server, which is then sent to the front and initiates a fetch requests from the client to the bucket. Any further intereaction with this would mean a second trip to the server. So why not handle everything on the server? In other words, handling file uploads on the server? Let's consider pro and cons.

Handling file uploads on the server:

• Control and validation: we can perform all our validation, security, processing and any additional logic easily within the same environment.
• Logging and auditing. We can keep a better record of events if everything goes through the server.
• Resumable uploads? Potentially allow a nice feature.
• Cleaner architecture. One trip to the backend that handles all the logic for the necessary operation.

Handling file uploads on the client:

• Reduced server load. When the client uploads the file directly to the bucket, it obviously off-loads that resource from the server. It also saves on having additional libraries (like multer) to parse and deal with files (I don't know if nextjs currently handles that built-in?).
• Faster uploads. Direct uploads can be faster as the client doesn't need to upload first to the server and then to the storage service.
• Less server storage. No need to store temporary files on the server. Given we are going for a stateless server, I'm not sure this is even possible?
• Clunkier code. If we want to do additional logic with uploads, we need to take into account what happens on the front and react to that from the backend, meaning a second (and more) trip to the backend for essentially the same operation.

Happy to discuss this further in more detail (in which case we might want to spawn a seperate issue and keep that as a discussion?).

[Firgrep]

Functionality added and merged to dev branch-