Guida di Master Expo per le notifiche push 2026

Probabilmente sei arrivato al punto in cui l'app funziona, gli utenti sono stati registrati e il prodotto vuole flussi di ri-engaggio che sentano nativi. Ricordi della cesta. Suggerimenti di revisione. Nuove notifiche di messaggio. Annunci di rilascio. La prima istintiva è spesso quella di "mettere a punto le notifiche push", poi una settimana dopo si è impegnati a risolvere perché un dispositivo riceve le notifiche, il simulatore sembra registrare bene e nessuno può spiegare perché i tocchi non aprono la schermata giusta.

Quello è dove le notifiche push di Expo sono o piacevolmente semplici o sorprendentemente fragili.

Expo offre a team React Native uno strato pratico sopra APNs e FCM, che è esattamente il motivo per cui molti team lo utilizzano. Ma il gap tra una dimostrazione e un'implementazione pronta per la produzione è reale. Il ciclo di vita dei token, il timing delle autorizzazioni, la configurazione dei listener, la progettazione dei payload e la pulizia del backend contano. Se anche stai spedito cambiamenti logici dell'app con frequenza, la necessità di disciplina operativa diventa ancora più acuta, soprattutto se il tuo lavoro di retention dipende da messaggi affidabili e velocità di rilascio. Quello è lo stesso problema più ampio dietro Ritenzione degli utenti dell'app mobile: la consegna è utile solo se l'esperienza utente che la circonda è prevedibile.

Indice

• La Fondazione per coinvolgere gli utenti con le notifiche di Expo
  • Cosa Expo astrae effettivamente
  • Cosa significa essere pronti per la produzione
• Configurazione iniziale del progetto e configurazione
  • Installa i pacchetti di notifica
  • Aggiungi la configurazione a livello di progetto
  • Imposta un gestore delle notifiche presto
  • Android richiede la configurazione del canale
• Richiesta di autorizzazione e cattura dei token delle notifiche
  • La funzione del client che dovrebbe essere il tuo punto di riferimento
  • Perché Device.isDevice non è facoltativo
  • Chiedi il permesso nel momento giusto
• Inviare Notifiche dal tuo Server
  • Cosa ogni campo del payload dovrebbe fare
  • Tenere i payload piccoli e noiosi
  • Abitudini utili sul lato server
• Gestione delle Notifiche Inbound nella tua App
  • La ricezione in primo piano e la risposta dell'utente sono eventi diversi
  • Leggi il payload dei dati e naviga intenzionalmente
  • Il comportamento in primo piano dovrebbe corrispondere al contesto dell'utente
• Pratiche di Miglioramento della Produzione e Comuni Insidie
  • Token sono effimeri, non registri di identità
  • La strategia di aggiornamento conta più di quanto ammettono la maggior parte dei tutorial
  • La sicurezza e la conformità non appartengono alla fine della sprint
  • Cosa funziona di solito e cosa si rompe di solito

La Fondazione per coinvolgere gli utenti con le notifiche push di Expo

Un Notifica push di Expo La configurazione è attraente per una ragione soprattutto. Elimina molta complessità di messaggistica nativa che le squadre non vogliono gestire già il primo giorno. Invece di costruire plumbing APNs e FCM direttamente, puoi lavorare con la porta di ingresso di Expo e concentrarti sul comportamento del prodotto, la routing, l'esperienza UX delle autorizzazioni e la logica dei messaggi backend.

Quell'astrazione non rende le notifiche push 'meno reali'. Cambia solo dove va il tuo sforzo di ingegneria.

Il servizio è anche abbastanza veloce che il rendimento non è il primo problema da cui preoccuparsi. Dal 14 marzo 2023 al 12 giugno 2023, le notifiche push di Expo API hanno mostrato un 42 millisecondo di tempo di risposta mediano, 273 millisecondo di latenza p99e un tasso medio giornaliero di errori del 0,17% su context: HTML testo frammento da una stringa Capgo più lunga (chiave genitore `capwesome_diff_experience_capgo`). Pagina/area: pagina di confronto Capawesome. Ruolo: lungo paragrafo di marketing o legale. Visto in: pagina capwesome.astro. Preservare termini prodotto/marchio e sviluppatore esattamente. Chiave messaggio `capwesome_diff_experience_capgo` (Capwesome Diff Experience Capgo).decine di milioni di messaggi giornalieri Knock’s Expo push API benchmark analysiscontext: testo di analisi di benchmark di Knock per Expo push __CAPGO_KEEP_0__

