undefined | Better HN

0 pointsbairen1y ago0 comments

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.

0 comments

beeboobaa31y ago

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

bairenOP1y ago

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.

aaomidi1y ago

Grpc isn’t just for scaling though. It’s a schema format that comes with code generation you can technically avoid the code generation if you so please.

Idk I think people are expecting either too much or too little of these tools.

skinner9271y ago

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

bairenOP1y ago

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

j / k navigate · click thread line to collapse

0 pointsbairen1y ago0 comments

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.

0 comments

beeboobaa31y ago

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

bairenOP1y ago

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.

aaomidi1y ago

Grpc isn’t just for scaling though. It’s a schema format that comes with code generation you can technically avoid the code generation if you so please.

Idk I think people are expecting either too much or too little of these tools.

skinner9271y ago

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

bairenOP1y ago

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

j / k navigate · click thread line to collapse