Il problema
Attualmente stiamo architettando il nostro nuovo microservizio di notifica, ma abbiamo problemi con come gestire le e-mail aggregate. Quello che dobbiamo fare è inviare una sola email ogni azione eseguita (potrebbe essere più di 20 minuti in pochi minuti), invieremo un'email dopo un'ora che riassume tutte le azioni che sono state completate.
Cosa abbiamo finora
Proponiamo finora di avere questo tipo di schema di messaggistica, in cui il servizio client è un qualsiasi servizio nel nostro cluster e Messagebot è il nostro microservizio di notifica.
1) Il servizio client invia una notifica a Messagebot che dovrà inviare qualcosa in futuro 2) Messagebot memorizza i dettagli nel suo database 2) Messagebot controlla periodicamente il suo database per ciò che deve essere inviato 3) Messagebot ottiene i dati richiesti da un altro servizio (potrebbe essere il Servizio Client) tramite API 4) Messagebot invia e-mail utilizzando i dati di # 3 e un modello HTML
Il dibattito
Per i dati che devono essere inviati, siamo meno sicuri ed è ciò di cui abbiamo bisogno di aiuto. Finora pensiamo che questa dovrebbe essere la struttura del JSON dal servizio client al servizio di notifica (passaggio n. 1):
{
template_id: SOME_TEMPLATE_ID,
user_id: SOME_USER_ID,
objectid: SOME_OBJECT_ID
}
o
{
template_id: SOME_TEMPLATE_ID,
user_id: SOME_USER_ID,
required_objects: {task_id: SOME_TASK_ID, document_id: SOME_DOCUMENT_ID}
}
Dove task_id e document_id sono solo esempi e cambierebbe in base al modello. Potrebbe essere altrettanto facilmente {product_id: SOME_PRODUCT_ID} per un modello diverso.
Perché il dibattito
I nostri pensieri finora sono:
1) Abbiamo solo bisogno di template_id perché l'origine dei dati sarebbe implicita negli oggetti (come una variabile ENV var). Ad esempio, l'oggetto Task si trova al link . In caso contrario, potremmo avere problemi con API non riuscite o cambiare URL in futuro.
2) Dovremmo usare userid invece di e-mail e nome perché evitiamo che il problema delle coppie di e-mail / nome non corrisponda a più messaggi
3) Per gli oggetti siamo ancora scettici perché significa che il servizio dell'app client avrebbe bisogno della conoscenza del funzionamento interno di Messagebot ma un singolo objectid potrebbe non essere molto estendibile. Potremmo facilmente immaginare molti dei nostri messaggi che richiedono più di un oggetto.
In conclusione
Grazie per la lettura. Il design di questo servizio è importante perché sarà centrale per la nostra intera organizzazione.
Quale dibattito sulla struttura JSON è più appropriato nella nostra situazione? Inoltre, conoscendo le nostre esigenze, quale sarebbe l'impostazione corretta per questo tipo di servizio? (alias: siamo corretti nelle nostre altre ipotesi?)