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 quick
I'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.
  • Comment on Re: Module callbacks - to fork or not fork

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
    I'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.

    Thanks for pointing that one - I wholeheartedly agree.

    I now do exactly this but, until recently, I didn't. I'm sure lots of people don't just because it had never occurred to them.

    There is a third advantage to add to your list. It is much easier to change the way you send emails. I've started using Send In Blue over SendGrid or SMTP. When I switched a system over from using MIME::Lite, making the change was simple as it only has to happen in one sub of one module.

Re^2: Module callbacks - to fork or not fork
by Bod (Parson) on Mar 01, 2023 at 23:18 UTC
    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

    That seems very reasonable...
    I feel that is right approach to take - thanks