Clojurians Log v2

I’m working on designing a notification system that supports “Reply by Email” similar to: • https://github.blog/2011-03-10-reply-to-comments-from-email • https://docs.gitlab.com/ee/administration/reply_by_email.html I’m not quite able to find any relevant resource/articles that talk about its architecture. Rails has Action Mailbox that assists in this but what I’m working on would be a purely Clojure implementation. Does anyone have any pointers on this?

HI @mail.acharyarahul.now, we have been running a similar thing using: https://postmarkapp.com it’s pretty solid and price is very reasonable.

here you can find detail documentation and some examples https://postmarkapp.com/developer/user-guide/inbound/parse-an-email

Hi @jmayaalv, was checking out https://sendgrid.com/docs/for-developers/parsing-email/setting-up-the-inbound-parse-webhook/#other-inbound-parse-documentation, will check out Postmark APIs as well, Thanks. I actually wanted to discuss the architecture of the notification system of which this is a small part. I missed out on explaining that. Here’re the details: Say there’s a list which has items and multiple people can act on the list. Upon any update on the shared list, all other participants should be notified of it (like how the Github PR comment works). And anyone in the shared list should be able to respond to that email and it’d trigger an action (like posting the Github comment) and that in turn updates the list and sends out emails again. I’d like to discuss the system design for this.

How do you see yourself solving this ? What does your current design look like ?

Hey @zor, here’s the design I’ve come up with:

Notes:
ECS = Email communication System.
Using sendgrid as an example Email Service Provider.

- Have color coded the flow. ECS has two parts, appropriate path would be chosen based on the event of send or receive.
- Send Email flow begins by reading data from `UpdateList` Topic. (Follow Blue)
- Receive Email flow begins by receiving Webhook callback (Sendgrid). (Follow Orange)

What does ECS stand for here ? Entity-Component-System ?

ECS = Email communication System. 

It's the name of the Notification system I'm designing. Currently focused on email but would be later extended to include SMS/Push.

The blue flow: I’ll have a consumer/subscriber subscribed to UpdateList Topic. So any new message that comes (as “Update Message”) will then be immediately stored in the database, then the db-id will be sent to the background worker. The background worker will fetch the record from the db and resolve the necessary details like the list info, thread meta, email template and the email address. Once the data is processed, the processed data would then be stored in the db again. It’d then send the email to other subscribers/recipients using Sendgrid* API and the response would be stored in the db. The orange flow: Once the email is responded to, it’ll hit the Sendgrid* Inbound parser webhook and will send the callback response to ECS. The callback response payload will be stored in the DB and then the db-id will be sent to the background worker. The background worker will then resolve the list-info and will publish a new message to the UpdateList topic. Which will cause re-sending of the email notification to the rest of the subscribers.

I would separate the inbound (webhook that happens to be hit by sendgrid inbound service) from the outbound (sendgrid API) in that diagram. When you say, later extensible to SMS/Push, you probably mean you intend to have more outbound channels. Once we do that we notice that the flow becomes pretty much unidirectional, looking like :inbound -> (store-inbound) -> :queue-a -> (handle-inbound-and-prep-outbound) -> :queue-b -> (send-outbound) -> :outbound.

> When you say, later extensible to SMS/Push, you probably mean you intend to have more outbound channels. Yeah, that’s right. > Once we do that we notice that the flow becomes pretty much unidirectional, looking like `:inbound -> (store-inbound) -> :queue-a -> (handle-inbound-and-prep-outbound) -> :queue-b -> (send-outbound) -> :outbound`. The intend is to have multiple selectable outbounds later. So yeah, it makes sense to separate it.

Thanks!

multimethods are a useful building block for dispatch. (and their combining cousin, weavejester/intentions (on GitHub))