DEV Community: Freddy Carrillo

Centralized vs. Decentralized: Why Modern Collaborative Tools choose CRDTs

Freddy Carrillo — Thu, 28 May 2026 20:16:55 +0000

Real-time collaboration works like magic until two users edit the same line simultaneously. Under the hood, an algorithm must decide whose change wins and get it right every time.

Software engineers faced this problem and two major approaches emerged: Operational Transforms (OT) and Conflict-Free Replicated Data Types (CRDTs). The choice determines how your application scales.

OT requires a centralized system to have total ordering of operations to transform correctly. The core issue is when two servers receiving the same operations in different orders, produce different results. In addition, the number of transformation combinations grow exponentially as users grow, making edge cases and divergence common.

On the other hand, CRDTs are a decentralized data structure which was design to eliminate the need for a central coordinator. CRDTs achieve strong eventual consistency with its metadata, a unique identifier, relative position from peers and a timestamp.

Strong eventual consistency is achieved mathematically:

Commutative - changing the order of operations does not change the result.
Associative - receiving operations in different groups will not change the result.
Idempotent - receiving the same operation twice will give the same result.

In the architecture of my Collaborative-Code-Editor, choosing CRDTs over OT gives me the advantage of not depending on a server for my data conflicts. Using Yjs as my CRDT library, not only fixes the problems OT arises but comes with additional features. A unique identifier keeps track of the characters' identity, and relative addressing that points to the character position in my code editor. The relative position matters because when working with other real-time data types that use indices, you will encounter stale data when inserting. In other words, when two users add character at the same time it will be inserted relative to the left and right parents rather than its place in the document.

Teams that build collaborative tools need to consider how to solve conflict data. CRDTs stand out as this algorithm that in addition to solving OT's scale issues, it lets developers not depend on a central server. In today's world where small teams and solo developer are emerging, they should consider using CRDTs if they need to scale without a central coordination server.

Centralized vs. Decentralized: Why Modern Collaborative Tools choose CRDTs

Freddy Carrillo — Thu, 28 May 2026 20:16:55 +0000

Real-time collaboration works like magic until two users edit the same line simultaneously. Under the hood, an algorithm must decide whose change wins and get it right every time.

Strong eventual consistency is achieved mathematically:

Commutative - changing the order of operations does not change the result.
Associative - receiving operations in different groups will not change the result.
Idempotent - receiving the same operation twice will give the same result.

Solving Cross-Origin Cookies

Freddy Carrillo — Mon, 16 Feb 2026 18:15:15 +0000

Your chat app works locally but your REST API and WebSocket authentication fail in production. Here's why.

I deployed with Vercel (frontend) and with Render (backend). Deploying on different domains makes for many adjustments during development when dealing with cookies. Without the correct configuration, my app failed to send cookies with HTTP requests. This created a problem, I had dual authentication: the HTTP Only cookies acted as my main security, which was set to protect all my REST API endpoints. My WebSocket authorization was protected by the same method, checking the HTTP only cookie, but also relied on its own token to establish a connection. Both expected the same token but delivered through different mechanisms.

My HTTP requests were not receiving the cookie, making my REST API authentication fail. After some research, I changed the cookie's settings:

// From:
sameSite: 'strict'
// To:
sameSite: 'none'

Allowing the cookies to be sent and received with all third-party requests which includes cross-origin cookies. To secure the cookies, I set the secure option to be true to only allow cookies from HTTPS requests. Testing it in deployment fixed the REST API authentication, but failed when the browser settings blocked third-party cookies. This also made WebSocket not connect, since there was no cookie to pass and allow.

Given that constraint, my first attempt was making my frontend proxy the API endpoints. This implementation made domain the same-origin in the browsers perspective, by accessing my API via the client URL. Now the browser saw my API as the same origin, eliminating any cross-origin issues.

// Before proxy
API_URL="https://message-app.render.com/:path"
// After proxy
API_URL="https://message-app.vercel.com/:path"

Each HTTP request is from the same origin, Vercel acts as the middle man, changing the API URL. To add, I needed to set a parameter (withCredentials) in the socket's client configuration to tell the browser to include cookies with the WebSocket handshake.

// Pass token via HTTP requests
const socket = io(URL, { withCredentials: true });

After deployment, the browser now allowed for users to be authenticated, but it was still not allowing my cookies to be passed to the WebSocket connection, and that made sense after I understood why.

Even in a properly configured cross-origin environment, some browsers still do not send cookies with WebSocket handshakes. A WebSocket handshake is when the HTTP connection upgrades, allowing users to communicate in real time. WebSocket connections upgrade from the HTTP to the WebSocket protocol. While my REST API requests went through Vercel's proxy (same-origin), the WebSocket upgrade connected directly to Render (cross-origin). This made the browser not allow WebSocket access to cookies, so my authentication failed.

The solution was to store the token in memory and attach it to Socket.io's parameters, which would be extracted in authorization.

// Fetch token from authenticated endpoint, pass explicitly
const socket = io(URL, {
  auth: { token: authToken }
});

With AuthContext already established with React's Context, on each page load the context will send an HTTP requests to the backend with the HTTP Only cookie attached. Rather than exposing the 5-day HTTP Only cookie token, I create a separate 1-hour token specifically for WebSocket authentication. This token is fetched from an authenticated endpoint (which validates the cookie), stored in memory, and passed via Socket.io's auth parameter. If an attacker somehow steals this token via XSS, their access is limited to 1 hour and cleared on page refresh.

This dual authentication strategy maintains security while ensuring cross-origin compatibility. If you're deploying a real-time application with frontend and backend on different domains, you'll likely need a similar approach. Browser cookies won't send credentials with WebSocket handshakes, regardless of your CORS configuration.