Voglio abilitare alcune notifiche in tempo reale sulle attività degli amici (social network).
Il contesto tecnico è: Webapp che chiama backend (API REST).
Lo scenario è:
Kevin segue Bob.
Quando Bob pubblica un nuovo commento, Kevin deve essere informato immediatamente (quasi in tempo reale).
Inoltre, quando Kevin accede, dovrebbe essere in grado di vedere alcune notifiche passate, simili a ciò che fa Facebook.
Significa che le notifiche dovrebbero essere memorizzate da qualche parte.
Ecco il flusso di lavoro tecnico:
- La pubblicazione di un nuovo commento da parte di Mario comporta un inserimento nel database di questo nuovo commento.
- Come seguendo Domain-Driven-Design, viene attivato l'evento
CommentedItemEvent. - Un lavoratore distinto nello stesso contesto limitato (processo di lunga durata, che esegue il polling del database ogni secondo) che ascolta questo evento lo cattura.
Alla fine del 3, vedo 2 possibilità:
- Creazione della notifica corrispondente, memorizzandola nel database e POI inviandola a Redis Pub / sub. Questo alimenterebbe alcuni abbonati specifici che agiscono sulla connessione WebSocket per inviare la notifica al client di Kevin.
- Creazione della notifica corrispondente, quindi invio a Redis THEN memorizzandoli nel database.
Per quanto riguarda la prima possibilità, il vantaggio sarebbe l'aspetto transazionale. In effetti, nessuna notifica potrebbe essere inviata se prima non fosse stata salvata. = > Integrità.
Tuttavia, lo svantaggio è che l'inserimento del database potrebbe rallentare il processo di "quasi in tempo reale di notifica".
Per quanto riguarda la seconda possibilità, le notifiche vengono inviate immediatamente, ma se si verifica qualche errore riguardante l'inserimento del database, Kevin potrebbe chiedersi:
"Humm ... ho ricevuto la notifica di Bob, sono sicuro di averlo visto, quindi perché un semplice aggiornamento della pagina non lo mostra più?" = > In effetti, non è stato mantenuto con successo, quindi non può interrogarlo.
Che cosa è una buona pratica in merito a questo caso d'uso?
Ovviamente, un modo più veloce sarebbe quello di non coinvolgere un listener di eventi per questo caso, ma violerebbe alcuni principi riguardanti il Domain-Driven Design. IMHO, database di polling listener nel suo contesto limitato è necessario. (evocato da Vaughn Vernon in questo libro IDDD - "Costruire un negozio di eventi")