. Ciò dovrebbe rassicurare qualsiasi team che si chiede se Expo è adatto solo per prototipi.

Cosa Expo astrae effettivamente

• Cosa significa quando i team dicono “push di Expo’ Si riferisce a più preoccupazioni separate raccolte insieme: Fornitore di routing: Expo invia messaggi a per iOS e FCM per Android.
• Formato del token: Il tuo server memorizza e invia un token di notifica Expo al posto di gestire il trattamento dei token specifici per piattaforma in primo luogo.
• Richiesta di contratto: Invi un payload al servizio di notifica Expo API al posto di integrare direttamente le API native dei provider.

È utile, ma crea anche una comune fraintesa. Alcune squadre suppongono che Expo gestisca ogni problema di consegna. In pratica, molti fallimenti provengono dall'app code, dai token scaduti, dai payload distorti o da un flusso di autorizzazione povero.

Regola pratica: Tratta Expo come un layer di trasporto affidabile, non come un sostituto di un design client e backend solido.

Cosa significa effettivamente la prontezza di produzione

Un demo funzionante prova solo che un dispositivo ha accettato un payload una volta sola. La prontezza di produzione significa qualcos'altro:

La differenza tra 'invia notifiche' e 'notifiche supportano un workflow di prodotto reale' è questa.

Configurazione del Progetto Iniziale e Configurazione

Molte delle preoccupazioni di Expo push iniziano prima della prima richiesta di autorizzazione. Se la configurazione del tuo progetto è disordinata, il client code può sembrare corretto mentre l'app si comporta in modo inconsistente tra le build.

Inizia con le librerie giuste installate e un ambiente di sviluppo che corrisponde al percorso di build. Se stai lavorando oltre Expo Go, è utile allineare il tuo workflow locale con una configurazione del client di sviluppo Expo personalizzataperché il comportamento delle notifiche spesso richiede di essere validato in un build che rifletta la produzione più da vicino di una rapida esecuzione di sandbox.

Installa i pacchetti di notifica

Di norma, avrai bisogno di:

• expo-notifications per le richieste di autorizzazione, la raccolta dei token, gli ascoltatori e la presentazione delle notifiche.
• expo-device perché dovresti proteggere la raccolta dei token con Device.isDevice.

Le comandi di installazione tipiche dipendono dal tuo gestore di pacchetti, ma la chiave è l'allineamento della versione con il tuo Expo SDK. Non mescolare versioni di pacchetti arbitrarie. Lascia che Expo risolva le versioni compatibili.

Aggiungi la configurazione a livello di progetto

Conserva la tua configurazione esplicita. Un minimo app.json o app.config.js context

{
  "expo": {
    "name": "MyApp",
    "slug": "my-app",
    "plugins": ["expo-notifications"],
    "ios": {
      "bundleIdentifier": "com.example.myapp"
    },
    "android": {
      "package": "com.example.myapp"
    },
    "extra": {
      "eas": {
        "projectId": "your-project-id"
      }
    }
  }
}

perché dovrebbe riflettere il fatto che le notifiche fanno parte del tuo contratto di app, non un dopo pensiero.

• Alcuni dettagli sono importanti qui: è necessario sincronizzare l'app che effettivamente distribuisce.
• Il plugin delle notifiche assicura che il progetto nativo riceva la configurazione necessaria durante la compilazione.
• L'ID del progetto EAS è importante quando il recupero del token attende che l'app sia associata al progetto Expo corretto.

Imposta un gestore delle notifiche presto

Molti tutorial base aspettano troppo a definire il comportamento delle notifiche. Non farlo. Mettilo vicino all'avvio dell'app per garantire un comportamento prevedibile in primo piano.

import * as Notifications from 'expo-notifications';

Notifications.setNotificationHandler({
  handleNotification: async () => ({
    shouldShowAlert: true,
    shouldPlaySound: false,
    shouldSetBadge: true,
  }),
});

