Real-Time Sync: From HTTP to Reactive Backends

The HTTP Problem: Request-Response Is Not Real-Time  

Browsers talk to servers over HTTP. This protocol has been the backbone of the internet since 1991, but it was never designed for real-time applications.

HTTP rests on one simple principle: request-response.

1. The browser asks: "Give me this data."
2. The server answers: "Here is the data."
3. The connection closes.

Why is this problematic?  

HTTP was built for the first case (static content for a single user). For the second case (collaborative real-time apps), it falls short at a fundamental level.

The core HTTP limitations:

1. One-way communication: only the client can initiate requests, never the server.
2. Request-response paradigm: every interaction has to be started by the client (even over Keep-Alive connections).
3. No server push: the server cannot speak up to say, "Hey, there are updates over here!"
4. Polling required: the browser has to keep asking whether anything has changed.

Table of Contents  

An Everyday Example: The Shopping List  

Situation: You and your partner both have a paper shopping list.

Result: you end up with twice as much milk, because your lists were never in sync.

Apps built on HTTP have exactly this problem.

The Same Problem with Apps  

The Three Main Problems  

How do developers solve this problem today?  

Developers fall back on three tricks to bend HTTP into a real-time tool anyway. All three take a fair amount of work to build:

// The browser asks for new data every 5 seconds
setInterval(async () => {
const response = await fetch('/api/project/status')
const data = await response.json()
updateUI(data)
}, 5000) // Every 5 seconds

The Core Problem  

All three are workarounds, nothing more. Developers burn a lot of time papering over the weaknesses of HTTP instead of building new features for the app.

The Solution: Reactive Backends  

The New Principle: Automatic Updates  

Imagine a shared shopping list on your phone. Your partner crosses off "milk", and the change shows up on your phone straight away. You never have to ask; it just happens.

How It Works – Example: A Shared Shopping List  

1. You open the app and see the shared shopping list.
2. The server makes a note: "This person is viewing the shopping list."
3. Your partner crosses off "milk": the server pushes the change to you automatically.
4. Your app updates the list on its own, and you see the milk crossed off straight away.

Convex: A Practical Example  

Watch

Play video

Loads YouTube & sets cookies

Click loads YouTube (Privacy)

Convex rests on three key capabilities:

1. Automatic Memory (Reactive Queries) – the server knows who needs which data
2. All or Nothing (Transactional Mutations) – changes are guaranteed to land in full
3. Always Connected (Real-time Subscriptions) – a persistent connection with no code on your part

Function 1: Automatic Memory (Reactive Queries)  

The problem: the server needs to know who to notify when something changes.

The solution: Convex automatically keeps track of who is viewing which data.

Back to the shopping list: when you and your partner open the shared list, the server notes who is looking at it. So when someone crosses off "milk", only those two browsers get notified and updated, not everyone else using the app.

Code Example  

// Convex Query: Automatic Tracking
export const getShoppingList = query({
args: { listId: v.id("shoppingLists") },
handler: async (ctx, { listId }) => {
  // Convex automatically remembers:
  // "This browser is looking at this shopping list"
  const list = await ctx.db.get(listId)
  return list
},
})

// In the browser: Automatic updates
const shoppingList = useQuery(api.lists.getShoppingList, { listId })
// When someone crosses off "milk", the display updates automatically!

Function 2: All or Nothing (Transactional Mutations)  

The problem: what happens if something goes wrong halfway through a change?

The solution: with Convex, the rule is simple: either everything succeeds, or nothing does.

Everyday example:

Picture a money transfer:

1. Take money out of account A
2. Put money into account B

Where is the disaster? If step 1 succeeds but step 2 does not, the money simply vanishes.

An atomic transaction means:

• Either BOTH steps happen
• Or NEITHER of them does
• Never just one of the two.

Code Example  

