Push-Benachrichtigungen vs. Live-Query-Abonnements: Was brauchen Sie?

Eine Push-Benachrichtigung ist eine vom OS zugestellte Meldung, die geschlossene Apps erreicht; eine Live Query streamt Änderungen bei offener App. Sie als Rivalen darzustellen ist der klassische Fehler – sie decken disjunkte App-Zustände ab, und die eigentliche Entwurfsfrage lautet nicht “welche von beiden”, sondern “wo ist der Nutzer gerade?”. Die meisten Apps, die sich wirklich nach Echtzeit anfühlen, betreiben beides und leiten anhand dieser Antwort weiter.

Das Wichtigste in Kürze

Beide Kanäle, im Code

Das Muster, auf das nahezu jede App für Messaging, Bestellungen und Warnungen zuläuft:

// JavaScript — Back4app JS SDK: one channel per app state
// While the app is OPEN — the live query delivers the data itself
const messages = new Parse.Query('Message');
messages.equalTo('conversation', conversationId);
const sub = await messages.subscribe();
sub.on('create', (m) => appendBubble(m));   // full object, real time

// While it is CLOSED — push owns delivery: register this device
const installation = await Parse.Installation.currentInstallation();
installation.set('channels', [`user-${currentUser.id}`]);
await installation.save();
// A Cloud Code afterSave trigger sends the push to this channel —
// the OS shows the alert; the tap opens the app, which re-subscribes.

// Flutter / Dart — Back4app Flutter SDK: one channel per app state
// While the app is OPEN — the live query delivers the data itself
final liveQuery = LiveQuery();
final messages = QueryBuilder<ParseObject>(ParseObject('Message'))
  ..whereEqualTo('conversation', conversationId);

final sub = await liveQuery.client.subscribe(messages);
sub.on(LiveQueryEvent.create, (m) => appendBubble(m)); // full object

// While it is CLOSED — push owns delivery: register this device
final installation = await ParseInstallation.currentInstallation();
installation.set('channels', ['user-$userId']);
await installation.save();
// A Cloud Code afterSave trigger sends the push to this channel —
// the OS shows the alert; the tap opens the app, which re-subscribes.

// iOS / Swift — Back4app Swift SDK: one channel per app state
// While the app is OPEN — the live query delivers the data itself
let messages = Message.query("conversation" == conversationId)
let subscription = messages.subscribeCallback
subscription?.handleEvent { _, event in
  if case .created(let m) = event { appendBubble(m) }  // full object
}

// While it is CLOSED — push owns delivery: register this device
var installation = Installation.current
installation?.channels = ["user-\(userId)"]
installation?.save { _ in }
// A Cloud Code afterSave trigger sends the push to this channel —
// the OS shows the alert; the tap opens the app, which re-subscribes.

// Android / Kotlin — Back4app Android SDK: one channel per app state
// While the app is OPEN — the live query delivers the data itself
val client = ParseLiveQueryClient.Factory.getClient()
val messages = ParseQuery.getQuery<ParseObject>("Message")
messages.whereEqualTo("conversation", conversationId)

val sub = client.subscribe(messages)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, m ->
    appendBubble(m)                                  // full object
}

// While it is CLOSED — push owns delivery: register this device
val installation = ParseInstallation.getCurrentInstallation()
installation.put("channels", listOf("user-$userId"))
installation.saveInBackground()
// A Cloud Code afterSave trigger sends the push to this channel.

Beachten Sie, was jede Hälfte erledigt: Das Abonnement liefert Daten – ganze Objekte, typisierte Ereignisse, in Echtzeit. Die Installation registriert sich für Aufmerksamkeit – das Recht, den Nutzer später zu unterbrechen, über eine Pipeline, die Ihre App nicht in der Hand hat.

Zwei Zustellwege, zwei Eigentümer

Unterschiedlicher könnten die Wege kaum sein, und jede Eigenschaft in der Vergleichstabelle folgt daraus, wem die letzte Meile gehört.

Eine Push-Benachrichtigung verlässt Ihr Backend als Anfrage an ein vom Betriebssystem betriebenes Gateway – die Push-Gateways von iOS und Android (APNs, FCM) oder im Web ein Push-Dienst des Browsers, der RFC 8030 spricht. Dem Gateway gehört die Zustellung: Es hält Nachrichten für Geräte im Offline-Zustand vor, fasst sie zusammen und drosselt unter Akkudruck, weckt Ihre App oder zeigt das Banner an. Diese geliehene Macht ist der ganze Sinn – nur das OS erreicht einen Prozess, der nicht läuft – und zugleich die ganze Einschränkung: Payloads auf rund 4 KB gedeckelt, Zustellung nach Best Effort, stille Hintergrundweckrufe tageweise rationiert und der Payload außerhalb des Berechtigungsmodells Ihres Backends.

