5 ms·
How do you implement "no really, this request should not return until the server has successfully completed external communication"? You can do some sort of we
by lumpypua 11y ago
How do you implement "no really, this request should not return until the server has successfully completed external communication"?
You can do some sort of websocket-y mechanism to tell the client that the server has completed a previous request, or polling, but both of those bring a lot of infrastructure overhead.
- jonny_eh 11y agoPolling is super easy. It's just one more API endpoint.
- StavrosK 11y agoBlocking is even easier, it's zero more endpoints.
- cdelsolar 11y agoYeah and if Stripe goes down your server goes down with it.
- StavrosK 11y agoHow are you architecting things that an upstream error will cause your server to die? Look, in both cases, the request needs to be synchronous. You need to tell the customer that their purchase went through. If you're going to add a whole other bus into the thing and make it asynchronous and have an elaborate polling solution on the client, that's fine, but I would (and do) just have them wait the two extra seconds and either say "your card has been charged" or handle the rare case with "there has been an upstream error, please don't close this window while we retry the request".
- pyre 11y agoIf Stripe is your payment processor, how do you propose that one should process payments if Stripe is down? How does making payment processing asynchronous help? Why would your entire server die because Stripe's API failed to return?