Hacker News Reader

Comment by mf192 | Hacker News Reader

It always felt like gRPC was solving Google problems, heck that's (probably) what the g stands for.

Connect is for the rest of us. I wonder what kind of useful general-purpose interceptors folks will come up with?

As someone who’s done lots of RESTful (or RESTish) json/HTTP APIs, lots of gRPC, and lots of GraphQL … the simplest, best solution in almost all cases is RESTful json/HTTP APIs. There’s really no need for gRPC for the rest of us, it’s just unnecessary complexity.

If you want code gen, just edit OAS specs with Stoplight’s OpenAPI editor, and generate clients/servers with OpenAPI generator. If you really need event streaming between services, just use something like Google PubSub, webhooks, Kafka, whatever - external systems are better for this than direct server to server comms because they’re more reliable, far less worries about deployment, etc.

RPC seems simple at first but always balloons into excess complexity. Just stick with REST, and sprinkle in a PubSub system if absolutely necessary, it’ll stay simpler that way.

gRPC is overkill for pretty much everything I do, but I like Protocol Buffers[0] for serialisation/deserialisation of big objects to disk.

[0] FlatBuffers would probably work well too, though I haven't used it

I don't see how Kafka means less worries about deployment

For event streaming, a shout out for redis's streams data type. A lot like Kafka for a lot less administrative overhead. Works in cluster mode, too.

gRPC streaming is too complicated so you should ... deploy Kafka?

I think the principle of using messaging is valid. You could just use a simple reliable MQTT broker.

Only when "rest of us" === Go developers, in its current state.

Put out an example of using it to switch the transport so that it is over NATS instead, this works now thanks to the interop with net/http package: https://github.com/wallyqs/connect-go/commit/2e744ec4bf7ce31... Internally requests are treated as NATS requests so you would get similar performance and latency as when using core NATS request/response.

There's definitely a tipping point where having language independent interfaces/protobufs and definitions of services are basically mandatory for any cross-team collaboration or work to be possible. But yeah for small teams or single products it really might not be necessary or be total overkill early on in a new product.

No, the g in gRPC stands for gRPC.

It’s something new every release. Current is golazo, previous was gravity. https://github.com/grpc/grpc/releases

They use this to pad the release notes so they don’t have to comprehensively document the behavior changes.

> They use this to pad the release notes so they don’t have to comprehensively document the behavior changes.

I want to laugh, but I also want to cry because it's true.

A better link https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md

Reply on news.ycombinator.com