News for hackers. Stuff that matters.
Re:I left Heroku for OpsWorks and shaved 40% off response times by rguzman on Friday February 07, 2014 @06:52PM (#7199585)
> 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.

Re:I left Heroku for OpsWorks and shaved 40% off response times by joevandyk on Friday February 07, 2014 @08:59PM (#7199989)
How would you do payment processing in the background without temporarily storing the payment details?
Re:I left Heroku for OpsWorks and shaved 40% off response times by steveklabnik on Friday February 07, 2014 @09:19PM (#7200029)
I 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.

Re:I left Heroku for OpsWorks and shaved 40% off response times by swrobel on Friday February 07, 2014 @07:35PM (#7199763)
valid point.