Le squadre decidono se le notifiche in primo piano dovrebbero visualizzare un avviso, riprodurre un suono o influenzare le badge. Il comportamento esatto dipende dal tuo prodotto. Un'app di chat e un'app di pagamento non faranno le stesse scelte.

Se non definisci intenzionalmente il comportamento in primo piano, la tua squadra finirà per debuggere le 'notifiche mancanti' che sono state effettivamente ricevute ma mai presentate nel modo in cui il prodotto si aspettava.

L'Android richiede la configurazione del canale

I canali delle notifiche Android non sono facoltativi nella pratica. Se li ignorate, le vostre avvisaglie possono sembrare inconsistenti o fallire nel soddisfare le aspettative degli utenti.

import { Platform } from 'react-native';
import * as Notifications from 'expo-notifications';

export async function configureAndroidNotifications() {
  if (Platform.OS !== 'android') return;

  await Notifications.setNotificationChannelAsync('default', {
    name: 'Default',
    importance: Notifications.AndroidImportance.MAX,
  });
}

Imposta questo durante l'inizializzazione dell'app. Poi mantieni stabili gli ID dei canali. Cambiarli casualmente rende più difficile ragionare sul comportamento delle notifiche in seguito.

Richiesta di autorizzazione e cattura dei token di push

Questo è il passaggio che molti team copiano da un snippet, poi si pentono.

Le richieste di autorizzazione richiedono un timing, una consapevolezza della piattaforma e un trattamento asincrono disciplinato. La cattura dei token deve avvenire solo su un dispositivo fisico, solo dopo che sono state risolte le autorizzazioni e solo se si è pronti a memorizzare il risultato sul backend immediatamente.

La funzione del client che dovrebbe essere il tuo punto di partenza

Usa una funzione come questa come punto di partenza:

import * as Device from 'expo-device';
import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
import { Platform } from 'react-native';

type RegisterResult =
  | { ok: true; token: string }
  | { ok: false; reason: string };

export async function registerForExpoPushNotificationsAsync(): Promise<RegisterResult> {
  if (!Device.isDevice) {
    return { ok: false, reason: 'Push notifications require a physical device.' };
  }

  if (Platform.OS === 'android') {
    await Notifications.setNotificationChannelAsync('default', {
      name: 'Default',
      importance: Notifications.AndroidImportance.MAX,
    });
  }

  const permissions = await Notifications.getPermissionsAsync();
  let finalStatus = permissions.status;

  if (finalStatus !== 'granted') {
    const request = await Notifications.requestPermissionsAsync();
    finalStatus = request.status;
  }

  if (finalStatus !== 'granted') {
    return { ok: false, reason: 'Notification permission was not granted.' };
  }

  const projectId =
    Constants.expoConfig?.extra?.eas?.projectId ??
    Constants.easConfig?.projectId;

  if (!projectId) {
    return { ok: false, reason: 'Missing EAS project ID configuration.' };
  }

  const tokenResponse = await Notifications.getExpoPushTokenAsync({ projectId });

  return { ok: true, token: tokenResponse.data };
}

L'ordine conta. Controlli il tipo di dispositivo prima, imposti il comportamento del canale Android, risolvi le autorizzazioni, validi la configurazione del progetto, poi richiedi il token Expo.

Perché Device.isDevice non è facoltativo

Questo è uno dei pochi errori che crea molto rumore mentre sembra innocuo. Gli esperti richiedono l'autorizzazione condizionalmente solo quando Device.isDevice è vero, e un comune tranello è saltare quel guardiano, che porta gli sviluppatori a inviare notifiche a token di simulator non validi e a incolpare Expo quando il problema è realmente la configurazione dell'app, come descritto in Eagerworks’ implementazione delle notifiche Expo: note.

Quello è il motivo per cui il controllo si trova in cima alla funzione. Non nasconderlo dietro un aiutante. Faglielo vedere.

Il risultato del simulatore è utile per il testing della UI. Non è affidabile per la validazione dell'iscrizione del token di push.

Chiedi il permesso nel momento giusto

Non chiedere sulla schermata di avvio. Non chiedere prima che l'utente capisca il valore. Il momento migliore è spesso dopo un'azione dell'utente che rende i benefici delle notifiche concrete, come abilitare gli aggiornamenti di consegna, unirsi a una conversazione o salvare un oggetto segnalato.

Una buona implementazione segue di solito questo flusso:

