Other than that, yes, durable execution does all of this for you.
TLDR on Durable Endpoints: you can automatically use steps in API endpoints which checkpoint state in the BG, and then retry on failure. This means you can run jobs in the background _somewhat_ transactionally (somewhat because there's delay between checkpointing) to minimize any tradeoffs here. And, if you want full transactionality, don't buffer checkpoints in the BG and instead do it synchronously.
Also, Redis is good for medium scale load. We're hitting millions of RPS (aggregated) on our services (I work at Inngest) and it doesn't scale so well at this load, at all. We had to invest in other infra.
IDK, it looks like servers were up, connectivity worked well, and some builds were failing. Wouldn't call that a big issue, and the same thing was happening with Vercel due to their git clones etc. yesterday too.
Yes... but people can only focus on one thing at a time. We don't have 360 vision. We have blind spots! We don't even know the exact speed of our car without looking away from the road momentarily! Vision based cars obviously don't have these issues. Just because some cars are 100% vision doesn't mean that it has to share all of the faults we have when driving.
That's not me in favour of one vs the other. I'm ambivalent and don't actually care. They can clearly both work.
If you're testing the interface, changing the implementation internals won't create any churn (as the mocks and tests don't change).
If you are changing the interface, though, that would mean a contract change. And if you're changing the contract, surely you wouldn't be able to even use the old tests?
This isn't really a go problem at all. Any contract change means changing tests.
I really, really want this updated too and saw it in my bookmarks. Figured the historic data was interesting, and that someone might want to give this another go.
Actually, both Vercel and Cloudflare are based off of the API that we built at https://inngest.com (disclaimer, I'm a founder).
I strongly believe that being obvious about steps with `step.run` is important: it improves o11y, makes things explicit, and you can see transactional boundaries.
Their support for the Nexus line of phones has been outstanding. Anyone can phone and speak to real humans with good tech knowledge, arrange a free replacement for (first time) cracked screens, and get next day replacements.
I have no doubt that the support for this will be as good.
Now, their automated side of advertising is crappy unless you're a large spender, but then that's just economies of scale.
The major benefit of slack over hipchat is slack comes with integrations by default. IE: instead of having to use Zapier or such to hook into Trello slack can handle it for you.
HipChat only has an API you push to, whereas Slack can pull from other services.
We tried it and kept with HipChat. I found Slack's interface/text to be less readable than HipChat. It might look better, but for reading information and usability HipChat won. Our entire team is happy with our choice.