5 ms·
> we have to run the call in the web process I know you probably have good reason for this, but this smells like an architecture problem. Whenever you are talk
by rguzman 13y ago
> we have to run the call in the web process
I know you probably have good reason for this, but this smells like an architecture problem. Whenever you are talking to an external service it is a good idea to have your code laid out such that you can do that in the background. I understand that if you didn't plan enough architecture and maybe even product design to make that feasible from the get-go it is an expensive thing to build, but regardless of who is your hosting provider sooner or later you'll likely need to do it.
One thing I've always liked about heroku, at least in concept, is that it forces you to have good architecture. Some times it is a bit of a pain, but I think this pays off quicker than you seem to realize.
- swrobel 13y agovalid point.
- joevandyk 13y agoHow would you do payment processing in the background without temporarily storing the payment details?
- steveklabnik 13y agoI work for a payments company. Generally, you use JavaScript to actually tokenize the card. You then save that token in your actual application, and then use it to actually charge against. This model works just fine with background jobs.