2 ms·
One of the reasons I'd disregard gRPC for front-end development is my belief that data exchange between front and back-ends should be driven by the front-end.
by beders 2y ago
One of the reasons I'd disregard gRPC for front-end development is my belief that data exchange between front and back-ends should be driven by the front-end.
The UX drives the shape of data it needs from back-ends.
Any UI work I do is interactive and fast. Anything that hinders that, like code generation, is a drag.
Adding a suitable new endpoint or evolving data shapes coming from existing endpoints happens instantaneously in my dev environment.
I value that flexibility over tightly controlled specs.
I might eventually add types when I'm reasonably sure I got the data shapes right.
- randomdata 2y ago> my belief that data exchange between front and back-ends should be driven by the front-end. Why, then, are you trying to design the 'data shapes' before the UX is old enough to drive? It seems you don't live by what you preach. For what it is worth, I happen to share in your belief. gRPC couldn't possibly get in the way as you're not going anywhere near that layer of abstraction while the UX is being developed. By the time you're at the point of making network calls the data model is fully solidified. There is no need for continued iteration once you've gone that far. The biggest reason to disregard gRPC on the frontend, though, is that frontends are often found on slow, high latency networks where call overhead starts to bite you. Moving beyond simple applications, you really need some kind batching system rather than the RPC model in order to diminish the overhead cost. Of course, you can bend gRPC into some kind of batching system if you try hard enough – it is all just 1s and 0s at the end of the day, but there are other solutions more in tune to that particular problem.