7 ms·
I can't remember how many times I've written Redis-backed retry timers in Go to handle unreliable endpoints. It'd be great to not have to do that again. I like
by wyc 6y ago
I can't remember how many times I've written Redis-backed retry timers in Go to handle unreliable endpoints. It'd be great to not have to do that again. I like that you're focusing on such a concrete problem that I can see shaped functionality need into which it fits.
What happens when the requests to your API fail? Do I need to retry? Will there be an SDK that can help with this?
- tasn 6y agoHahaha yeah, I hope no one ever needs to do it ever again! It's a good question, and I answered it in a sibling comment: https://news.ycombinator.com/item?id=26400510 https://news.ycombinator.com/item?id=26400510 Essentially I think it's a risk with any external API you use. What happens when Stripe goes down? Twilio? Sendgrid (when you use magic links login)? Our whole focus is uptime, that's what we do. :)
- mperham 6y agoThis is one of the advantages of using background jobs. Any call to a 3rd party service should be in the background to handle network and reliability issues. The job system handles automatic retry.