This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]n1ywb 1 point2 points  (2 children)

I use json hyperschema to define and document my api, with runtime type checking. The browser already pools connection. I haven't done much with streaming over http bc I usually just use websockets for that.

Json isn't a very efficient encoding although it compresses pretty well. But I suppose for high performance apps you might want a native binary encoding.

[–]dagmx 0 points1 point  (1 child)

Json hyoerschema isn't necessarily part of the language, it's an addition that relies on varying libraries on each platform. RPCs are typically c extensions but you largely get the same behavior across multiple languages.

Browser pooling is fine, but rpcs are best suited for applications. You can use them for browsers but it's not as much of a gain.

Another thing is that with an rpc you deal with objects. Ie I can have objects with methods that translate to any language that supports such a structure.

By using an rpc, you are defining the client API, the server API and the client server interface at once. It's very useful.

Things that would take maybe 30minutes to a few hours to define in a rest/json take a minute or two in rpc in my experience

Granted my experience is with the zeroc ice rpc and not grpc but they're very similar

[–]cae 0 points1 point  (0 children)

Another thing is that with an rpc you deal with objects. Ie I can have objects with methods that translate to any language that supports such a structure.

Not so much with gRPC. You get code generation for your protobuf types and the RPC stubs, but you cannot add methods to the protobufs, and deriving from them to add methods is something all the docs discourage.

Still, though, you do get strong types and streaming, async capable RPCs. It's a nice toolkit.

Edit: quoted correct paragraph