3 ms·

I disagree. I would still have to wait for the API to return before I can proceed with the transaction and display the download page, so doing it synchronously

by jknupp 13y ago

I disagree. I would still have to wait for the API to return before I can proceed with the transaction and display the download page, so doing it synchronously makes more sense. And the overhead introducing Celery or python-rq would add versus the response time difference doing asynchronous email (which I'm using GMail for anyway, so I'm not too worried about it going down) makes the synchronous approach even more attractive.

zrail 13y ago
Sure. But what happens if Stripe's charge API takes 30 seconds and then Gmail takes a few seconds? The users browser times out and they're left looking at a 500 error. With asynchronous processing you get a lot of flexibility with regards to the failure modes. (This is not idle talk. We experienced this at my day job which is specifically what drove me to write my book.) For email you should probably not use Gmail. They have weird limits and you can easily run afoul of them. A better route is something like Mailgun or Mandrill. They're both free for a large number of outgoing sends and have nice logging and tracking options.
- abritishguy 13y ago
  I agree for email but transactions are very different, I want to know whether my transaction has been successful there and then and get access to what I have paid for. I don't want to be moved to a page saying that my transaction will be processed shortly. Also there would have to be much more than 30 seconds of lag before the connection would timeout.
- elithrar 13y ago
  > For email you should probably not use Gmail. I totally agree here. You're also forced to store a password (even if it's app-specific) in plain text, and the tracking/delivery features are non-existent. The Mandrill API is pretty rad (I'm using it in my Go app) and the tracking, ability to re-send an email from the last 24 hours (on the free plan) and the server-side templates are all very useful. try: mandrill_client = mandrill.Mandrill('YOUR_API_KEY') message = { 'subject': "Hello there.", 'to': [{'email': 'recipient.email@example.com', 'name': 'Recipient Name', 'type': 'to'}], 'from_name': "Matt", 'from_email': "matt@example.com", } result = mandrill_client.messages.send(message=message, async=True) // It'll fire it off without waiting, and you can either set up a web-hook *or* manually re-send if it fails via the dashboard if you don't do massive volumes except mandrill.Error, e: # Mandrill errors are thrown as exceptions print 'A mandrill error occurred: %s - %s' % (e.__class__, e) # A mandrill error occurred: <class 'mandrill.UnknownSubaccountError'> - No subaccount exists with the id 'customer-123' raise Pretty simple stuff. Add in some MergeVars (|NAME|, |PURCHASE_ID|) and server-side templates and you can pass whatever is needed to the API without having to keep "content" in your code or pull in an external template (i.e. Jinja).

by jknupp 13y ago

zrail 13y ago

Sure. But what happens if Stripe's charge API takes 30 seconds and then Gmail takes a few seconds? The users browser times out and they're left looking at a 500 error. With asynchronous processing you get a lot of flexibility with regards to the failure modes. (This is not idle talk. We experienced this at my day job which is specifically what drove me to write my book.) For email you should probably not use Gmail. They have weird limits and you can easily run afoul of them. A better route is something like Mailgun or Mandrill. They're both free for a large number of outgoing sends and have nice logging and tracking options.

abritishguy 13y ago
I agree for email but transactions are very different, I want to know whether my transaction has been successful there and then and get access to what I have paid for. I don't want to be moved to a page saying that my transaction will be processed shortly. Also there would have to be much more than 30 seconds of lag before the connection would timeout.
elithrar 13y ago
> For email you should probably not use Gmail. I totally agree here. You're also forced to store a password (even if it's app-specific) in plain text, and the tracking/delivery features are non-existent. The Mandrill API is pretty rad (I'm using it in my Go app) and the tracking, ability to re-send an email from the last 24 hours (on the free plan) and the server-side templates are all very useful. try: mandrill_client = mandrill.Mandrill('YOUR_API_KEY') message = { 'subject': "Hello there.", 'to': [{'email': 'recipient.email@example.com', 'name': 'Recipient Name', 'type': 'to'}], 'from_name': "Matt", 'from_email': "matt@example.com", } result = mandrill_client.messages.send(message=message, async=True) // It'll fire it off without waiting, and you can either set up a web-hook *or* manually re-send if it fails via the dashboard if you don't do massive volumes except mandrill.Error, e: # Mandrill errors are thrown as exceptions print 'A mandrill error occurred: %s - %s' % (e.__class__, e) # A mandrill error occurred: <class 'mandrill.UnknownSubaccountError'> - No subaccount exists with the id 'customer-123' raise Pretty simple stuff. Add in some MergeVars (|NAME|, |PURCHASE_ID|) and server-side templates and you can pass whatever is needed to the API without having to keep "content" in your code or pull in an external template (i.e. Jinja).