// Convex Mutation: All or Nothing
export const checkOffItem = mutation({
args: { 
  listId: v.id("shoppingLists"),
  itemName: v.string(),
},
handler: async (ctx, { listId, itemName }) => {
  // Everything together is an atomic transaction
  const list = await ctx.db.get(listId)
  
  if (!list) {
    throw new Error("Shopping list not found")
  }
  
  // Find item

The four guarantees (the ACID principle):

• Atomicity (indivisible): all or nothing
• Consistency: the data always stays valid
• Isolation: concurrent changes do not interfere with one another
• Durability: successful changes are stored permanently

Function 3: Always Connected (Real-time Subscriptions)  

The problem: how can the server tell you the moment something changes?

The solution: Convex holds a persistent connection open (much like a phone call).

The clever part about Convex: you never have to deal with WebSockets yourself.

Convex sets the open connection up for you. You write your app as normal, and the updates simply arrive.

Code Example  

// This is what you have to write (very simple!):
import { ConvexProvider, ConvexReactClient } from 'convex/react'

const convex = new ConvexReactClient(process.env.NEXT_PUBLIC_CONVEX_URL!)

function App() {
return (
  <ConvexProvider client={convex}>
    {/* All components here receive automatic updates */}
    <ShoppingListApp />
  </ConvexProvider>
)
}

// In your component: Query data normally

You do NOT have to write any code for:

• Opening a WebSocket connection
• Monitoring the connection
• Reconnecting after a drop
• Receiving updates
• Updating the UI

Convex handles all of it automatically.

Comparison: Old vs. New  

Here are the differences side by side:

Self-Hosting and Data Sovereignty  

Alongside the managed cloud infrastructure, Convex also offers self-hosting for companies with specific compliance, data protection, or governance requirements.

The open-source backend can run on your own infrastructure. Full control over where your data lives matters above all for regulated industries and GDPR-compliant architectures.

Feature scope: the open-source backend includes all the core features (Queries, Mutations, Actions, Realtime Subscriptions, Transactions).

GDPR considerations for the Managed Cloud: Convex is a US company. Using the hosted cloud means a third-country transfer, which calls for a Data Processing Agreement (DPA) and an assessment of the Standard Contractual Clauses (Art. 46 GDPR). For many applications that is perfectly adequate; it only becomes a sticking point with highly sensitive data (health or financial records) or where authorities and regulated industries impose strict on-premise requirements.

Recommendation: for most web apps (B2B SaaS, content platforms, e-commerce), the Managed Cloud with a DPA is fully GDPR-compliant. Self-hosting mainly pays off for banking and healthcare, public authorities, and companies with an explicit on-premise policy.

The Transition: From Old to New  

How complicated is the transition?  

Good news: you do not have to change everything at once. You can move across step by step.

Let's look at an example: just how much simpler does the code get?

Before: With the Old System (HTTP)  

What's wrong here?

Code Example  

// Old system: Far too complicated!
// Backend (Express.js)
app.get('/api/projects/:id', async (req, res) => {
const project = await db.projects.findById(req.params.id)
res.json(project)
})

app.patch('/api/projects/:id', async (req, res) => {
const updated = await db.projects.update(req.params.id, req.body)
res.json(updated)
})

// Frontend (React + Redux)
const ProjectView = ({ projectId }) => {
const dispatch = useDispatch()

After: With Convex (much simpler!)  

The difference is dramatic.

In short: instead of writing hundreds of lines of code, you reach for useQuery and useMutation, and Convex handles the rest.

Code Example  

// Convex Backend (much simpler!)
export const getShoppingList = query({
args: { listId: v.id("shoppingLists") },
handler: async (ctx, { listId }) => {
  // Simply fetch data - Convex automatically remembers
  // who is looking at this list
  return await ctx.db.get(listId)
},
})

export const checkOffItem = mutation({
args: { 
  listId: v.id("shoppingLists"),
  itemName: v.string(),
},

Speed Comparison (with Numbers!)  

Imagine 1,000 people using your app at the same time.

Limitations and Boundaries  

Internet Connection Required  

Reactive backends need a live connection to the server. Offline-first apps call for extra architecture (local caching, sync conflict handling).

Migration Effort  

Existing systems will need refactoring, so an incremental migration is the safer route.

Offline support: hybrid setups with local state management (LocalStorage, IndexedDB) and sync-on-reconnect are possible, but take extra work to build.

Conclusion and Recommendation  

Our take: for real-time applications, reactive backends are not optional. The question is not whether you will make the move, but when.

Further Links  

• Convex Documentation – the official docs, with tutorials and examples. There is a free tier you can try.
• The Reactive Manifesto – the founding principles of reactive systems (a little technical, but well explained).
• RFC 6455: WebSocket Protocol – the official technical spec for WebSockets (for the deeply curious).