Async mails

[dimsav]

Hello, is it possible to send emails asynchronously?

Thanks

[richleland]

@beardyman or @jasonrhodes - can either of you chime in?

[davidkudera]

@dimsav you can use for example rabbitmq for that

[richleland]

Our plan is to tackle something using HTTPlug in the 2.x refactor.

[dimsav]

@dimsav you can use for example rabbitmq for that

@davidkudera think of very simple presentation website that have a contact form and send emails through sparkpost. Adding rabitMQ in this kind of sites is an overkill imo.

On the other hand, I am not saying sparkpost should have to support async emails, but it would be a nice feature to have.

[davidkudera]

@dimsav yeah, it definitely is 😃

[ao]

Any news on this yet?

[jasonrhodes]

tbh I'm not sure what you're asking here.

On May 5, 2016, at 9:32 PM, Richard Leland notifications@github.com wrote:

@beardyman or @jasonrhodes - can either of you chime in?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[ao]

@jasonrhodes The ability for the API to perform email sending in the background instead of the current synchronous way.
At the moment the API holds the connection open until the email is sent which can take up to 15seconds (other may have experienced more?)

This would be a nice feature enhancement so that external applications/devs don't have to handle email queues. (Much like Mandrill does..)

Maybe another key array("async", true); with default to false(as is)?

[richleland]

We're going to handle this in 2.x, which is in progress. Essentially if whatever adapter you bring supports async, you can use async. Check out the README for 2.x (again, code is in progress).

[jasonrhodes]

@ao I just want to make sure we understand what problem you're having -- are you doing single-recipient transmission calls? If so, I think we respond differently in that case, where we wait for most of the send to complete before returning a response that corresponds to the status of the send. If that's the wait you're seeing, you could try batching your calls to send to multiple recipients at once, since we don't block on those calls and respond somewhat more immediately.

What @richleland is talking about is a way to not block your own application while waiting for our response, in general. PHP has async libraries that can handle this (e.g. http://reactphp.org) so you could implement something yourself if you want to, or you can wait for 2.x and then make sure you have an async-compatible adapter. (Or, you know, switch to nodejs )

[richleland]

#121 has been merged to the 2.x branch.

[dimsav]

Thank you guys for your hard work.

Unfortunately doing async http requests is not making a difference because we would still have to delay the response on our websites to inform the user of whether the mail was sent or not.

The error is mine because I wasn't clear enough when I opened the issue. Mandrill's api (search for async) supports async email sending. This means that they have a big queue in the background and they don't process their messages during the time they receive the request.

The benefit of using this system is that the response are very fast compared to a sync email sending. Correct me if I'm wrong but it seems that SparkPost's api doesn't support this feature, so we should probably make a feature requests in their support center.

[richleland]

Hi @dimsav our sending isn't synchronous - the API call itself is, but the actual send of the email is async. When you call the transmissions API, we'll let you know how many recipients were accepted/rejected, but that doesn't indicate delivery as many things can happen during the lifecycle of sending an email. If you need to check to see that the email was delivered, you'll want to use either webhooks or the message events API for delivery events.