3 ms·

> The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. Second this. I think its also really important to consider the "tra

> The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. Second this. I think its also really important to consider the "trap" of going in on gRPC, but using something like grpc-gateway to also spit out JSON as a "backup". We did this for a project I was on, and the JSON API was the thing everyone else used (because up until then, everything there was a JSON API, naturally). As a result, unless a consuming team was willing/able to get involved in the protobuf definition internals, most of our consumers didn't reap any benefits from our typed protobuf API. I know it really isn't hard to do, but lowest friction denominator wins far too often in a feature-focused environment :-\

gravypod 5y ago
One thing that was doable in my last company where I used gRPC was I made interfacing with the gRPC API dead simple. Something like `connect(ServiceBlockingStub.class)` was in your code and it would instantly pull configs, build the service, wire up all of our middle wares + logging, etc. You can automate a lot of this which essentially makes the normal level of friction easier.
- ammanley 5y ago
  That's pretty cool. Was there a particular local environment needed to make this work? I recall auto generation being a part of the whole suite, but sounds like you took it up a notch.
  - gravypod 5y ago
    The special sauce was establishing standards that were used across the code base that we could detect. For example, all configs were from environment variables in the form of `<ServiceName>_<DestinationName>_URL` or something. If the foobar services wants to talk to the auth service it would read the environment variable `FOOBAR_AUTH_URL`. Then, from conventions like this you can build libraries/tools and layer them on to simplify. The way you write your deployments can also know about this convention and automatically generate the environment variables you need (didn't get to this point). I hope one day I get a chance to work on building some tooling like this, open sourcing it, and making it easy for others to adopt a similar mentality.

gravypod 5y ago

One thing that was doable in my last company where I used gRPC was I made interfacing with the gRPC API dead simple. Something like `connect(ServiceBlockingStub.class)` was in your code and it would instantly pull configs, build the service, wire up all of our middle wares + logging, etc. You can automate a lot of this which essentially makes the normal level of friction easier.

ammanley 5y ago
That's pretty cool. Was there a particular local environment needed to make this work? I recall auto generation being a part of the whole suite, but sounds like you took it up a notch.
- gravypod 5y ago
  The special sauce was establishing standards that were used across the code base that we could detect. For example, all configs were from environment variables in the form of `<ServiceName>_<DestinationName>_URL` or something. If the foobar services wants to talk to the auth service it would read the environment variable `FOOBAR_AUTH_URL`. Then, from conventions like this you can build libraries/tools and layer them on to simplify. The way you write your deployments can also know about this convention and automatically generate the environment variables you need (didn't get to this point). I hope one day I get a chance to work on building some tooling like this, open sourcing it, and making it easy for others to adopt a similar mentality.