4 ms·

This makes sense, but what if you're using a message queue to send transactional emails? Why would you put that logic on the browser?

by mbesto 3y ago

solardev 3y ago
Not quite sure I follow. Do you mean your frontend sends a "send message X to user Y" request to your backend, which then enqueues it internally and handles the actual SMTP later? That part of the logic wouldn't be in the browser (unless you're purposefully trying to emulate SMTP on the client for some reason). In Resend, for example, a 200 just acknowledges that their API successfully received your request and will attempt delivery soon. It doesn't necessarily mean the email was either sent from their SMTP servers or received by the recipient's server client. You can check delivery status later on in the dashboard: https://resend.com/docs/dashboard/emails/introduction#understand-email-events https://resend.com/docs/dashboard/emails/introduction#unders... (And then optionally receive that as a webhook later on, if you want to notify the user of success: https://resend.com/docs/dashboard/webhooks/event-types#email-delivered https://resend.com/docs/dashboard/webhooks/event-types#email...) ---- Edit: In case it wasn't clear, the value of something like Resend or (SES or SendGrid or whatever) is that you don't HAVE to write logic to handle the tricky parts of email delivery. You just send an API call to someone else's transactional email service and let them worry about all that. Bigger companies with dedicated staff/teams might want to inhouse a lot of that stuff, but there are a lot of smaller companies (or non tech companies) that still need to do transactional emails but don't necessarily want to maintain it in-house. In a resource-constrained team/org, it's the difference between a full-stack dev who has to split time between making the website and maintaining the backend(s) and infra, vs a cheaper frontend Javascript dev who can focus solely on the frontend UX/marketing/branding/etc.. The latter can matter more for direct-to-consumer companies who don't necessarily care about the backend as long as it works and isn't too expensive... those 3rd party services are usually much cheaper than hiring even a junior dev/sysadmin.
- mbesto 3y ago
  > Do you mean your frontend sends a "send message X to user Y" request to your backend, which then enqueues it internally and handles the actual SMTP later? No, I'm very familiar with transactional email services and why its superior to SMTP. > You just send an API call to someone else's transactional email service and let them worry about all that. 100%. But you also need code to do that. Typically the front-end form calls a backend endpoint (a controller for example in MVC) and then the back-end manages the request with the external API. Hence why there are endless docs like this: https://docs.sendgrid.com/for-developers/sending-email/quickstart-ruby https://docs.sendgrid.com/for-developers/sending-email/quick... At scale, those calls are actually handled by a message queue (like Redis). If you let the front-end code handle it, you would likely get throttled by the transactional email service provider.
  - solardev 3y ago
    Ah, I see what you're saying now! Sorry I misunderstood, and thanks for explaining. That does sound like something better dealt with on the backend at sufficient scale. The Resend API rate limit appears to be 10/sec.

This makes sense, but what if you're using a message queue to send transactional emails? Why would you put that logic on the browser?

by mbesto 3y ago

This makes sense, but what if you're using a message queue to send transactional emails? Why would you put that logic on the browser?

solardev 3y ago

Not quite sure I follow. Do you mean your frontend sends a "send message X to user Y" request to your backend, which then enqueues it internally and handles the actual SMTP later? That part of the logic wouldn't be in the browser (unless you're purposefully trying to emulate SMTP on the client for some reason). In Resend, for example, a 200 just acknowledges that their API successfully received your request and will attempt delivery soon. It doesn't necessarily mean the email was either sent from their SMTP servers or received by the recipient's server client. You can check delivery status later on in the dashboard: https://resend.com/docs/dashboard/emails/introduction#understand-email-events https://resend.com/docs/dashboard/emails/introduction#unders... (And then optionally receive that as a webhook later on, if you want to notify the user of success: https://resend.com/docs/dashboard/webhooks/event-types#email-delivered https://resend.com/docs/dashboard/webhooks/event-types#email...) ---- Edit: In case it wasn't clear, the value of something like Resend or (SES or SendGrid or whatever) is that you don't HAVE to write logic to handle the tricky parts of email delivery. You just send an API call to someone else's transactional email service and let them worry about all that. Bigger companies with dedicated staff/teams might want to inhouse a lot of that stuff, but there are a lot of smaller companies (or non tech companies) that still need to do transactional emails but don't necessarily want to maintain it in-house. In a resource-constrained team/org, it's the difference between a full-stack dev who has to split time between making the website and maintaining the backend(s) and infra, vs a cheaper frontend Javascript dev who can focus solely on the frontend UX/marketing/branding/etc.. The latter can matter more for direct-to-consumer companies who don't necessarily care about the backend as long as it works and isn't too expensive... those 3rd party services are usually much cheaper than hiring even a junior dev/sysadmin.

mbesto 3y ago
> Do you mean your frontend sends a "send message X to user Y" request to your backend, which then enqueues it internally and handles the actual SMTP later? No, I'm very familiar with transactional email services and why its superior to SMTP. > You just send an API call to someone else's transactional email service and let them worry about all that. 100%. But you also need code to do that. Typically the front-end form calls a backend endpoint (a controller for example in MVC) and then the back-end manages the request with the external API. Hence why there are endless docs like this: https://docs.sendgrid.com/for-developers/sending-email/quickstart-ruby https://docs.sendgrid.com/for-developers/sending-email/quick... At scale, those calls are actually handled by a message queue (like Redis). If you let the front-end code handle it, you would likely get throttled by the transactional email service provider.
- solardev 3y ago
  Ah, I see what you're saying now! Sorry I misunderstood, and thanks for explaining. That does sound like something better dealt with on the backend at sufficient scale. The Resend API rate limit appears to be 10/sec.