4 ms·
Good point. I refered to the code, not to the protocls. With REST/JSON mostly you write code twice – server implementation and client implementation. If you ad
by divan 3y ago
Good point. I refered to the code, not to the protocls.
With REST/JSON mostly you write code twice – server implementation and client implementation. If you add new platform (say, iOS), you write new code again. So for each new platform you maintain separate code => not cross platform.
- bastawhiz 3y agoWhat code are you talking about? Having to write the URL in the HTTP client call?
- divan 3y agoNo, a bit upper layer. You need to handle error codes, request and response parameters, naming for the API etc. Imagine having API with 100+ endpoints. How do you add another one in gRPC? You edit .proto file and run codegenerator, which creates stub code for clients and server. You just need to connect that code to the rest of your app (say, talk to database here or display the response on the screen here). You don't write actual code for the network part. With traditional HTTP/REST/JSON approach you would have to write handlers yourself for each codebase separately. And there is no way to make sure they're in sync – only on organizational level (by static checks, four-eyes policies and such). I know it doesn't sound too big of a deal because most people used to it, but gRPC gives a different experience. Hence my initial comment that it's so much easier to work with.