Real-time Synchronisation for Web Apps: From HTTP to Reactive Backends

The HTTP Problem: Request-Response is not Real-Time  

Browsers communicate with servers via HTTP. This protocol has been the foundation of the internet since 1991 – but it was never designed for real-time applications.

HTTP is based on a simple principle: Request-Response.

1. Browser asks: "Give me this data"
2. Server answers: "Here is the data"
3. Connection is closed

Why is this problematic?  

HTTP was developed for the first case (static content for single users). For the second case (collaborative real-time apps), it fundamentally fails.

The fundamental HTTP limitations:

1. One-way communication: Only the client can initiate requests, never the server.
2. Request-Response paradigm: Every interaction must be started by the client (even with Keep-Alive connections).
3. No server push notifications: The server cannot actively say "Hey, there are updates here!"
4. Polling necessary: The browser has to constantly ask if there are changes.

Table of Contents  

An Everyday Example: The Shopping List  

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

Result: You now have double the milk because your lists were not synchronised.

Apps using HTTP have exactly this problem!

The Same Problem with Apps  

The Three Main Problems  

How do developers solve this problem today?  

Developers use three tricks to use HTTP for real-time apps anyway. All three require significant implementation effort:

// 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 solutions are merely workarounds. Developers spend a lot of time compensating for the weaknesses of HTTP instead of developing new features for the app.

The Solution: Reactive Backends  

The New Principle: Automatic Updates  

Imagine you have a shared shopping list on your smartphone. Your partner crosses out "milk" – and immediately you see the change on your phone. You don't have to ask, it happens automatically!

How it works – Example: Shared Shopping List  

1. You open the app and see the shared shopping list
2. The server remembers: "This person is looking at the shopping list"
3. Your partner crosses off "milk": The server automatically sends you the change
4. Your app updates the list by itself – you immediately see the crossed-out milk

Convex: A Practical Example  

Convex has three important functions:

1. Automatic Memory (Reactive Queries) – the server knows who needs which data
2. All or Nothing (Transactional Mutations) – changes are guaranteed to be complete
3. Always Connected (Real-time Subscriptions) – persistent connection without programming effort

Function 1: Automatic Memory (Reactive Queries)  

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

The Solution: Convex automatically remembers who is looking at which data.

Back to the shopping list: When you and your partner open the shared list, the server automatically remembers who is looking at it – and when someone crosses off "milk", only these two browsers are informed and updated, not all other users of 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 in the middle of a change?

The Solution: With Convex, the rule is: Either everything works, or nothing at all.

Everyday example:

Imagine a money transfer:

1. Debit money from account A
2. Deposit money into account B

What would be disastrous? If step 1 succeeds, but step 2 does not. Then the money is gone!

Atomic transaction means:

• Either BOTH steps occur
• Or NEITHER of the two steps
• Never just one!

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 (ACID principle):

• Atomicity (Indivisible): All or nothing
• Consistency: Data always remains valid
• Isolation: Concurrent changes do not interfere with each other
• Durability: Successful changes are permanently stored

Function 3: Always Connected (Real-time Subscriptions)  

The Problem: How can the server inform you immediately when something changes?

The Solution: Convex keeps a persistent connection open (like a phone call).

The brilliant thing about Convex: You don't have to worry about WebSockets!

Convex sets up the open connection automatically. You program your app normally, and updates arrive automatically.

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 program anything for:

• Establishing a WebSocket connection
• Monitoring the connection
• Reconnecting upon disconnection
• Receiving updates
• Updating the UI

Convex handles everything automatically!

Comparison: Old vs. New  

Let's look at the differences in a table:

Self-Hosting and Data Sovereignty  

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

The open-source backend can be operated on your own infrastructure. Full control over the data infrastructure is crucial, especially for regulated industries and GDPR-compliant architectures.

Feature Scope: The open-source backend contains all core features (Queries, Mutations, Actions, Realtime Subscriptions, Transactions).

GDPR Considerations for Managed Cloud: Convex is a US company. If you use the hosted cloud solution, this involves a third-country transfer, which requires a Data Processing Agreement (DPA) and an assessment of Standard Contractual Clauses (Art. 46 GDPR). For many applications, this is entirely sufficient – it only becomes critical for highly sensitive data (health data, financial data) or if authorities/regulated industries have 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 is primarily worthwhile for: banking/healthcare, government authorities, companies with an explicit on-premise policy.

The Transition: From Old to New  

How complicated is the transition?  

Good news: You don't have to change everything at once. You can transition step by step.

Let's look at an example: How much simpler does the code become?

Before: With the Old System (HTTP)  

What is the problem 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 huge!

In short: Instead of writing hundreds of lines of code, you use useQuery and useMutation. 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 require an active connection to the server. Offline-first apps require additional architecture (local caching, sync conflicts).

Migration Effort  

Existing systems require refactoring. An incremental migration is recommended.

Offline Support: Hybrid solutions with local state management (LocalStorage, IndexedDB) and sync-on-reconnect are possible, but require additional implementation.

Conclusion and Recommendation  

Our assessment: For real-time applications, reactive backends are necessary. The question is not "if", but "when" you will make the transition.

Further Links  

• Convex Documentation – Official documentation with tutorials and examples. There is a free version available for testing.
• The Reactive Manifesto – Basic principles of reactive systems (a bit technical, but well explained).
• RFC 6455: WebSocket Protocol – The official technical specification for WebSockets (for experts).