Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
1–10 of 286 posts
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#2always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#3always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
yes!
REST is kind of like HTML... source available by default, human-readable, easy to inspect
GRPC is for machines efficiently talking to other machines... slightly inconvenient for any human in the loop (whether that's coding or inspecting requests and responses)
The different affordances make sense given the contexts and goals they were developed in, even if they are functionally very similar.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#4always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
How could gRPC be simpler without sacrificing performance?
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#5(2020)
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#6always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
How could gRPC be simpler without sacrificing performance?
What kind of performance? Read? Write? Bandwidth?
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#7always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
there are well working (official) generators of openapi/json schemas for grpc.
so once you wrote grpc, you get open api rpc for free.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#8Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#9always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
How could gRPC be simpler without sacrificing performance?
There's two parts to gRPC's performance
- 1. multiplexing protocol implemented on top of HTTP/2 - 2. serialization format via protobuf
For most companies, neither 1 or 2 is needed, but the side effect of 2 (of having structured schema) is good enough. This was the idea behind twrip - https://github.com/twitchtv/twirp - not sure whether this is still actively used / maintained, but it's protobuf as json over HTTP.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#10always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
afaik grpc did callbacks before we got sse/ws/webrtc/webtransport. so grpc was needed kind of.
and also canonical content streaming was in grpc. in http there was no common accepted solution at old times.