5 ms·

For internal services communication, gRPC is a better option. For backend to web frontend, I will keep REST for a while although is tempting to have a unified s

• q3k 9y ago
  I'm currently developing a product using gRPC-Web as an interface between our client and server-side code. It's very pleasant to work with, especially when using TypeScript on the client side. Oh, and for those who want to be able to query APIs from the command line without prior knowledge, the following works if you have reflection enabled on your gRPC server: q3k@anathema ~ $ alias grpc="docker run --rm -it --net=host returnpath/grpc_cli" q3k@anathema ~ $ grpc ls 127.0.0.1:50051 helloworld.Greeter grpc.reflection.v1alpha.ServerReflection q3k@anathema ~ $ grpc ls -l 127.0.0.1:50051 helloworld.Greeter filename: helloworld.proto package: helloworld; service Greeter { rpc SayHello(helloworld.HelloRequest) returns (helloworld.HelloReply) {} } q3k@anathema ~ $ grpc type 127.0.0.1:50051 helloworld.HelloRequest message HelloRequest { optional string name = 1[json_name = "name"]; } q3k@anathema ~ $ grpc call 127.0.0.1:50051 helloworld.Greeter.SayHello 'name: "gRPC World"' connecting to 127.0.0.1:50051 Rpc succeeded with OK status Response: message: "Hello gRPC World"
  • speedplane 9y ago
    gPRC is nice... my only two gripes are that it isn't quite as debuggable as JSON, it's often overkill, and because it moves so fast (right now) I've seen updates introduce real errors into the protocol (they are fixed in a few days, but when they occur it's a terror to debug).