in reply to Module callbacks - to fork or not fork
As general advice for authoring modules, try not to get too wrapped up in the potential problems of users. Let them know about the timing requirements and they can worry about post-processing. There's quite a few ways to do it, too: forking, threads, event libraries, or Minion.
But also, regarding
send an email which is usually not exactly quickI'm going to jump in with related advice that when a web app wants to generate an email as part of a transaction with the user, the email should be added to a queue table of the database, to ensure the event is initiated. Then, come back with a background job that pushes the email from the table to SMTP or Sendgrid or whatever. This way 1) you never lose emails, and 2) service interruptions in SMTP or SendGrid will never delay the HTTP response to the user. You also gain a lot of control over how you handle the errors, like alarms that go off any time the table has stale messages in it, or automatic retries within the first 10 minutes, etc.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Queueing emails (was: Re^2: Module callbacks - to fork or not fork)
by Bod (Parson) on Mar 01, 2023 at 23:11 UTC | |
|
Re^2: Module callbacks - to fork or not fork
by Bod (Parson) on Mar 01, 2023 at 23:18 UTC |