Notifiche push vs. sottoscrizioni Live Query: quale canale serve?

Una notifica push è un avviso consegnato dal sistema operativo che raggiunge le app chiuse; una live query trasmette le modifiche ai dati mentre l’app è aperta. Presentarle come rivali è l’errore classico – coprono stati disgiunti dell’app, e la vera domanda di progettazione non è “quale delle due” ma “dove si trova l’utente in questo momento?”. La maggior parte delle app che danno una vera sensazione di tempo reale usa entrambi i canali e instrada in base a quella risposta.

Punti chiave

Entrambi i canali, in codice

Il pattern verso cui converge quasi ogni app di messaggistica, ordini e avvisi:

// 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.

Da notare che cosa gestisce ciascuna metà: la sottoscrizione consegna dati – oggetti interi, eventi tipizzati, in tempo reale. L’installazione si registra per ottenere attenzione – il diritto di interrompere l’utente più tardi, attraverso una pipeline che l’app non controlla.

Due consegne, due proprietari

I percorsi non potrebbero essere più diversi, e ogni proprietà della tabella comparativa discende da chi possiede l’ultimo miglio.

Una notifica push lascia il backend come richiesta verso un gateway gestito dal sistema operativo – i gateway push di iOS e Android (APNs, FCM), oppure sul web un servizio push del browser che parla RFC 8030. Il gateway possiede la consegna: trattiene i messaggi per i dispositivi offline, accorpa e limita sotto pressione della batteria, e risveglia l’app o mostra il banner. Quel potere preso in prestito è l’intero vantaggio – solo il sistema operativo può raggiungere un processo che non è in esecuzione – ed è anche l’intero vincolo: payload limitati a circa 4 KB, consegna best-effort, risvegli silenziosi in background razionati per giorno, e un payload fuori dal modello di permessi del backend.

Una live query non esce mai dal perimetro di fiducia: l’app mantiene un WebSocket verso il server di sottoscrizioni del backend, che confronta ogni scrittura sul database con la query sottoscritta e spinge eventi tipizzati – create, update, enter, leave, delete – con le ACL applicate per ogni sottoscrittore. Oggetti completi, latenza da tempo reale, nessun tetto al payload degno di nota. In cambio la dipendenza è brutale: la sottoscrizione è stato dentro il processo, e quando il sistema operativo sospende l’app – cosa che le piattaforme mobili fanno in modo aggressivo – il socket, e con lui il canale, sparisce.

Notifiche push vs. live query

Le righe si compongono in modo pulito perché i due canali rispondono a domande diverse: il push risponde a “come raggiungere l’utente?”, le live query a “come tenere lo schermo fedele?” – ed è per questo che il confronto a livello di trasporto tra SSE, WebSocket e polling vive interamente dentro la seconda domanda.

Il passaggio di consegne: dove le app si rompono davvero

I bug vivono nella giuntura tra i canali. Un utente tocca un push relativo a un messaggio che è stato anche consegnato dalla live query prima della sospensione dell’app – si deduplica per ID dell’oggetto, non per canale. Arriva un push su dati a cui l’utente non ha più accesso – si recuperano attraverso l’API normale all’apertura lasciando decidere alle ACL, senza mai fidarsi del payload. L’app è rimasta chiusa tre giorni – l’app riaperta non può ricostruire il buco dai push (le notifiche non sono un registro), quindi il passaggio di consegne è sempre risottoscrivere, poi rieseguire la query di base per ricostruire la verità, tenendo aggiornata in background la registrazione del token push. Progettata una volta la giuntura, entrambi i canali diventano noiosi – che è esattamente l’obiettivo.

Casi d’uso tipici

• Chat e messaggistica – la live query mostra la conversazione aperta; il push porta il “nuovo messaggio” attraverso lo stato chiuso. L’app a due canali per antonomasia.
• Tracciamento di ordini e consegne – la schermata di tracciamento aperta si sottoscrive; il passaggio a “consegnato” ad app chiusa arriva come push.
• Alerting operativo – le console di reperibilità si sottoscrivono per lo schermo a parete; il percorso del cercapersone è il push, perché nessuno tiene l’app aperta alle 3 di notte.
• Aste e drop – movimento dei prezzi in diretta nell’app; essere superati in un’offerta mentre si è lontani è un push, con deep link di ritorno alla schermata live.
• Coinvolgimento social – like e risposte arrivano come push di riattivazione; il feed aperto va in diretta tramite sottoscrizione.

Quale canale usare? Matrice decisionale

Limiti e trade-off

• Il push non è un canale dati. Tetti al payload, instradamento opaco fuori dalle ACL e accorpamento lo rendono strutturalmente sbagliato per trasportare stato – inviare riferimenti, recuperare la verità all’apertura.
• La consegna push è una probabilità, non una promessa. Ottimizzatori della batteria, permessi revocati e limitazioni del gateway scartano messaggi in silenzio; tutto ciò che non può andare perso ha bisogno di un percorso di riconciliazione via query.
• Le live query si fermano al confine del processo. Nessun socket sopravvive alla sospensione; trattare una sottoscrizione come un canale sempre attivo è l’ipotesi sbagliata dietro la maggior parte dei bug del tipo “abbiamo perso degli eventi”.
• Entrambi i canali gravano sul client. Sottoscrizioni troppo ampie consumano batteria e matching lato server; un push troppo zelante consuma la buona volontà – la disinstallazione è il rate limiting dell’utente.
• La giuntura resta in mano a chi sviluppa. Deduplicazione, query di recupero e aggiornamento dei token sono logica applicativa; nessuno dei due canali li fornisce gratis.

Push e live query su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Entrambi i canali sono integrati e condividono un unico percorso di scrittura: un trigger Cloud Code afterSave sulla stessa scrittura nel database può inviare il push – tramite le integrazioni della piattaforma con i gateway, con targeting per dispositivo e per canale – mentre Live Query propaga automaticamente l’oggetto completo a ogni client sottoscritto, permessi verificati. Il diagramma di instradamento qui sopra si riduce a un trigger e a una chiamata di sottoscrizione, e la logica della giuntura – query di recupero, registrazione del token tramite la classe Installation – passa dagli stessi SDK mostrati nelle schede di codice.