Core Idea and Environment Setup

You might be wondering, what is a Vaas? I don’t know if it literally is a term or not, but I use it for my project. A VaaS is abbreviated as a Video as a Service Platform. Now after reading this, you may think that it is another YouTube clone, but no, it is not for that purpose.

VaaS (Video as a Service)

A VaaS is a kind of video service that allows you to easily delegate your video hosting to a platform that will allow controlling all factors of your video, such as optimisation, resizing, modification and hosting it. You can just ping a download URL, and your video is ready to go inside a page. It will support a lot of types for embedding and protocols and will allow you to directly embed ads in the video from the platform directly. In simple words, you don’t have to worry about anything regarding your videos and their size. You just need to worry about where to use it.

I know maybe YouTube-like services do already offer these features, but the workflows are not formal and integrated in the development ecosystem easily. It feels like an external service and has its own hassle of integration of hosted videos and the complexities it brings.

So with this thought and to improve my own hold on understanding complex technologies and how they work under the hood, I decided to build my own VaaS platform. I don’t know if I will monetise it or not, but it is a great experience for learning and designing architecture for systems. (too tired of the TODOs and clones).

I will keep on building the architecture as we proceed step by step. If you are interested in my approach or have some suggestions (criticisms too), then you can follow this journey of mine to build a VaaS platform as a solo developer for a side project.

Tech Stack

I am going to go with a monolithic setup because at the start I do not foresee all the situations, and once I know what modules are going to be there at that time, I will start separating them. Like a good developer, I will go with clean coding principles so that later on we don’t have a spaghetti mess.

So the tech stack I have chosen for my project is as follows :

• Vue for Frontend – IMO this does not have any uniqueness, and you can swap this with React/NextJS as well or any other frontend framework. I have chosen VueJS, as I have been wanting to learn it for a long time and its minimalistic approach is not bloated compared to React (yes, I find react bloated but I still use it sometimes :) )

• Golang for Application Server/Backend – I had two choices to go with – Node.js or Go. I did not go with NodeJS because this implementation is CPU intensive (Node is good for I/O intensive), and I know Web Workers are there, but the memory footprint of NodeJS is too high. So I chose Go as the primary backend language.

• PostgreSQL for Database – I wanted to go with a relational database since there are going to be multiple entities that are always going to be related here, like, e.g., videos and thumbnails, which we need to always fetch efficiently together. Moreover, we need consistency in state management for all video statuses, so we need durability all the time.

• S3 for Storage – Since S3 is widely used and there are many non-S3 Object Storage services now available, I am going to go with it. For local development I will be using Minio as my S3 service.

• Redis for cache – I only know thiso I'm going with this :/

Code Architecture

I will be following a separation of concerns architecture and keeping it very simple. We will be having following layers:

• Repository – This layer is the innermost layer and will allow any persistence-related operations. In our case, it will be the PostgreSQL-related writes and reads for every entity and also S3-related file storage.

• Service – This layer is the middle layer and will allow performing a set of logical unit tasks. Each function groups a logical set of tasks. It needs to be atomic i.e., only perform one set of logical task such as generating a video upload url and returning it, etc.

• Transport – This layer will contain the router and controller for our HTTP requests. It is the client-side facing layer. In future we will add sockets in this layer.

• Server – This is not a layer but contains all the initialisation code to start our application server. It will initialise all layers and pass them as dependencies as needed.

User Authentication

We will be having the base authentication as email and password for now. The user will have their username, email and password stored in a database. This is going to just be like a basic, typical implementation. For login we will have a login API and for registration a registration API. There will be middleware in the router to check if a user is authenticated or not.

For password hashing I will be using bcrypt with 10 rounds to allow for a durable method of hashing. Although it tends to be a bit slow, it’s very non-permeable to this day.

Conclusion

So I am going to conclude it here and go on to design the base architecture for uploading a video. Let’s discuss that in the next blog. Thank you :)