5 ms·
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
by mf192 4y ago
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?
- charcircuit 4y agoNo, the g in gRPC stands for gRPC.
- nycdotnet 4y agoIt’s something new every release. Current is golazo, previous was gravity. https://github.com/grpc/grpc/releases 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.
- 0des 4y ago> 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.
- charcircuit 4y agoA better link https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md
- qbasic_forever 4y agoThere'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.
- pjmlp 4y agoOnly when "rest of us" === Go developers, in its current state.
- yashap 4y agoAs 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.
- strken 4y agogRPC 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
- depr 4y agoI don't see how Kafka means less worries about deployment
- hkt 4y agoFor 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.
- thinkharderdev 4y agogRPC streaming is too complicated so you should ... deploy Kafka?
- discreteevent 4y agoI think the principle of using messaging is valid. You could just use a simple reliable MQTT broker.
- wallyqs 4y agoPut 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/2e744ec4bf7ce3184f2f12b88c96103246f11184 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.