[Hackathon Mini Series] — Digital Draw on Screen
The fifth blog in our hackathon series looks at how one team build a drawing on screen app. The output was a fully scalable solution — a very ambitious projects for a 2 day hackathon!
One of the prised features of my favoured video chat client is the ability to collaborate by highlighting and drawing on screen. It’s something we’ve grown accustomed to whilst working remotely — underlining code, drawing pointers: circles, arrows and dots (“where do you mean?”, “this bit here!”), and sometimes even rudimentary architecture diagrams.
And occasionally, doodling.
For Hackathon we decided to look into decoupling the screen drawing element from the video conferencing. In doing so we would have a desktop app that could be used on top of, and independent of any video chat app — or it could even be used standalone.
This would give us ownership and direction to extend and enrich functionality in future. For example, we could separate each users’ drawings onto different layers, thus allowing the client to show / hide layers; have the ability to record / save drawings per layer; offer pre-defined drawing shapes etc. The ideas were bubbling!
From a high level, our MVP vision was this: Users join a video call and spin up the proposed draw-on-screen app. After joining the app, one or more of the callers can then, well, draw on their screen - and all the other members see that drawing superimposed on their screens too.
So, how did we approach it?
On the first hackathon day, after breakfast and briefings, we met for the first time as a team in person and quickly got down to discussing some of the details and direction in which we wanted to go. The team was made up of five front-end Javascript developers and one SRE engineer, so we quickly established that working in our Javascript comfort zone made the most sense. We decided our app should be a cross platform desktop app, and Electron would be a good starting point.
Next we considered the app communication conundrum. As we were aiming for a near real-time experience, the WebSockets protocol was the obvious choice — but the specific implementation and tooling was less straight forward. We could use something like Socket.IO and run it locally which would suitably simplify things for a Hackathon. Socket.IO provides the concept of rooms to isolate multiple users and provides server broadcast functionality. It also provides a JS client (for the browser) and server (NodeJS) — and running the server locally would mean we could easily achieve a real-time system and not have to worry much about latency.
But of course this is not how it would work in the real-world, so we quickly put the kibosh on the local server approach.
Instead we opted for something a little more challenging using an AWS stack: API GW -> WebSockets -> Lambda -> DynamoDB
On the plus side, this approach includes scaleable services and works for users on different networks. On the negative we would have to consider multiple-room functionality, connection persistence, public network and lambda latency and potential network throttling. In hindsight this was quite ambitious, but we also felt this was in the full spirit of a Hackathon.
Undeterred, we split our team up so we could work effectively in parallel. A few of us worked on setting up the AWS stack, someone on the Electron app, a couple on the front-end React app, and one person on a Terraform script to spin up the stack from code.
To facilitate the split we decided to agree a contract on the data shape. This is the data sent to initialise / join a call, and during the sending / receiving of drawing data. Once this was established, we worked quite effectively in a degree of isolation — although there was a healthy amount of excitement shouted across the table at every milestone reached and some good swarming when we needed more minds on a problem.
We decided early on to use P5, a Javascript drawing library to help abstract interaction with HTML Canvas and to provide a rich SDK for future extension of our UI. For now, we wanted a user to be able to change their pen colour, and display drawings on screen for a specified amount of time before fading away. We also wanted multiple users to draw simultaneously i.e handle multiple simultaneous isolated drawings on each client.
We discovered the AWS API GW throttling limits very quickly (on a free tier account), as sending each individual mouse movement coordinate in an individual network request was not going to be scaleable (or necessary). Our solution was to package the mouse movement coordinates from when they started drawing a shape (mouse down) to when they finished (mouse up). This reduced the network requests enormously, and within our acceptance.
To test the basic functionality and our API to join and draw, we used wscat, a command line utility to interact with WebSockets.
So at the end of approximately 10 hours of hackathoning over 2 days, what were our successes and where could we have improved?
As we were testing mostly in isolation, it was quite late in the day when we realised (after integrating all the elements together) that we needed a form of persistence for the web socket connections to account for lambda concurrency. We started working on DynamoDB to persist the connections, but sadly ran out of time!
This scuppered our initial idea for the final presentation — where we had dreamy grand plans of offering the judges our laptops and letting them doodle on a live call to each other, whilst watching our fellow competing hackathoners bask in our boldness — but it wasn’t to be, and we resorted to playing back a well received recording for the demo instead.
So was our Digital Draw on Screen hackathon a success? Yes! And we are immensely proud of what we achieved in such a short amount time: an overall working end-to-end solution that allows multiple users to join a call and draw simultaneously over public network using a scaleable AWS stack!
And if you haven’t noticed it by now, let me highlight our nickname for our Digital Draw on Screen app — DDoS!
Addendum: Shortly after the Hackathon we added more UI functionality, finalised the connection persistence and now we’re creating a backlog to take DDoS forward. Who knows, you might one day be using it yourself as an Open Source project.
Want to know more?
If this article has inspired you, and you want to know more please reach out to us on our various social media channels.
If you want to work with us, find us on LinkedIn and drop us a message, we would love to hear from you! ✉️
