Part 1 | Part 2 | Part 3 | Part 4 | Part 5 |
Table of Contents
Real-time collaboration is now more reality than ambition, but several obstacles remain, particularly in the form of peer-to-peer collaboration when many collaborators are involved. While Yjs, an open-source framework for real-time collaboration, and WebRTC, a new protocol for peer-to-peer communication now seeing wide browser support, permit editorial collaboration between peers in a graceful way, things get more complicated when many users enter the picture. Nonetheless, thanks to y-webrtc, the Yjs integration with WebRTC, we can enable not only effective resolutions to complex situations but also a variety of fascinating applications and collaboration use cases.
Not long ago, your correspondent (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) sat down for an exciting hour of conversation with fellow Tag1 colleagues Kevin Jahns (Real-Time Collaboration Systems Lead at Tag1 and founder and project lead of Yjs), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), and Michael Meyers (Managing Director at Tag1) about how the combination of Yjs, WebRTC, and y-webrtc can yield considerable fruit in enabling peer-to-peer collaboration, especially in editorial settings. In this multi-part blog series, we explore how these three technologies interact to enable decentralized applications, and in this fourth installment of the series, we focus on the distinction between viewers and collaborators as well as some of the exciting potential applications for y-webrtc in the wild.
Handling viewers versus collaborators
One question that arises frequently in response to y-webrtc's limit of 20-30 collaborators simultaneously connected to one another is whether this limit entails solely collaborators or also those who are merely viewing the document as watchers. In other words, is there a limit on the number of watchers that can help raise the threshold of 20-30 collaborators editing documents directly? Unfortunately, because peer-to-peer collaboration requires that all users have direct connections with one another, there is no such difference.
In Google Docs, for example, as of only a few years ago, only ten or twenty collaborators were possible on the same document. Above a fixed number of collaborators, according to Kevin, Google Docs would only allow additional entrants into the document to view the document and watch changes. Adding still more collaborators above that threshold will eventually reach another limit in the number of document viewers. Once you exceed that maximum limit, collaborators will only see flashes of content in the document. Though y-webrtc has the same mechanism of limiting collaborators, there are other hard caps on the number of collaborators within the browser itself. Google Chrome, for instance, will only allow up to 120 simultaneous connections and will throw errors past that threshold.
If you are lucky, however, and the connections are both still alive and lack fragmentation, y-webrtc should still function normally, though this high quantity of connections is of course not recommended. In the scenario where you require many more collaborators than y-webrtc — or modern browsers, for that matter — can support off the shelf, Kevin recommends implementing a central server and using y-webrtc up to a certain number of collaborators before connecting to a server-side implementation such as a WebSocket server.
A different algorithm for viewers?
During our webinar together as part of the Tag1 Team Talks series, Michael recommended that organizations interested in implementing peer-to-peer collaboration and adopting tools like Yjs and WebRTC carefully consider the number of active collaborators they will need to support and falling back to a centralized server when the aforementioned thresholds are exceeded.
Nonetheless, Fabian recommends that further performance optimizations can arise from establishing a clear distinction between active collaborators and passive watchers by providing different algorithms for both types of users. This could entail the creation of a signaling server that would allow you to select any peer arbitrarily and to listen to updates from that peer through a subscription. Because every update is sent to every peer in Yjs, as we saw in previous explorations of Yjs, you can listen to any single peer while twenty other collaborators are working, all without interrupting ongoing work in the document. Such differentiated algorithms are technically feasible but are not yet implemented.
Another scenario that illustrates the challenges surrounding such peer-to-peer collaboration is that commonly seen in large media and publishing companies where many authors need to collaborate simultaneously on many large documents. An individual organization in the media and publishing vertical would rapidly exceed the limit of 20-30 collaborators outlined in the previous installment in this series. In order to scale to thousands of collaborators, Fabian and Kevin recommend that such organizations use their commonly ample budgets to provision WebSocket servers so that clients can reach and share data rather than leveraging the browser-based WebRTC protocol.
Applications for y-webrtc
What are some of the fascinating use cases available to users of y-webrtc who are interested in real-time collaboration in a decentralized fashion? In this section, we outline some of the possible use cases made possible by y-webrtc, including as a drop-in solution into existing CMS ecosystems like Drupal and WordPress and as an enabler for collaboration in a variety of situations far outside the realm of mere textual content.
A drop-in solution for collaboration
Thanks to y-webrtc's design, you can leverage y-webrtc as a drop-in solution in your existing web application. Now that WebRTC support is available in all modern browsers, dropping it into an editorial interface will "just work," and full peer-to-peer collaboration will be supported. But perhaps more interesting to many readers of this blog is whether WordPress and Drupal could potentially support real-time peer-to-peer collaboration in the future by leveraging y-webrtc as a dependency.
For instance, Michael expresses his desire to see native peer-to-peer collaboration available in Drupal in the form of a Drupal distribution with y-webrtc included, as this would permit users to access collaborative interfaces without downloading or requiring a contributed module. If you have a special rich text editing solution that supports peer-to-peer collaboration such as ProseMirror, which Tag1 recently chose in an evaluation for a Fortune Top 50 company, you can simply enable this module, utilize one of the public signaling servers configurable in the module, and start a new collaborative document. This document would then automatically connect to a signaling server, and another collaborator could enter the document and connect to the same signaling server. The two collaborators would then work together on the document as if there were no server.
Kevin noted that this would require a public signaling server that is always available and cited a strong need in the collaboration space for an organization to manage and scale up public instances to enable many more users to access collaborative documents. Another option, however, that ecosystems like Drupal and WordPress could undertake is to implement the signaling server implementation in other languages such as PHP. After all, Kevin states, his core signaling server code consists of only a hundred lines, enabling other developers to reimplement the approach in their preferred language.
How signaling servers could function in PHP
For server-side languages like PHP, there are techniques available to make signaling servers possible with long-polling, in which we use one connection for a long period of time, and as soon as data arrives, the data is written to the application. Using frequent polls instead of long-lasting connections can also work remarkably well thanks to content delivery networks (CDNs) like Akamai or Fastly. Moreover, polling is efficient, because if cached data is invalidated, it can be expired and fetched again by the server. Fortunately, polling is much more feasible than it was a mere decade ago when combined with robust caching and CDNs.
In the Drupal ecosystem, developers can use the cache tag system and invalidate caches such that the server will receive only a single request once data expires, and this is a novel approach to polling implementations in today's web development landscape. Historically, many formerly claimed that polling was inadequate for robust performance, but with the proliferation of CDNs at a large scale and the implementation of a simple PHP client, near-real-time signaling can occur without any overhead on the server, if the cache is expired as soon as data updates occur.
Conclusion
The world of real-time collaboration is undergoing significant change as technologies like WebRTC and Yjs, an open-source framework for real-time collaboration, enter the fray. Thanks to Yjs' integration for WebRTC, y-webrtc, anyone can now support up to 20-30 collaborators on a single document without relying on a central server. In addition, due to the widening browser support for WebRTC, CMS ecosystems like Drupal and WordPress will doubtlessly find the growing range of possibilities and potential use cases fascinating for their futures. Peer-to-peer collaboration is the future, and y-webrtc is paving the way.
In this blog post, we focused our attention on the scalability of y-webrtc and whether a differentiation between passive watchers and active collaborators is necessary to support the needs of large enterprise organizations with thousands of editors and thousands of documents. We also devoted time to some of the potential applications for Yjs, WebRTC, and y-webrtc together. In the next — and final — installment of this blog series on peer-to-peer collaborative editing, we return to the topic of how to support decentralized collaboration in server-side environments like PHP and enumerate other exciting use cases for the sort of collaboration that these technologies enable.
Special thanks to Fabian Franz, Kevin Jahns, and Michael Meyers for their feedback during the writing process.
For more Yjs content, see Yjs - Add real-time collaboration to any application.
Part 1 | Part 2 | Part 3 | Part 4 | Part 5 |
Photo by Perry Grone on Unsplash