Migrate from Firebase to NoLag

Firebase Realtime Database and Firestore give you realtime by syncing stored documents and firing client listeners when the data changes. NoLag takes a different approach: explicit publish and subscribe over topics. That difference matters for migration, so let us be clear up front about what to move and what to keep.

What to migrate, and what not to

NoLag is a messaging layer, not a database. If you use Firebase purely as a realtime signal, presence, or message bus, NoLag replaces that cleanly and gives you more control over delivery. If you use Firebase as your system of record, keep a database. Migrate the realtime and pub/sub usage to NoLag, and let your data live wherever suits you. Many teams end up with NoLag for the live layer and a database of their choice behind it.

Why teams move the realtime layer

• Explicit pub/sub instead of modelling every realtime feature as a change on a stored document.
• Database-agnostic: add realtime to any stack rather than standardising on Firestore.
• Blueprint SDKs for chat, notifications, dashboards, and tracking.
• A coordination layer for AI agents on the same platform.

Concept map

Before: Firebase Realtime Database

import { getDatabase, ref, onValue, push } from 'firebase/database'

const db = getDatabase()
const messagesRef = ref(db, 'chat/general/messages')

onValue(messagesRef, (snapshot) => {
  console.log('Data changed:', snapshot.val())
})

push(messagesRef, { text: 'Hello!', sender: 'user-123' })

After: NoLag

import { NoLag } from '@nolag/js-sdk'

const client = NoLag('your_access_token')
await client.connect()

const room = client.setApp('chat').setRoom('general')
room.subscribe('messages')

room.on('messages', (data) => {
  console.log('Message received:', data)
})

room.emit('messages', { text: 'Hello!', sender: 'user-123' })

The key shift is from "write to a path and listen for changes" to "publish an event and subscribe to it." You send exactly the message you mean, rather than reshaping your data model so that a write triggers the right listeners.

Access control

Firebase security rules become per-topic ACL in NoLag, tied to a typed actor and enforced at the broker rather than written in a rules language. A connection authenticates with an actor token, and browser clients use short-lived JWTs (client tokens) your backend signs with a project signing key.

Next steps

• Follow the 5-minute quick start.
• See the full NoLag vs Firebase comparison.
• If you are keeping a database, use NoLag alongside it for the live layer only.