Eine Live Query verlässt Ihre Vertrauensgrenze nie: Die App hält einen WebSocket zum Abonnement-Server des Backends, der jeden Datenbankschreibvorgang gegen die abonnierte Query prüft und typisierte Ereignisse pusht – create, update, enter, leave, delete – mit pro Abonnent durchgesetzten ACLs. Vollständige Objekte, Latenz in Echtzeit, keine nennenswerte Obergrenze für den Payload. Die Abhängigkeit im Gegenzug ist brutal: Das Abonnement ist Zustand innerhalb Ihres Prozesses, und wenn das OS die App suspendiert – was mobile Plattformen aggressiv tun –, sind Socket und Kanal weg.

Push-Benachrichtigungen vs. Live Queries

Die Zeilen ergänzen sich sauber, weil die beiden Kanäle verschiedene Fragen beantworten: Push beantwortet “Wie erreiche ich den Nutzer?”, Live Queries beantworten “Wie bleibt der Bildschirm wahrhaftig?” – weshalb der Vergleich auf Transportebene zwischen SSE, WebSockets und Polling vollständig innerhalb der zweiten Frage liegt.

Die Übergabe: wo Apps tatsächlich kaputtgehen

Die Fehler sitzen an der Naht zwischen den Kanälen. Ein Nutzer tippt auf einen Push zu einer Nachricht, die auch per Live Query zugestellt wurde, bevor die App suspendiert wurde – deduplizieren Sie nach Objekt-ID, nicht nach Kanal. Ein Push trifft zu Daten ein, auf die der Nutzer keinen Zugriff mehr hat – holen Sie sie beim Öffnen über die normale API und lassen Sie die ACLs entscheiden, vertrauen Sie niemals dem Payload. Die App war drei Tage lang geschlossen – die wieder geöffnete App kann eine Lücke nicht aus Pushes wiedergeben (Benachrichtigungen sind kein Journal), also lautet die Übergabe immer neu abonnieren, dann die Basisabfrage erneut ausführen, um die Wahrheit neu aufzubauen, während die Registrierung des Push-Tokens im Hintergrund aktuell gehalten wird. Entwerfen Sie die Naht einmal, und beide Kanäle werden langweilig – genau das ist das Ziel.

Typische Anwendungsfälle

• Chat und Messaging – die Live Query stellt die geöffnete Unterhaltung dar; der Push trägt “neue Nachricht” durch den geschlossenen Zustand. Die Zwei-Kanal-App schlechthin.
• Bestell- und Lieferverfolgung – der geöffnete Verfolgungsbildschirm abonniert; der Wechsel auf “zugestellt” bei geschlossener App kommt als Push.
• Betriebliche Alarmierung – Konsolen der Rufbereitschaft abonnieren für die Wandanzeige; der Weg zum Pager ist Push, weil um 3 Uhr nachts niemand die App offen hält.
• Auktionen und Drops – Preisbewegungen live in der App; überboten zu werden, während man weg ist, ist ein Push mit Deep Link zurück in den Live-Bildschirm.
• Soziale Interaktion – Likes und Antworten landen als Push zur Rückgewinnung; der geöffnete Feed geht per Abonnement live.

Welchen Kanal sollten Sie verwenden? Entscheidungsmatrix

Grenzen und Trade-offs

• Push ist kein Datenkanal. Payload-Grenzen, undurchsichtiges Routing außerhalb Ihrer ACLs und das Zusammenfassen machen ihn strukturell ungeeignet, Zustand zu tragen – senden Sie Verweise, holen Sie die Wahrheit beim Öffnen.
• Push-Zustellung ist eine Wahrscheinlichkeit, kein Versprechen. Akku-Optimierer, entzogene Berechtigungen und Drosselung durch das Gateway verwerfen Nachrichten allesamt stillschweigend; alles, was nicht verloren gehen darf, braucht einen Abgleichspfad per Abfrage.
• Live Queries enden an der Prozessgrenze. Kein Socket überlebt die Suspendierung; ein Abonnement für einen dauerhaft aktiven Kanal zu halten ist die falsche Annahme hinter den meisten “uns sind Ereignisse entgangen”-Fehlern.
• Beide Kanäle belasten den Client. Zu breite Abonnements verbrennen Akku und serverseitigen Abgleich; zu eifriger Push verbrennt Wohlwollen – die Deinstallation ist das Rate Limiting des Nutzers.
• Die Naht liegt in Ihrer Verantwortung. Deduplizierung, Aufhol-Abfragen und die Auffrischung der Token sind Anwendungslogik; keiner der beiden Kanäle liefert sie gratis mit.

Push und Live Queries mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Beide Kanäle sind eingebaut und teilen sich einen Schreibpfad: Ein Cloud-Code-Trigger afterSave auf demselben Datenbankschreibvorgang kann den Push senden – über die Gateway-Anbindungen der Plattform, mit Adressierung nach Gerät und Kanal –, während Live Query das vollständige Objekt automatisch an jeden abonnierten, berechtigungsgeprüften Client fächert. Das Weiterleitungsdiagramm oben schrumpft auf einen Trigger und einen Abonnementaufruf, und die Logik an der Naht – Aufhol-Abfragen, Token-Registrierung über die Installation-Klasse – läuft durch dieselben SDKs, die die Code-Tabs zeigen.