1. L'utente raggiunge un confine significativo della funzione.
2. L'app spiega il valore delle notifiche nella propria UI.
3. L'app richiede il permesso del sistema.
4. L'app memorizza il token sul backend immediatamente se il permesso è stato concesso.

Quel passaggio finale è dove molti app falliscono. Eseguono il recupero del token, lo registrano localmente e rimandano la registrazione sul backend. In seguito, il supporto non può dire quale dispositivo aveva quale token in quale momento.

Ecco un esempio semplice di memorizzazione del token dopo l'iscrizione:

export async function enablePushForCurrentUser(userId: string) {
  const result = await registerForExpoPushNotificationsAsync();

  if (!result.ok) {
    return result;
  }

  await fetch('https://api.example.com/push-tokens', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: 'Bearer user-session-token',
    },
    body: JSON.stringify({
      userId,
      token: result.token,
      platform: Platform.OS,
    }),
  });

  return result;
}

Più avanti nel workflow, questo walkthrough è una utile riferimento visivo:

Per le squadre che stanno costruendo app con rilasci pesanti, è anche utile pensare alla registrazione del token come parte dello stato operativo dell'app, non solo come parte dell'onboarding. Questo modo di pensare si adatta bene con i flussi di lavoro più ampi di consegna delle app Expo Expo app delivery workflows, dove il comportamento dell'app può cambiare frequentemente e lo stato del backend deve rimanere sincronizzato.

Inviare Notifiche dal tuo Server

Una volta che il tuo backend ha un token di notifica Expo valido, inviare una notifica è facile. La parte difficile non è la richiesta stessa. È decidere cosa appartiene al payload e quanto fiducia si mette nello stato del client.

Esempio minimale Node-style usando fetch:

type ExpoPushMessage = {
  to: string;
  title: string;
  body: string;
  sound?: 'default' | null;
  data?: Record<string, unknown>;
};

