Hacker News Reader

Comment by pm90 | Hacker News Reader

> A bi-directional API layer between the Control Plane and the Data Plane defines the only integration point between the two planes. We decided to go with a REST API for the following reasons:

> REST APIs are independent of technology used, which helps avoid any dependency between Control Plane and Data Plane. We were able to change the language from Python to Golang in the Data Plane without any changes or impact to the Control Plane. They offer a lot of flexibility, decoupling various server components which can evolve independently. > They can scale efficiently due to the stateless nature of the requests - the server completes every client request independently of previous requests.

Im not sure what REST apis are being compared against? Something like RPCs? If so, then using an interchange format like protobufs allows for automatic client generation in several languages. Additionally, schema changes are much less painful.

View on HN

> using an interchange format like protobufs allows for automatic client generation in several languages

Maybe things have improved, and maybe I was using the "wrong" languages, but when we tried this at a previous company the generated code was deemed so awful that we abandoned that idea almost on day 1. To this day I tend to believe the promise of "write once, generate anywhere!" to be mostly BS.

Not even picking on protobuf specifically here - last time I tried a REST generative approach (swagger?) the results were similarly unusable. The whole concept is a fantasy, unless things have staggeringly improved.

I've had really good luck with gRPC + protobufs for generating solid client side code. Swagger + REST never seemed to deliver what it promised but then again, neither did SOAP + WSDL.

Mind sharing what the client side languages were? Admittedly what I was using at the time was ruby, hardly a priority for the google team I imagine.

We’re actually finding good success with GraphQL codegen, specifically for a Go backend and Apollo + TypeScript frontend.

Out of all the options for generating typesafe interfaces this seems the most flexible and generates usable code.

What do you mean “awful”? You’re not meant to read it. We don’t even materialize it into our repos - the build system generates it at compile time. When you go-to-definition in there it’s a little weird, but it works.

>Im not sure what REST apis are being compared against? Something like RPCs? If so, then using an interchange format like protobufs allows for automatic client generation in several languages. Additionally, schema changes are much less painful.

It's so much more expensive in the long run, though. Everything talks in HTTP. Everyone can read and understand HTTP. Proprietary binary protocols add a layer of complexity to literally everything else you do, and require a translation layer to talk to the front end.

Yeah, I’m not sure why they need to justify REST APIs in 2023?

Probably to prevent readers asking questions like ‘why not gRPC’.

Fair enough, I’m surprised no one has asked about GraphQL yet.

GraphQL is REST (normal POST against /graphql usually). It’s just a grammar by which you retrieve information.

Depending on your definition of REST I guess, what you describe is just saying GraphQL works over HTTP, but I certainly wouldn’t call it RESTful in the slightest.

GraphQL is an entire API definition. Yes, it’s available at a specific POST endpoint - but that does not make it RESTful.

Having also spent time at a GraphQL company, I keep expecting this question too ;)

But, as of yet, it has not come up.

Reply on news.ycombinator.com