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.