3 ms·

It does not do a retry. It runs in the background to present the user with immediate feedback. Seeing a "processing" page with a "spinner" animation for 30 seco

It does not do a retry. It runs in the background to present the user with immediate feedback. Seeing a "processing" page with a "spinner" animation for 30 seconds is much better than the browser waiting on the server for 30 seconds. RE EDIT: From the article: "Typically, this completes almost immediately.". A 500ms poll isn't really a problem when for most people it will return success on the first poll.

optimiz3 13y ago
So ruby isn't a primary language form me, but doesn't the tx.save in the rescue block cause a retry? Also the 500ms poll looks like it is coming from the client - that definitely seems like a no-no. You'd hit the server 60 times over a 30 second back-end timeout. The worst time to ratchet up load on your server is when your back-end is having issues.
- zrail 13y ago
  The `save!` in the rescue block is just to save off the error message from Stripe, since retrying after a Stripe-level error isn't possible because the token that you get from `stripe.js` is one-time-use and is consumed as soon as Stripe sees you make an API call. SuckerPunch won't actually retry the job. In this simple example the backgrounding mechanism is mostly for insulating you from the browser's timeout.
- micaeked 13y ago
  Not quite. `txn.save!` just writes the data to the database. The call to do the actual processing happens earlier, on the line beginning with `charge = Stripe::Charge.create(`. RE the poll: I tend to do doubling polls for stuff like this (500ms, 1s, 2s, 4s, 8s, etc), but in this case I don't think it matters, since all the server does is one database lookup and render as json. Side note to OP: It seems like a bad idea to use the auto-incremented id as a key for polling, since it would allow an attacker to get full details of all transactions.
  - zrail 13y ago
    Yep, you're right. The book[1] has a much more fleshed out version of this example that uses a random guid as the key, plus a whole lot more. [1]: https://www.petekeen.net/mastering-modern-payments https://www.petekeen.net/mastering-modern-payments
  - optimiz3 13y ago
    Got it, thanks!

optimiz3 13y ago

So ruby isn't a primary language form me, but doesn't the tx.save in the rescue block cause a retry? Also the 500ms poll looks like it is coming from the client - that definitely seems like a no-no. You'd hit the server 60 times over a 30 second back-end timeout. The worst time to ratchet up load on your server is when your back-end is having issues.

zrail 13y ago
The `save!` in the rescue block is just to save off the error message from Stripe, since retrying after a Stripe-level error isn't possible because the token that you get from `stripe.js` is one-time-use and is consumed as soon as Stripe sees you make an API call. SuckerPunch won't actually retry the job. In this simple example the backgrounding mechanism is mostly for insulating you from the browser's timeout.
micaeked 13y ago
Not quite. `txn.save!` just writes the data to the database. The call to do the actual processing happens earlier, on the line beginning with `charge = Stripe::Charge.create(`. RE the poll: I tend to do doubling polls for stuff like this (500ms, 1s, 2s, 4s, 8s, etc), but in this case I don't think it matters, since all the server does is one database lookup and render as json. Side note to OP: It seems like a bad idea to use the auto-incremented id as a key for polling, since it would allow an attacker to get full details of all transactions.
- zrail 13y ago
  Yep, you're right. The book[1] has a much more fleshed out version of this example that uses a random guid as the key, plus a whole lot more. [1]: https://www.petekeen.net/mastering-modern-payments https://www.petekeen.net/mastering-modern-payments
- optimiz3 13y ago
  Got it, thanks!