È sempre il modo migliore per andare a mettere in coda le email invece di inviarle in tempo reale? [duplicare]

4

Se dovessi decidere tra e-mail in coda e inviarli in tempo reale, è sempre il modo migliore per metterli in coda e inviarli uno per uno invece che istantaneamente non appena un utente invia la richiesta?

Le email vengono inviate usando un servizio esterno che è Mandrill. Evertime qualcuno invia un modulo specifico nel nostro sito Web, viene inviata un'email di notifica dell'operazione riuscita. Queste "richieste" vengono quindi gestite nel back office da un altro team e quindi un'altra email viene inviata al richiedente originale.

Inoltre avremo bisogno di costruire un sistema di email marketing all'interno dell'applicazione, in modo che sia così.

Ciò che intendevo con l'accodamento delle e-mail (dato che stiamo usando Mandrill) è l'accodamento della chiamata API al servizio invece di inviarlo non in modo asincrono. Poiché l'invio dell'email non è istantaneo, il client attende fino a quando viene ricevuta una risposta da Mandrill, invece di gestirla con un sistema di coda (come beanstalkd).

Ecco un esempio di codice di ciò che intendo.

public function example($id)
{
    [...]

    $Mandrill = \App::make('mandrill');

    $message = $Mandrill->prepareEmail(
        [...]
    );

    $Mandrill->messages->send($message, false, null, null);
}

Inviamo immediatamente la richiesta API e poiché la risposta non è immediata, la richiesta si blocca perché è in attesa della risposta dell'API, ovvero ciò che intendo per in tempo reale (non è sicuro se sia così forse il termine corretto?).

Quello che ti ho mostrato sopra fa parte del codice base della mia attuale applicazione. Quello che sto chiedendo è se vale la pena refactoring del codice in modo che le richieste API siano inviate su una coda di elementi e avere un gestore code (con beanstalkd per esempio) gestirli uno per uno su una richiesta separata dietro le quinte .

    
posta GiamPy 16.11.2015 - 21:15
fonte

1 risposta

1

Poiché le e-mail non sono la consegna garantita in tempo reale, non vi è alcun evidente vantaggio nel mandarle in blocco. Tuttavia, non è così semplice nella pratica e il blocco può avere un merito.

Vai con l'invio asincrono / in coda se il blocco danneggia i processi upstream.

Vai con l'invio sincrono / bloccante se il processo upstream ha bisogno di sapere che il tentativo di invio fallisce in modo triviale (SMTP non disponibile, autenticazione SMTP fallita, ecc.).

Vorrei andare con async come approccio predefinito e registrare errori o disporre di una coda separata per lo stato di invio che il processo upstream oi processi di monitoraggio downstream possono sottoscrivere e agire.

    
risposta data 17.11.2015 - 03:20
fonte

Leggi altre domande sui tag