PatchVid

August 2024

Idea

PatchVid was inspired by the need for an accessible tool that allows users to quickly create videos highlighting updates to their services. The app focuses on providing customizable templates for showcasing key information related to updates, available on both web and Discord platforms

Planning

In the planning phase, I focused on visualizing the data flow and organizing my thoughts to develop a coherent plan. I selected the technologies to bring this vision to life: Next.js for the web app, Express for video rendering, and Discord.js for the Discord bot. Remotion was chosen for programmatically creating videos using React and for rendering, I combined RabbitMQ with Redis to manage the queue system. The project was structured as a monorepo using Turborepo. For deployment, I planned to self-host the Discord bot and rendering service using Docker.

Building

I began by setting up the monorepo structure using Turborepo. Next, I developed the Next.js web app, focusing on creating the first video template.

After that, I implemented the Discord bot, which takes inputs from the user, validates them, and sends them to the rendering service via an HTTP request. This led me to the next step: building the rendering service.

Rendering a video has two steps: first, selecting the template that the user has chosen, and then applying the user input to the template before starting the rendering process. To inform the user of the rendering progress, I used RabbitMQ to communicate with the Discord bot (where the request originates). After the Discord bot sends the render request, it begins consuming messages from the message broker. These messages contain the progress of the render, which comes from the rendering service.

The web app follows the same process as the Discord bots it takes the input and sends it to the rendering service. but, instead of consuming progress messages from the message broker, I implemented polling since I cannot use a message broker on the client side. Polling involves sending HTTP GET requests to the rendering service, which returns the progress as a response.

Managing Multiple Users: Rendering is time-consuming and resource-intensive, and since my server doesn't auto-scale, this is where queues come into play. When a request comes to the rendering service, I send it to the queue and store the user's queue position in Redis because RabbitMQ doesn't provide user positions. Now, when a request comes to the rendering service, I put it in the queue. If the queue is clear, I start updating the user with the rendering progress. If the user is in the queue, I update them with their current position.