---
term: 'Notifiche push vs. sottoscrizioni Live Query'
seoTitle: 'Notifiche push vs. live query: quale canale in tempo reale?'
headline: 'Notifiche push vs. sottoscrizioni Live Query: quale canale serve?'
slug: push-vs-live-queries
category: api-realtime
shortDefinition: '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.'
relatedTerms:
  - push-notifications-apns-fcm
  - real-time-live-queries
  - websockets-real-time-sync
  - sse-vs-websockets-vs-polling
contrastsWith:
  - real-time-live-queries
aboutTerms:
  - 'Push Notifications'
  - 'Live Query Subscriptions'
faq:
  - question: 'Qual è la differenza tra notifiche push e live query?'
    answer: 'Il percorso di consegna e lo stato dell''app che servono. Una notifica push attraversa il gateway push del sistema operativo e raggiunge il dispositivo anche con l''app chiusa – ma trasporta un payload piccolo e opaco, con garanzie best-effort. Una live query è una sottoscrizione WebSocket che l''app in esecuzione tiene aperta: oggetti completi, in tempo reale, con permessi verificati – e morta nell''istante in cui lo è l''app.'
  - question: 'Le live query funzionano ad app chiusa?'
    answer: 'No, e nessuna astuzia lato client cambia le cose. Una live query è stato dentro il processo in esecuzione – un WebSocket che l''app tiene aperto. Quando il sistema operativo sospende o termina l''app, il socket muore con lei, e le piattaforme mobili sospendono in modo aggressivo le app in background per risparmiare batteria. Raggiungere un''app chiusa è esattamente il compito che il sistema operativo riserva al proprio gateway push.'
  - question: 'Un''app di chat dovrebbe usare le notifiche push o le live query?'
    answer: 'Entrambe, ripartite in base allo stato dell''app. La conversazione aperta si sottoscrive a una live query – i messaggi compaiono all''istante con dati completi, indicatori di digitazione e conferme di lettura inclusi. L''app chiusa si affida al push per avvisare il destinatario, con il payload appena sufficiente a disegnare il banner. Il tocco apre l''app, che si risottoscrive e riesegue la query per recuperare il ritardo. Ogni messenger diffuso funziona così.'
  - question: 'La consegna delle notifiche push è garantita?'
    answer: 'No – la consegna è best-effort per progetto. I gateway del sistema operativo accorpano, limitano e scartano messaggi sotto pressione della batteria, gli utenti disattivano del tutto i permessi e i dispositivi diventano irraggiungibili. I push silenziosi in background sono limitati ancora più duramente di quelli visibili. Il push va trattato come un colpetto sulla spalla per risvegliare l''app, mai come un contratto di trasporto dati; l''app deve riconciliare lo stato con una query dopo l''apertura.'
  - question: 'Quanto può essere grande il payload di una notifica push?'
    answer: 'Kilobyte, non dati. I gateway del sistema operativo limitano i payload a circa 4 KB, e il payload è opaco per il modello di permessi del backend – qualunque cosa ci finisca dentro viaggia nella pipeline delle notifiche, fuori dalle ACL. Il pattern robusto invia solo identificatori e stringhe da mostrare, e lascia che l''app aperta recuperi gli oggetti veri attraverso l''API normale, con permessi verificati.'
  - question: 'Che cos''è una notifica push silenziosa?'
    answer: 'Un push senza avviso visibile che chiede al sistema operativo di risvegliare brevemente l''app in background – di solito per precaricare dati, così che la prossima apertura sembri istantanea. È la risorsa più razionata del sistema push: il sistema operativo assegna un budget di risvegli per app e per giorno e ignora l''eccedenza, quindi il push silenzioso funziona come livello di ottimizzazione, mai come canale di sincronizzazione affidabile.'
  - question: 'Servono sia le notifiche push sia le live query?'
    answer: 'Se agli utenti interessano eventi che accadono mentre l''app è chiusa – messaggi, ordini, avvisi – sì, quasi inevitabilmente. I due canali coprono stati disgiunti dell''app: le live query governano l''esperienza ad app aperta, il push governa la riattivazione dallo stato chiuso. I backend che integrano entrambi lasciano che una sola scrittura sul database si propaghi a ciascun canale, così avere bisogno di entrambi non significa più costruire due volte.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'RFC 8030 — Generic Event Delivery Using HTTP Push'
    url: 'https://datatracker.ietf.org/doc/html/rfc8030'
  - name: 'Push API — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/API/Push_API'
  - name: 'Push technology (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Push_technology'
  - name: 'Live Queries — Parse Server guide'
    url: 'https://docs.parseplatform.org/parse-server/guide/#live-queries'
