Le migliori pratiche quando si progetta un motore di workflow utilizzando i timer?

4

Sto lavorando in un linguaggio OOP chiamato Fantom, simile a Java, per creare un motore di workflow. Il mio codice invia e-mail agli utenti e attende che gli utenti facciano clic su un pulsante all'interno dell'e-mail. Nel mio attuale codice di lavoro, invio l'e-mail, quindi sospendo il thread con qualcosa come Thread.sleep (1000) e controlla ogni pochi secondi per vedere se l'utente ha risposto. Invio un'altra email a seconda della risposta, e ho diverse di queste e-mail e timer. Mi aspetto che gli utenti abbiano fino a due settimane per rispondere a ciascuna email. Mentre la mia soluzione funziona, mi chiedo quali sono le migliori pratiche per un'applicazione come questa a livello di architettura? Quali sono alcune risorse per aiutarmi a progettarlo meglio? Grazie

    
posta Daryl Bennett 13.08.2018 - 19:56
fonte

1 risposta

9

Puoi progettare il flusso di controllo in senso inverso per evitare più timer.

  1. Quando invii un'email, memorizza qualsiasi contesto necessario per una risposta. Per esempio. scrivi questo contesto in un database o file.
  2. Controlla regolarmente le risposte. Per esempio. potresti avere un singolo thread che controlla le email in arrivo. Ciò può comportare un timer o semplicemente attendere le notifiche push (ad esempio quando si utilizza push-IMAP).
  3. Una volta ricevuta una risposta, carica le informazioni necessarie (dal database) e invia l'email successiva.

Perché questa potrebbe essere una soluzione migliore?

  • Siamo in grado di gestire molte più risposte in attesa perché non abbiamo bisogno di un thread per risposta in sospeso. Ciò consente di risparmiare memoria e tempo di CPU, al costo di una piccola quantità di spazio di archiviazione del database.
  • Di conseguenza, anche in questo caso si tratta di una soluzione molto migliore se una risposta non viene mai.
  • Se l'applicazione si blocca, può essere riavviata e continuerà con lo stato salvato.

Come osservazione generale, è spesso meglio avere eventi che innescano reazioni, invece di sondare o aspettare eventi. I concetti correlati vagamente includono Tell, non chiedere principio , promises , interfacce utente reattive (ad esempio JavaFX), server Web asincroni come NodeJS e l'idea di continuazioni : possiamo memorizzare il contesto di un thread e continuarlo in seguito. E naturalmente l'ampia classe di architetture basate sugli eventi in generale, in particolare idee come architettura di sourcing .

    
risposta data 13.08.2018 - 20:23
fonte

Leggi altre domande sui tag