eLitmus Blog Building a Collaborative code-editor & Whiteboard: For tech interviews.

A Collaborative code-editor and Whiteboard aims to diversify the current interviewing scenario to Live - Coding, Sketching, Crafting, and Conceptualisation of ideas between the Interviewer and Interviewee for better communication which was until now only limited to Video and audio chats. The Blog Blueprint: Need for collaboration: Unveiling the Why Cracking the Code: Research and Concluded Solutions     Collaborative conflict management.     Code-editor research     Existing code-editors     Existing whiteboards Feature Showcase Architecture Actors: Use case diagram Dockerization, Deployment and scale Conclusion Need for Collaboration: Unveiling the Why In the post-pandemic landscape, the majority of tech interviews and initial screening rounds have transitioned to virtual formats through platforms like Google Meet, Zoom, or Microsoft Teams. While these platforms excel in facilitating video and audio interactions, they fall short when it comes to assessing candidates’ coding problem-solving skills in a live, interview-pressure setting. Typically, recruiters resort to screen sharing candidates’ local code editors, but this approach presents limitations. Recruiters lack the ability to actively edit the code or navigate through different code files seamlessly. Simple tasks such as pointing out errors, saving code for later review, brainstorming designs, and optimizing code quality become cumbersome, relying on manual instructions for candidates to scroll up or down. As a result, the demand for a collaborative code editor and whiteboard becomes not just beneficial but critical in addressing these challenges efficiently. Cracking the Code: Research and Concluded Solutions What if two users press two different letters on the same line at the exact same time? This conflict is a major problem that all collaborative and distributed softwares have to address. Therefore, when the user makes a change to the document that change needs to be synchronised with other users as well and if the user has to wait for this synchronisation for every letter they type this will make the application very slow. So in order to get a near real-time collaborative editing experience every client maintains a local replica of the document and the main issue now is just to maintain consistency with other clients local replica. Consider the following example - In an empty line, Alice inserts letter ‘A’ at index 0 and Bob inserts letter ‘B’ at index 0 at the exact same time. Now how should we combine these changes together? Should we prefer Alice’s changes over Bob’s or vice-versa? Well there is no logical answer and quite frankly it doesn’t matter, what actually matters is that at the end of combining these operations it should “Converge to an identical state� i.e both Alice and Bob should get the same text as soon as possible and if they are not satisfied they will re-edit just like in git you would have merge conflicts and you would have to merge manually but here we can automate this merging using various concurrency control and consistency models. There are two conceptual protocols when dealing with such problems - Consensus based protocol - Pick one & reject the rest. In this case it will select any one between Alice and Bob, thereby losing one client’s data completely. This is mainly used in decentralised blockchain applications. Collaboration based protocol - Merge & Keep them all. But that’s not the end of the story as we can take advantage of commutative operations like consider a double insertion situation - the text initially is “APP�, Alice inserts “H� at the beginning and Bob inserts “Y� at the end at the exact same time as Alice. In such a situation there is a line conflict but since insertions at different positions are commutative we can merge these operations automatically to get the final text “HAPPY�. Thereby not discarding Alice’s changes or Bob’s changes, providing a real-time conflict-free editing experience and there is no need for someone to manually merge these changes for us. The concurrency control algorithms are widely studied for collaborative tools and a lot of research is currently going into such algorithms to attain distributed concurrency. The two most widely used ones are OT and CRDT. Operational Transformation (OT) Also known as Event passing. Any key event happening on the client-side will be sent to the server. Events can be inserting/deleting a character. The operation received by the server from the client is transformed against its operation which results in a new operation to be performed on the client-side. OT implementations are used in Google docs and many more such collaborative applications pre-2018 ( before CRDT optimisations started to outperform their OT counterparts ). This can be better understood with the help of an example - There are many models based on Operational Transformation that are used in prod addressing different issues and there is a plethora of dense academic research whose references can be found in the Documentation. As this blog is written mainly from a developer point of view but academic references are also mentioned wherever needed. Conflict-free Replicated Data Type (CRDT) CRDT works on two core principles - Commutative - Re-ordering different operations will not change the final result. Idempotency - No matter how many times an operation is performed the final result remains the same. Here, every character in the document is assigned a unique ID, and when a new character is inserted, the new character would get an ID based on the average of its neighbours (ideally could even take non-integer IDs), which helps to make the algorithm less complex in conflict resolution. Just like OT had its own various models, CRDTs too have different implementations developed & optimised over time. To get a conceptual understanding consider the example below - using Lagoot’s CRDT Algorithm CRDTs have a lenient approach to the order of operations. In theory, this reduces the design complexity of distribution mechanisms since there is no need for strict serialisation protocols. By tolerating out-of-order updates, the distribution mechanism has to meet simpler integrity guarantees. OT Vs CRDT: Final Solution CRDTs serve our requirements much better because of these two main reasons - Speed: CRDTs are much much faster than many OT implementations applying operations should be possible with just a O(log(n)) lookup. But in the past the main problem was the large memory overhead. Which is now resolved after significant optimisations in YJS CRDT implementation. ( Exact benchmarks are provided in the references section of Documentation. ) Flexibility and Usability: CRDTs support a wider range of data types. Compared to the OT library, which requires a thorough modelling of business logic as different types of operation data structures, when using the CRDT library, you only need to perform the same operation on common data structures, such as Map and Array. Code-editor Research The main code-editing component libraries explored were - CodeMirror 6 Monaco Editor Ace Editor Out of which CodeMirror 6 was selected due to the following reasons - Highly modular and lightweight: seamless integration of only the necessary components, allowing for a tailored and resource-efficient implementation. Has a modern, extensible API with excellent documentation. Is easy to customise, style, and reconfigure. Existing Browser based code-editors Here are some more projects and companies whose products were researched thoroughly, but to prevent this blog from becoming super lengthy only the names with references are mentioned and all the other details are mentioned in the Proof Of Concept given alongside the Documentation: Gitlab Web IDE Code-server Replit Codeanywhere Codepen Codetogether Github.dev Github Codespaces Vscode.dev Existing Whiteboards tldraw Docs Github 22k+ stars 130 contributors actively maintaining. Well funded $2.7M seed Supports YJS ( Shared-editing framework ) Easy to integrate. Other options researched: Excalidraw fabric.js react-canvas-draw Feature Showcase Client Workspace Multifile Navigation & Room info Whiteboard All features are satisfied as specified in FRS: Collaborative Code Editor Real-time code editing and sharing capabilities using websockets. Syntax highlighting for multiple programming languages using codemirror 6 language packages. Support for multiple users editing code simultaneously using YJS shared-editing framework. Files navigator bar for multi-file editing using Depth First Search Algorithm in react. Create a new meet in just one click! Fast and low-latency using websockets + sending only new changes made to the document instead of sending the whole document each time. Modular code as specified in Architecture below. Secure groups/ rooms using YJS update serialisation. Additional features provided -     Zip downloads the entire codebase.     Pdf download all whiteboard designs.     Role management for different actors ( or users ) specified below in the use-case diagram. Whiteboard Interactive whiteboard for visual collaboration and problem-solving using tldraw. Drawing tools, shapes, and text annotations. Real-time updates for all participants using YJS. Ability to save whiteboard content by downloading a local pdf copy: Simply by pressing Ctrl + P. Additional features provided -     Upload any new shape or image for UML diagrams, flowcharts or any other design pattern.     Dark mode and multi page editing.     Set custom opacity, texture patterns and border levels.     Use laser pointers for b