evinism

i'd love to hear more about your thoughts on pipes. Any particular reason they don't sit right with you?

Yeah, GraphQL certainly has many of the features that I was looking at here too, and I figure that it's the rough direction in which webdev seems to be going.

I just... like RPCs.

There's also a vague sense of "buttery should work well for multiple services in a way that other methods might struggle to do so." The fact that RPCs are grouped into services means that a load balancer can shift RPCs to different backends based on which buttery service they're talking to. I'm not sure how that actually compares against common solutions, but it IS interesting :)

Thanks for taking the time to think about all these things! It's very helpful for me.

I'm not sure any answer other than "I felt like it was a good choice" is gonna be 100% accurate, but a few things, some of which are speculative, some of which are reactionary.

(I'm sadly not very familiar with OAS, so it's very possible that OAS supports many of the things I'm going for!)

- This takes very heavily after protos, which use a DSL.

- This rejects protos because of a few reasons, not the least of which is that every field in proto3 is optional. While it makes sense for google, I don't think it makes sense for everybody.

- gRPC is non-http, and I was unhappy with gRPC-web

- I wanted it to be a terse specification, such that just glancing over the definition file gives you a sense of what the API consists of.

- I wanted a solution that handled websockets/server push as a first-class citizen, and not as a secondary add-on

- I wanted to provide library-level validation of request / response shape.

- I wanted to extend it beyond typescript, notably into python (and hopefully beyond)

- I like the idea of generic structs and oneofs (which I'm going to implement in some future version). I think if we had an easy way to define generics in cross-language APIs, we'd probably use it a fair amount.

- I like the idea of having an extensible language, e.g. be able to provide a JSONLogic type. Imagine a field `priceCalculation: JsonLogic<string, number>`. That'd be pretty cool!

this is one of those problems I've needed to solve for forever, but which i've never explicitly looked up a clean solution for. I can immediately think of 3 instances in the past week where this would have been perfect.

always used xkcd for this

This is the question I was going to ask. It seems like porting many of the poor decisions that were made in creating the web to native desktop.