If you're interested in hosting it at no cost on Oracle Cloud's always free tier (4 cpu, 24GB ram), instead of buying a Mac Mini or paying for a VPS, I wrote up how-to with a Pulumi infra-as-code template here: https://abrown.blog/posts/personal-assistant-clawdbot-on-ora...
It doesn't, but from my perspective the thinking behind zero trust is partly to stop treating networking as a layer of security. Which makes sense to me - the larger the network grows, the harder to know all its entry-points and the transitive reach of those.
Another interpretation of this is that the lead developer adequately mitigated the risk of errors while also managing the risk of not shipping fast enough. It's very easy to criticise when you're not the one answering for both, especially the latter.
I really wanted to adopt tRPC but the deal breaker was it being opinionated on status codes without allowing configurability. Because I needed to meet an existing API spec, that meant ts-rest was a better option. I think there's an aditional option with a native spec generator in frameworks like Hono, and maybe Elysia.
His point about the runtime complexity of an API being entirely distinct from how the interface to it's code is exposed (whether GraphQL or REST or otherwise) is fairly obvious, I think.
The counter-argument is that unlimited query complexity makes it far bigger problem, and the author's point is that if you're using it for private APIs with persisted queries, you shouldn't have that problem unknowingly.
Don't get me wrong - I think the takeaway is that GraphQL's niche is quite small, and he's defending exactly that niche. It's not often the case that you can develop an API in a private manner which doesn't undercut higher-order value in the future, as the rise of AWS hopefully made evident.
Everything I needed to know about Russell's performance war was answered when, whilst he was working at Google, folk started asking him why he was naming and shaming companies for poor performance when his exact critiques were swiftly applied to Google's apps (calendar, maps, gmail). I wish I could find the twitter thread from back then, but the gist of his response was that what Google was doing was incredibly complicated, far more than anything the targets of his ire were working on, and as such it was reasonable not to have fixed those issues.
He wasn't wrong in his assessment of complexity, but the fact he refused to acknowledge the business priorities were the same between Google and companies he called out, absolutely baffled me. The gist from my perspective was that companies external to his own should bend over backwards for performance, while his should not, because his personal goals were tied to improving the performance of the web. Hopefully that's an over-simplification and I've missed something, but that's what I can recall.
> Folks seems to lack a kind of basic economic perspective.
I agree with most of what you said, but this seems a bit ironic.
Your suggestions almost exclusively involve large investments of time with little established proof that they are efficient. Do you genuinely believe reading RFC 2616 "cover to cover" is an efficient way of solving the specific problems they came across?
I would wager most developers wishing to be "really good" actually have a concrete desire like a greater paycheque or employer in mind. If that is true, I doubt reading someone's booklist necessarily is their fastest pathway, and their economic perspective is exactly what stops them doing so.
Agree that try/catch is verbose and not terribly ergonomic, but my solution has been to treat errors as values rather than exceptions, by default. It's much less painful to achieve this if you use a library with an implementation of a Result type, which I admit is a bit of a nuisance workaround, but worth it. I've recently been using: https://github.com/swan-io/boxed.
By far the greatest benefit is being able to sanely implement a type-safe API. To me, it is utter madness throwing custom extensions of the Error class arbitrarily deep in the call-stack, and then having a catch handler somewhere up the top hoping that each error case is matched and correctly translated to the intended http response (at least this seems to be a common alternative).