I’m curious about the tech behind Google Drive’s real-time updates. When multiple people work on a doc at once, it’s super smooth. But I can’t figure out how it works.
I checked the Network tab in Chrome DevTools. No WebSockets. Instead, I see lots of AJAX calls with ‘bind?’ or ‘save?’ in the URL. The ‘save?’ POSTs happen when I type. Makes sense.
But here’s the weird part. When someone else types, the latest ‘bind?’ GET call stays open. The data transferred keeps growing. It’s not long-polling or server-sent events.
Anyone know what this is called? How can I build something similar? I’d love to try it out in my own project.
// Example of how I might start implementing this
function openLongRunningConnection() {
const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/bind?userId=123', true);
xhr.onprogress = function() {
// Handle incoming data
console.log('New data:', xhr.responseText);
};
xhr.send();
}
Google Drive’s instant collaboration is likely powered by Operational Transformation (OT), a complex algorithm designed for real-time collaborative editing. It works by transforming concurrent edits to maintain consistency across all users’ views.
The long-running GET requests you’ve observed are probably using a technique called ‘long polling’ or ‘comet’. This allows the server to push updates to clients efficiently without constantly opening new connections.
To implement something similar, you’d need to set up a server that can handle concurrent edits, apply OT, and push updates to connected clients. On the client-side, you’d maintain an open connection to receive these updates.
It’s a challenging system to build from scratch, but there are open-source libraries like ShareDB or Yjs that can help you get started with real-time collaboration features in your own projects.
yo, google drive’s collab magic is pretty sick. it uses this thing called operational transformation (OT) to keep everyone in sync. basically, it takes all the changes and tweaks em so they work together smoothly.
the long-running requests ur seeing? that’s probly a comet-style setup for pushing updates. clever stuff.
building ur own would be a pain, tho. maybe check out sharedb or yjs if u wanna give it a shot
I’ve actually worked on a similar system before and it appears that this method leverages what is known as chunked transfer encoding. Essentially, the client opens a long-running GET request to the server, and instead of receiving a fully formed response, the server keeps the connection open and sends data in segments as it becomes available. This allows the client to process incremental updates in real time without the need for constant polling. Although it might seem less direct than WebSockets, the technique fits well within standard HTTP protocols and can be adapted by configuring the server to stream responses and by handling the data via the onprogress event in the client.