Soumyadip Bhattacharjya

Abstract:

It's a collaborative drawing with communication platform.
Features includes -

Own drawing system.
Own authentication system
Edit canvas with peers in real time.
Messages, well designed to not hinder the experience of drawing.
Create meetings upfront and share the links with others.
Join to a meeting via encrypted link.

Idea:

It was exam day. My friends and I were frustrated—exams, the job market, and the fact that we hadn’t built anything that truly pushed our limits. So, we decided: let’s build something we’ve never heard of and figure it out from scratch.

Being a fan of networking, I suggested a real-time app. We all loved Excalidraw, so I took the idea further—collaborative drawing + messaging. By this year, I plan to expand it into a full-fledged video and audio calling platform.

After exams, we jumped in. Managing a two-person team taught me a lot about collaboration, Git, and GitHub. The journey was full of fun, frustration, and endless learning.

Now, let’s check out some screenshots and a demo!

Showcase

images of application (pending...)
demo yt video of application (pending...)
checkout the code-base (if you're interested) [CODE BASE](https://github.com/SoumyaCO/Collaboard)

System Architecture

Let's talk about the top level system architecture.

We've used separate backend and frontend. Frontend is made using react + javascript and backend is made with nodejs + typescript. As database thre is MongoDB and for storing dynamic collaboration room details used redis. Frontend talks with backend with REST APIs.

NOTE: we've made a postman collection and shared with team members to communicate api request and response structure.
But, if I have to do it and has enough I would like to make a separate "/docs" api endpoint and communicate those for others to use the backend only and make other frontend.

Let's talk about each and every part of the system. Up ahead there are detailed discussion on -

backend structure api routes.
authentication details
websocket and drawing system
new joiner request and admin acceptance feature.
Future working of it.
Team management

So if you're not a "tech enthusiast", not a problem, I put a halt to it. go checkout the github page,

and check out the product, youtube demo.

And if you're interested in a specific topic feel free to use Table of Contents top left of the screen (if you're on mobile)/ left side of the screen (if you're from a laptop/pc)

Backend API Structure

To be honest there are not much API routes in this system, so we've never thought of implementing GraphQL. It's hardly 6 to 8 routes.

generic home route "/"
auth routes "/auth"
login "/auth/login"
register "/auth/register"
user routes "/user"
user details update route "/user/update"
user deletion route "/user/delete"
meeting routes "/meetings"
get all meetings of a particular user "/meetings/get_all"
create meeting "/meetings/create"
update meeting "/meetings/update"
delete meeting "/meeting/delete"

As the name suggests these routes are basic CRUD operation for users and meetings.

Now the challenging portion of the app.

Drawing on canvas

Those who don't know, by default web supports simple graphics drawing via iitscontext api.
To call it a simple is a false statement cause our entire application is built with this " simple " context api.
Here is an example to draw a simple rectangle in an html "<canvas>"

1<html>
2<head> ... </head>
3<body>
4...
5<canvas id="canvas"> </canvas>
6...
7<script src="./scripts/canvas.js"></script>
8</body>
9</html>

1const canvas = document.getElementById("canvas");
2/**@type{CanvasRenderingContext2D}*/
3const ctx = canvas.getContext("2d",
4{ willReadFrequently: true });
5const [x, y, width, height] = [10, 10, 50, 50];
6ctx.fillRect(x, y, width, height);

NOTE: you're using javascript and still wants the auto suggestion from LSP (language server protocol) you can add that simple JSDoc comment before the line "@type{...}".

Now these objects are like bitmap, and they're pasted into the canvas. In order to communicate this thing we had two ways, and we tried both of them -

Share it as image to other peers upon getting the image the peer redraws it into their own canvas
Store each and every drawing command in a data structure and send that to peers and the peers draws that based on the commands.

The first approach had a very terrible drawbacks -

Each time we draw the image we loose information about the previous images, their dimensions and colours.
Also sharing these images though not significantly but compressing the quality, and making it obvious that a portion of image is newly drawn and another is previously drawn.

So, we proceeded with another approach: storing each and every data in a data structure. But which one?

We needed a data structure that preserves the order, and easy to delete an item from it and also easy to access.

Hashmap is cancelled because it doesn't stores the order.
We started with something light ... STACKs

Now there is a stack, and each time there is a new drawing we have to store those drawing data into the stack. Which kinda looks like this.

approach of storing canvas data into a stack

And the code for this kinda looks like this -

1let DRAWING_STACK = [];
2let drawingData = {
3id: 1,
4tool: tool,
5color: selectedColor,
6startX: 0,
7startY: 0,
8width: 0,
9height: 0,
10strokeWidth: strokeWidth,
11};
12function pushDataToStack() {
13let data = Drawing();
14data.id = drawingData.id;
15data.tool = drawingData.tool;
16data.color = drawingData.color;
17data.x = drawingData.startX;
18data.y = drawingData.startY;
19data.width = drawingData.width;
20data.height = drawingData.height;
21data.strokeWidth = drawingData.strokeWidth;
22DRAWING_STACK.push(data);
23drawingData.id++;
24}

A peer shares the entire stack each time to peers. and they redraws it sequentially

web socket structure for sharing canvas drawing data

[Work in progress ...]