3 ms·
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 RESTfu
by yashap 4y ago
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.
- 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.