Tgfgyvvvgggggvv
Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
281–286 of 286 posts
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#282C rtrrgehevvrrhg33g
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#283Earlier quoted context omitted.
Can you elaborate?
Some very obvious and easily avoidable problems (of the binary format): * Messages are designed in such a way that only the size of the constituents is given. The size of the container message isn't known. Therefore the top-level message doesn't record its size. This requires one to invent an extra bit of the binary format, when they decide how to delimit top-level messages. Different Protobuf implementations do it d…
> Had the author of this creation tried to use it for a while,...
The problem is that proto v1 has existed for over 20 years internally at Google. And being able to be backwards compatible is extremely important.
Edit. Oh. You're an LLM
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#284As someone who has worked at a few of the FAANGs, having thrift/grpc is a godsend for internal service routing, but a lot of the complexity is managed by teams building the libraries, creating the service discovery layers, doing the routing etc. But using an RPC protocol enables those things to happen on a much greater scale and speed than you could ever do with your typical JSON/REST service. I've also never seen a…
What about non-web client/server applications though? I'm thinking online games / MMOs that require much more realtime communications than REST does. I have no idea what is used now, socket connections with something on the line I suppose.
For a game, I would maybe use Protobuf and grpc. There is serialization and deserializarion required. Something like flatbuffers or capnproto where the wireformat matches language data layout makes for extremely efficient parsing (though it may not be as network efficient). Really depends on how you structure your data.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#285> The least-commonly used API model is REST
IMHO that's not true. We could argue that the REST name is abused, but it's the word commonly used to describe a stateless API that use HTTP with URI trough verbs (GET, POST, PUT, DELETE, PATCH).
This article seems opinionated towards gRPC
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#286Earlier quoted context omitted.
Yeah, I like doing this as well. And all the data goes in the request body. No query parameters. Especially when the primary intended client is an SPA, where the URL shown is decoupled with the API URL. Little bit of a memory jolt: I once built a (not for prod) backend in python as follows: write a list of functions, one for each RPC, in a file `functions.py` then write this generic function for flask: import server.…
Use a decorator to expose functions explicitly, otherwise sounds like security issue waiting to happen. All your decorator needs to do is add the function to an __exposed__ set, then when you’re looping over the dict, only expose keys who’s values are in the __exposed__ set
Good idea
Although I suppose using an approach like mine precludes any notion of a serious application.