cta:
  title: 'Un solo backend, entrambi i canali'
  text: 'Back4app offre notifiche push e Live Query sugli stessi dati: una sola scrittura sul database si propaga ai gateway push del sistema operativo e a ogni WebSocket sottoscritto. Collega il trigger afterSave una volta sola e copri ogni stato dell''app.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-23'
translationKey: push-notifications-vs-live-queries
---

**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

| Domanda | Risposta |
| --- | --- |
| Notifiche push | Consegna tramite il gateway del sistema operativo (APNs, FCM) – raggiunge le app chiuse, payload opaco di ~4 KB, best-effort |
| Live query | Sottoscrizione WebSocket – oggetti completi con permessi verificati, tempo reale, l'app deve essere aperta |
| La rivalità | Falsa – servono stati disgiunti dell'app e si compongono, non competono |
| La regola di instradamento | App aperta → live query · app chiusa → push · tocco sul push → apertura, risottoscrizione, recupero |
| La modalità di errore | Usare il push come canale dati, o aspettarsi che i socket sopravvivano al processo |

## Entrambi i canali, in codice

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

**JavaScript:**

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

**Swift:**

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

**Kotlin:**

```kotlin
// 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](https://datatracker.ietf.org/doc/html/rfc8030). 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](/glossary/it/websockets/) 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](/glossary/it/live-queries-tempo-reale/). 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.

```mermaid
flowchart TB
  accTitle: Instradare la consegna in tempo reale in base allo stato dell'app
  accDescr: Una scrittura sul database attiva la logica del backend. Se l'app del destinatario è aperta, una live query spinge l'oggetto completo su un WebSocket. Se l'app è chiusa, il backend invia un piccolo payload tramite il gateway push del sistema operativo, che mostra una notifica; un tocco la apre, e l'app si risottoscrive e recupera il ritardo con una query.
  W["Scrittura sul database<br/>(messaggio, ordine, avviso)"] --> T["Trigger del backend<br/>(afterSave)"]
  T -->|"app aperta"| LQ["Push via live query<br/>oggetto completo · WebSocket"]
  T -->|"app chiusa"| GW["Gateway push del sistema<br/>(APNs, FCM)"]
  GW --> N["Banner di notifica<br/>payload di ~4 KB"]
  N -->|"tocco"| O["L'app si apre →<br/>risottoscrizione + query di recupero"]
  LQ --> UI["Lo schermo si aggiorna sul posto"]
  O --> UI
```

## Notifiche push vs. live query

| | Notifiche push | Sottoscrizioni live query |
| --- | --- | --- |
| Raggiunge un'app chiusa | **Sì – il potere che le definisce** | No – la sottoscrizione muore con il processo |
| Payload | ~4 KB, opaco per le ACL | Oggetti completi, permessi verificati per sottoscrittore |
| Garanzia di consegna | Best-effort; accorpabile, limitabile, scartabile | Affidabile finché connessa; recupero necessario dopo un'interruzione |
| Latenza | Nell'ordine dei secondi, dipende dal gateway | Tempo reale (~RTT) |
| Proprietario del trasporto | Il sistema operativo e il suo gateway | La flotta di WebSocket del backend |
| Consenso dell'utente | Richiesta di permesso; revocabile dall'utente | Nessuno – sono solo i dati dell'app |
| Costo dell'abuso | Assuefazione alle notifiche, disinstallazioni | Carico su batteria e socket in caso di sottoscrizioni eccessive |
| Progettato per | Attenzione e riattivazione | Dati e stato in-app |

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](/glossary/it/sse-vs-websockets-vs-polling/) 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](/glossary/it/notifiche-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

| Situazione | Scegliere |
| --- | --- |
| La schermata è aperta e deve restare aggiornata | Live query |
| L'evento avviene ad app chiusa e l'utente deve saperlo | Notifica push |
| Il payload è sensibile o soggetto a permessi | Live query – oppure push con soli identificatori, recupero all'apertura |
| Serve una consegna dei dati garantita e ordinata | Nessuno dei due da solo – recupero via query all'apertura, canali come acceleratori |
| Aggiornare un badge o un contatore in-app in tempo reale | Live query |
| Riattivare utenti che non aprono l'app da giorni | Push – l'unico canale che può farlo |
| Chiosco o schermo a parete che non dorme mai | Solo live query; il push non aggiunge nulla |

## 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](/glossary/it/live-queries-tempo-reale/) 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.