Collaborative form editor using WebSockets | Web Sockets in Golang and React
Want real-time communication across clients and asynchronously handle every incoming event across client modules and broadcast it to multiple registered services without long polling for the data? Want to create a chatting application? Websockets might just be your best friend for this particular use case!
Psst. You are at the first post of a three-part series if you are interested in deep diving in one of the technically intensive posts, feel free to check out part 2 and (or) 3.
- Collaborative form editor using WebSockets | Web Sockets in Golang and React
- Designing a WebSocket server in Golang | Reformers backend implementation strategy
- Designing a WebSocket client with notifications in ReactJS | Reformers frontend implementation strategy
What is WebSocket? 🤓
In Wikipedia terms, WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection, which is the best definition one could give, but allow me to water it down a little.
I’ll be citing this amazing blog written by Matt West[1] for Treehouse
WebSockets provide a persistent connection between a client and server that both parties can use to start sending data at any time.
So, for real-time interaction between two parties, you don’t need to periodically fetch data via GET requests or long poll the server for any updates, the server will push it to you using the established TCP connection directly. You can read the Treehouse blog link given above to understand the entire working of WebSocket protocol as it demands an entire post of its own.
Pros and Cons of WebSockets
Cons
Bad things first, once your connection is terminated, you can’t recover it automatically. You have to periodically check for connection establishments (a cron checker would be nice here)
Pros
- It keeps a unique connection open, hence eliminating the latency issue
- WebSockets generally won’t use XMLHttpRequest and headers won’t be sent every time we need to get more information from the server.
- You don’t need to send multiple HTTP requests to fetch new messages, hence no polling is required ❤
What was your product again? 😮💨
Glad you asked. Allow me to introduce you to a fun project named Re-Formers. A collaborative form editor with live interaction user interaction, something like google forms minus the vast variety of question format (and the support, of course).
Let me explain, it’s a simple room where you can insert a question, edit existing ones or delete the ones you don’t like. A client will log you into the room with a color + name combination for 30 minutes.
- Create a new question with a title.
- Editing the existing questions written by other members
- See the version history of a question and check what was changed when.
- Delete an existing question.
What it can’t do is saving the form and persist actual user login authentication and accept responses for the form (because the aim is to provide a working UI and the user broadcast feel, hence no databases used)
But we have Google Docs / Sheets / Slides etc too so why only forms? 📃
Document editing and synchronization have been performed millions of times before on the web. Slides and Sheets are more complex use cases when your entire goal of making the product is trying out WebSockets, and chatting applications are again common picks for beginner projects, hence, the google forms.
Current Engineering (Proof of Concept level) 👷
The current high-level workflow can be seen in the diagram depicted below.
Multiple React JS Clients connect to a single Golang server (maximum 30 at once for now) and they all interact to a single list of questions and perform the desired operations or just watch as the room unfolds, while the server broadcasts the updates in real-time.
Destination Product Architecture 🏗️
The diagram below is the final architecture this product would like to reach, even though it’s a far cry from the current arch.
A client will request an available TCP connection to a deployed pod and once the user is authenticated, a secure WebSocket connection is established to a certain deployed server, where the client will be granted entry to a form editing room. All the data will be persistent and stored in a database (and the updates will be written in batches, with a consumer built specifically for that role in Redis)
What’s Further? 🍂
You can find the technical implementation of the project in-depth for environment-specific components, i.e. the client-facing component and the server in the next two blogs.
This post was to elaborate on the basic layout of the Re-Formers project and what it’s all about, and why WebSockets make sense to be used instead of classic REST APIs.