export async function sendExpoPushNotification(token: string) {
  const message: ExpoPushMessage = {
    to: token,
    title: 'New review received',
    body: 'Tap to open the order details.',
    sound: 'default',
    data: {
      type: 'new_review',
      orderId: 'ord_123',
      screen: 'OrderDetails',
    },
  };

  const response = await fetch('https://exp.host/--/api/v2/push/send', {
    method: 'POST',
    headers: {
      Accept: 'application/json',
      'Accept-encoding': 'gzip, deflate',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(message),
  });

  const result = await response.json();
  return result;
}

Ciascun campo del payload dovrebbe fare qualcosa

Non trattare il payload come un mucchio di rifiuti. Mantieni ciascun campo intenzionale.

Questo data L'oggetto è dove i flussi di lavoro dei prodotti diventano utili. Puoi passare un tipo e un ID record, poi lascia che l'app fetchi i dati più recenti quando l'utente clicca. È più sicuro di inserire direttamente nel payload grandi o sensibili blob.

Conserva i payload piccoli e noiosi

Secondo La guida di Courier alle notifiche di Expo, i token di notifica di Expo dovrebbero essere trattati come ephemeris, i payload che superano i limiti di dimensione di circa 4 KB possono essere eliminati, e un modello affidabile è quello di inviare payload di metadati piccoli come { "type": "new_review", "id": 123 } piuttosto che grandi JSON o media inline. Questo consiglio corrisponde a ciò che funziona nei sistemi reali. I payload piccoli falliscono meno spesso e invecchiano meglio quando le logiche dell'app cambiano.

Invia abbastanza dati per indirizzare l'utente. Esegui il resto dopo che l'app si apre.

Abitudini utili del server

Una funzione di invio base è sufficiente per la prova. Una funzione di produzione aggiunge di solito alcune responsabilità in più:

• Persisti gli sforzi di invio: Salva l'intento di notifica con ID utente, token, tipo di payload e timestamp.
• Separare la generazione del contenuto dal trasporto: Costruisci la copia del messaggio in un layer e la richiesta di Expo API in un altro.
• Gestisci il feedback di invalidazione: Se Expo riporta in seguito DeviceNotRegisteredSegnala che il token è scaduto e fermati di riprovare senza senso.
• Utilizza un design amico dei webhook: Se il tuo sistema emette già eventi, invia i trigger delle notifiche attraverso lo stesso modello di elaborazione dei webhook sul backend che utilizzi altrove. Prima di debuggare gli ascoltatori del client, invia una notifica di test manuale. Se un token riceve una notifica normale con un payload piccolo, il tuo percorso di trasporto è probabilmente sano. Se non, non iniziare cambiando la navigazione __CAPGO_KEEP_0__. Inizia validando il token, la forma del payload e lo stato di autorizzazione. Gestisci le Notifiche In Arrivo nell'App

Before debugging client listeners, send a manual test push first. If a token receives a plain notification with a tiny payload, your transport path is probably healthy. If not, don’t start by changing navigation code. Start by validating the token, payload shape, and permission state.

Separare la generazione del contenuto dal trasporto:

Costruisci la copia del messaggio in un layer e la richiesta di Expo __CAPGO_KEEP_0__ in un altro.

Significa gestire due momenti separati:

• la notifica arriva mentre l'app è aperta
• l'utente interagisce con la notifica dalla barra dei notifiche o dalla schermata di blocco

La ricezione in anteprima e la risposta dell'utente sono eventi diversi

Un setup affidabile include di solito entrambi gli ascoltatori:

import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';

export function useNotificationObservers(
  onForegroundMessage: (notification: Notifications.Notification) => void,
  onNotificationTap: (response: Notifications.NotificationResponse) => void
) {
  useEffect(() => {
    const receivedSub = Notifications.addNotificationReceivedListener(
      (notification) => {
        onForegroundMessage(notification);
      }
    );

    const responseSub = Notifications.addNotificationResponseReceivedListener(
      (response) => {
        onNotificationTap(response);
      }
    );

    return () => {
      receivedSub.remove();
      responseSub.remove();
    };
  }, [onForegroundMessage, onNotificationTap]);
}

addNotificationReceivedListener Esso si esegue quando l'app è attiva. addNotificationResponseReceivedListener Esso si esegue quando l'utente tocca una notifica consegnata. Non combinarli mentalmente. Servono percorsi UX diversi.

Leggi il payload dei dati e naviga intenzionalmente

Ecco un pattern pratico per il trattamento del tocco:

type NotificationData = {
  type?: string;
  orderId?: string;
  screen?: string;
};

export function handleNotificationTap(
  response: Notifications.NotificationResponse,
  navigation: any
) {
  const data =
    response.notification.request.content.data as NotificationData;

  if (data.screen === 'OrderDetails' && data.orderId) {
    navigation.navigate('OrderDetails', { orderId: data.orderId });
    return;
  }

  if (data.type === 'new_review') {
    navigation.navigate('Inbox');
    return;
  }

  navigation.navigate('Home');
}

Questo pattern rimane resiliente perché il payload contiene indizi di routing, non documenti interi. Se l'ordine è cambiato dal momento in cui la notifica è stata inviata, l'app può recuperare lo stato del server corrente dopo la navigazione.

Una notifica toccata dovrebbe portare a un destino ovvio. Se il tuo percorso di fallback è vago, gli utenti lo notano immediatamente.

Il comportamento in primo piano dovrebbe corrispondere al contesto utente

Quando l'app è già aperta, mostrare un avviso di sistema a caso può sembrare goffo. A volte il passo giusto è un banner in-app, un aggiornamento della badge o un rinfresco silenzioso. Una schermata di posta in arrivo non ha bisogno di un avviso visibile quando l'utente sta già leggendo quella conversazione.

È per questo che il tuo ascoltatore in primo piano dovrebbe ramificarsi in base alla rotta e al tipo di notifica. Ad esempio:

• Schermo della chat aperto: aggiungi il messaggio e evita un banner ridondante
• Schermo del dashboard aperto: mostra un toast in-app leggero
• Evento critico dell'account: presenta un trattamento UI più forte

Un approccio semplice assomiglia a questo:

export function handleForegroundNotification(
  notification: Notifications.Notification,
  currentRouteName: string
) {
  const data = notification.request.content.data as { type?: string };

  if (currentRouteName === 'ChatThread' && data.type === 'new_message') {
    // refresh local thread state
    return;
  }

  // otherwise show your own in-app UI or update badges
}

Se il tuo app non distingue questi contesti, gli utenti sentiranno la fatica delle notifiche più velocemente, anche se la consegna è tecnicamente corretta.

Pratiche di produzione migliori e comuni insidie

La maggior parte delle configurazioni di notifica push Expo non funzionanti non falliscono perché Expo è troppo limitato. Falliscono perché gli squadre assumono che il token sia permanente, i payload possono trasportare qualsiasi cosa e gli aggiornamenti dell'app non influenzeranno la logica delle notifiche.

Quell'assunzione non sopravvive alla produzione.

Il token è effimero, non un registro di identità

Un token di notifica Expo è meglio trattato come un contratto di locazione, non come un dispositivo di identificazione a vita. I token possono rotare dopo reinstallazione, cambiamenti di sistema operativo o altri eventi di ciclo di vita. Se un token torna infine DeviceNotRegisteredil tuo backend dovrebbe smettere di trattarlo come attivo.

Un modello di backend pratico memorizza:

• ID utente
• piattaforma
• metadati di installazione scollegati
• token corrente
• timestamp dell'ultima visualizzazione
• Lo stato può essere attivo, scaduto o revocato

Non memorizzare un campo di token nella tabella degli utenti e considerare il problema risolto. Gli utenti hanno più dispositivi e i dispositivi cambiano stato.

La strategia di aggiornamento conta più di quanto ammettano la maggior parte dei tutorial

Il consiglio ufficiale dell'ecosistema lascia un vero gap operativo in questo caso. Il contenuto di notifica Expo spesso non spiega come mantenere la validità del token durante i cicli di revisione dell'App Store e gli aggiornamenti OTA È particolarmente importante per le squadre che inviano cambiamenti in tempo reale, poiché la affidabilità delle notifiche dipende dallo stato del token attuale e dalla sincronizzazione con il backend, come riportato nella documentazione delle notifiche ExpoCiò influisce su come progettare i trigger di aggiornamento. Buoni momenti per riconciliare lo stato del token includono: L'evento di avvio dell'app dopo un aggiornamento.

L'accesso dell'utente

• La modifica delle impostazioni di permesso
• L'aggiornamento delle credenziali nel processo di rilascio
• App Store review cycles and OTA updates
• Expo notifications documentation
• Flussi di recupero dopo i ticket di supporto relativi alle push

La sicurezza e la conformità non devono essere lasciate alla fine dello sprint

Molti tutorial di Expo si concentrano sulla meccanica e trascurano il rischio operativo. Va bene per le app di hobby. Non è bene per i prodotti sanitari adiacenti, fintech o commercio regolamentato.

La discussione di Courier focalizzata sull'impresa di Expo sui vuoti delle notifiche evidenzia una mancanza di linee guida pratiche relative alla registrazione del consenso, ai registri di audit e alla minimizzazione dell'esposizione dei dati di payload sensibili. Il takeaway di ingegneria diretta è semplice: Non inserire dati di business sensibili nel testo o nel metadati di payload delle notifiche.

• Registrare i cambiamenti di consenso sul lato server.
• Registrare quale intento di notifica è stato inviato a quale token.
• Usare gli ID nei payload e recuperare il contenuto protetto dopo l'apertura dell'app.
• Per le squadre che allineano le operazioni di rilascio con le pratiche di sicurezza più ampie e __CAPGO_KEEP_0__ di conformità degli store di app

Le push dovrebbero essere incluse nello stesso regime di revisione di autenticazione, analisi e registrazione degli eventi backend. app store compliance and API security practicesSecurity and compliance don’t belong at the end of the sprint

Gli avvisi push sono messaggi destinati agli utenti, ma sono anche un problema di sistemi distribuiti. Trattali con la stessa cura che applichi allo stato di autenticazione e agli eventi di pagamento.

Quello che funziona di solito e quello che di solito si rompe

Una buona configurazione di push di Expo non è complicata. È disciplinata.

Se il tuo team invia modifiche logiche dell'app con frequenza e ha bisogno di un controllo più stretto sul comportamento di rilascio, sui rollback e sulla visibilità della consegna, Capgo è degno di una visita. Aiuta i team mobili a inviare aggiornamenti velocemente senza dover attendere la revisione della store, il che è particolarmente utile quando sono necessarie flussi di notifica, logica di routing o correzioni client-side che devono raggiungere gli utenti velocemente.