251–260 of 286 posts
Earlier quoted context omitted.
"Write a protocol and GraphQL", god damn it escalates quickly. Fortunately, there are intermediate steps.
Any suggestions for a good RPC library?
Earlier quoted context omitted.
How does one even write an API client against a REST API that only publishes the initial entry point? in particular, how should the client discover the resources that can be manipulated by the API or the request/response models?
Your Web browser is probably the best example. When you visit a Web site, your browser discovers resources and understands how it can interact with them.
Most APIs however are intended to be consumed by another service, not by a human manually interpreting the responses and picking the next action from a set of action links. HATEOS is mostly pointless.
I've been having fun with connectrpc https://connectrpc.com/ It fixes a lot of the problematic stuff with grpc and I'm excited for webtransport to finally be accepted by safari so connectrpc can develop better streaming. I initially thought https://buf.build was overkill, but the killer feature was being able to import 3rd party proto files without having to download them individually: deps: - buf.build/landeed/proto…
We developed a small WebSocket-based wrapper for ConnectRPC streaming, just to make it work with ReactNative. But it also allows us to use bidirectional streaming in the browser.
Earlier quoted context omitted.
Go and Dart are probably the languages most likely to work well with gRPC, given their provenance.
Google has massive amounts of code written in Java so one would think the Java tooling would be excellent as well.
Earlier quoted context omitted.
For a public API I wouldn’t do this, but for private APIs we just do POST /api/doThingy with a JSON body, easy peasy RPC anyone can participate in with the most basic HTTP client. Works great on every OS and in every browser, no fucking around with “what goes in the URL path” vs “what goes in query params” vs “what goes in the body”. You can even do this with gRPC if you’re using Buf or Connect - one of the server th…
I'd argue just making everything POST is the correct way to do a public Api too. REST tricks you into endpoints no one really wants, or you break it anyway to support functionality needed. SOAP was heavy with it's request/respone, but it was absolutely correct that just sending everything as POST across the wire is easier to work with.
I've been having fun with connectrpc https://connectrpc.com/ It fixes a lot of the problematic stuff with grpc and I'm excited for webtransport to finally be accepted by safari so connectrpc can develop better streaming. I initially thought https://buf.build was overkill, but the killer feature was being able to import 3rd party proto files without having to download them individually: deps: - buf.build/landeed/proto…
It still uses protocol buffers though, which is where many of the problems I have with gRPC comes from
> If your API is a REST API, then your clients never have to understand the format of your URLs and those formats are not part of the API specification given to clients. Roy Fielding, who coined the term REST: "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any…
This idea of self-describing REST is now better known as HATEOAS. Personally I think it’s bloated and doesn’t solve a real problem. https://en.m.wikipedia.org/wiki/HATEOAS
https://hypermedia.systems/components-of-a-hypermedia-system...
It's an important aspect of a truly RESTful network architecture
Earlier quoted context omitted.
This idea of self-describing REST is now better known as HATEOAS. Personally I think it’s bloated and doesn’t solve a real problem. https://en.m.wikipedia.org/wiki/HATEOAS
HATEOAS is fantastic when your clients are humans. Not so much when they're code.
Earlier quoted context omitted.
your browser is a client that works against RESTful entries points that only publish an initial entry point, such as https://news.ycombinator.com from that point forward the client discovers resources (articles, etc) that can be manipulated (e.g. comments posted and updated) via hypermedia responses from the server in responses
The browser is also driven by an advanced wetware AI system that knows which links to click on and how to interpret the results.
Earlier quoted context omitted.
> You can’t just give someone a simple command to call an endpoint—it requires additional tooling that isn’t standardized. GRPC is a standard in all the ways that matter. It (or Thrift) is a breath of fresh air compared to doing it all by hand - write down your data types and function signatures, get something that you can actually call like a function (clearly separated from an actual function function - as it shoul…
> GraphQL is even better. Letting clients introduce load into the system without understanding the big O impact of the SOA upstream is a foot gun. This does not scale and results in a massive waste of money on unnecessary CPU cycles on O(log n) FK joins and O(n^2) aggregators. Precomputed data in the shape of the client's data access pattern is the way to go. Frontload your CPU cycles with CQRS. Running all your comp…