[bairen]

We ended up wrapping them in envoy so that our UI can convert the grpc to regular old http 1. And that's where they get the most use.

And by doing that we've added extra layers and it ended up slower than it would have been had we just used regular rest.

Further more now we need to keep evoy up to date.

Occasionally they break their API on major versions. Their config files are complicated and confusing.

So, imo, grpc should only be used for service to service communication where you don't want to share the code with a UI and speed and throughput is very very important.

And speed of http 1 rarely is the bottleneck.

[beeboobaa3]

But... Why? How is envoy, a proxy, related to your choice to use protobuf? How are your gripes with envoy relevant? This just smells like bad design

[bairen]

Yes, using envoy was bad design in our situation. It was premature optimisation.

We could either maintain a grpc API and a rest API , or a grpc API plus envoy, or 1 rest API.

I am saying we should have picked 1 rest API and only switched to grpc if and when we ran into scaling problems.

Avoiding having to maintain grpc compilers and envoy in our security updates.

[skinner927]

So why did you choose to use grpc if you were just going to have to convert it?

[bairen]

We use a few of the endpoints in the backend. Service to service communication.

Those same endpoints are used with envoy. By our UI.

That choice was made to reduce code bloat.

Rather than maintain grpc and envoy it's easier to just maintain 1 rest API.

The service to service communication was never a bottle neck.

So it was highly prematurely optimized.

We spend way more time keeping evoy and our grpc compilers up to date and free of security issues than I would like.

It's just extra software and thus extra attack surfaces we didn't need. In retrospect