Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

cloud.google.com

Post reply on HN
Print view View original

221–230 of 286 posts

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#221

Post by masterj »

thayne wrote: post #151
jon_richards wrote: post #86

I've been having fun with connectrpc https://connectrpc.com/ It fixes a lot of the problematic stuff with grpc and I'm excited for webtransport to finally be accepted by safari so connectrpc can develop better streaming. I initially thought https://buf.build was overkill, but the killer feature was being able to import 3rd party proto files without having to download them individually: deps: - buf.build/landeed/proto…

It still uses protocol buffers though, which is where many of the problems I have with gRPC comes from

You can also choose to use JSON instead. Works great with curl and browser dev tools.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#222

Post by cloverich »

nsonha wrote: post #48
lmm wrote: post #29

Earlier quoted context omitted.

> You can’t just give someone a simple command to call an endpoint—it requires additional tooling that isn’t standardized. GRPC is a standard in all the ways that matter. It (or Thrift) is a breath of fresh air compared to doing it all by hand - write down your data types and function signatures, get something that you can actually call like a function (clearly separated from an actual function function - as it shoul…

> GraphQL is even better just a casual sentence at the end? How about no. It's in the name, a query-oriented API, useless if you don't need flexible queries. Why don't you address the problem they talked about, what is the cli tool I can use to test grpc, what about gui client?

> a query-oriented API, useless if you don't need flexible queries

Right but, the typical web service at the typical startup does need flexible queries. I feel people both overestimate its implications and under estimate its value.

    - Standard "I need everything" in the model call
    - Simplified "I need two properties call", like id + display name for a dropdown
    - I need everything + a few related fields, which maybe require elevated permissions
GraphQL makes that very easy to support, test, and monitor in a very standard way. You can build something similar with REST, its just very ergonomic and natural in GraphQL. And its especially valuable as your startup grows, and some of your services become "Key" services used by a wider variety of use cases. Its not perfect or something everyone should use sure, but I believe a _lot_ of startup developers would be more efficient and satisfied using GraphQL.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#223

Post by taeric »

By far the worst part of OpenAPI is how aspirational the documentation seems to remain. It seems it is always leveraging things that almost worked in the previous version with advice on how it should be done. But if you do the new way, expect that about half of the tooling you find won't work.

It really is WSDL all over again. Where if you buy in to a specific vendor's tooling, and don't leave it, things actually do mostly work as advertised. You want to piecemeal anything, and holy crap at the unexpected pitches.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#224

Post by bluGill »

hedora wrote: post #99
inetknght wrote: post #85

Earlier quoted context omitted.

> Because of the generated message definition stubs (which require additional tooling), clients almost never send malformed requests and the servers send a well understood response. Sure. Until you need some fields to be optional. > This makes stable APIs so much easier to integrate with. Only on your first iteration. After a year or two of iterating you're back to JSON, checking if fields exist, and re-validating yo…

There’s also a gaping security hole in its design. They don’t have sane support for protocol versioning or required fields, so every field of every type ends up being optional in practice. So, if a message has N fields, there are 2^N combinations of fields that the generated stubs will accept and pass to you, and its up to business logic to decide which combinations are valid. It’s actually worse than that, since the…

I have yet to see a good way to do backward compatibility in anything. The only thing I've found that really works is sometimes you can add an argument with a default value. Removing an argument only works if everyone is using the same value of it anyway - otherwise they are expecting the behavior that other value causes and so you can't remove it.

Thus all arguments should be required in my opinion. If you make a change add a whole new function with the new arguments. If allowed the new function can have the same time (if overloading should be done this way is somewhat controversial - I'm coming out in favor but the arguments against do make good points which may be compelling to you). That way the complexity is managed since there is only a limited subset of the combinatorial explosion possible.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#225

Post by Pooge »

oppositelock wrote: post #98

I've been building API's for a long time, using gRPC, and HTTP/REST (we'll not go into CORBA or DCOM, because I'll cry). To that end, I've open sourced a Go library for generating your clients and servers from OpenAPI specs ( https://github.com/oapi-codegen/oapi-codegen ). I disagree with the way this article breaks down the options. There is no difference between OpenAPI and REST, it's a strange distinction. OpenAPI…

> https://github.com/oapi-codegen/oapi-codegen

I'm using it for a small personal project! Works very well. Thank you!

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#226

Post by tbarbugli »

stickfigure wrote: post #113
jdwyah wrote: post #76

If I could go back in time I would stop myself from ever learning about gRPC. I was so into the dream, but years later way too many headaches. Don’t do it to yourself. Saying gRPC hides the internals is a joke. You’ll get internals all right, when you’re blasting debug logging trying to figure out what the f is going on causing 1/10 requests to fail and fine tuning 10-20 different poorly named and timeout / retry set…

IMO the problem with gRPC isn't the protocol or the protobufs, but the terrible tooling - at least on the Java end. It generates shit code with awful developer ergonomics. When you run the protobuf builder... * The client stub is a concrete final class. It can't be mocked in tests. * When implementing a server, you have to extend a concrete class (not an interface). * The server method has an async method signature.…

In my experience, only Swift has a generator that produces good-quality code. Ironically, it’s developed by Apple.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#227

Post by coolhand2120 »

lmm wrote: post #29
rednafi wrote: post #13

Google somehow psyoped the entire industry to use gRPC for internal service communications. The devex of gRPC is considerably worse than REST. You can’t just give someone a simple command to call an endpoint—it requires additional tooling that isn’t standardized. Plus, the generated client-side code is some of the ugliest gunk you’ll find in any language.

> You can’t just give someone a simple command to call an endpoint—it requires additional tooling that isn’t standardized. GRPC is a standard in all the ways that matter. It (or Thrift) is a breath of fresh air compared to doing it all by hand - write down your data types and function signatures, get something that you can actually call like a function (clearly separated from an actual function function - as it shoul…

> GraphQL is even better.

Letting clients introduce load into the system without understanding the big O impact of the SOA upstream is a foot gun. This does not scale and results in a massive waste of money on unnecessary CPU cycles on O(log n) FK joins and O(n^2) aggregators.

Precomputed data in the shape of the client's data access pattern is the way to go. Frontload your CPU cycles with CQRS. Running all your compute at runtime is a terrible experience for users (slow, uncachable, geo origin slow too) and creates total chaos for backend service scaling (Who's going to use what resource next? Nobody knows!).

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#228

Post by foobarian »

ak217 wrote: post #135
physicles wrote: post #111

Earlier quoted context omitted.

> There is no difference between OpenAPI and REST, it's a strange distinction. That threw me off too. What the article calls REST, I understand to be closer to HATEOAS. > I've open sourced a Go library for generating your clients and servers from OpenAPI specs As a maintainer of a couple pretty substantial APIs with internal and external clients, I'm really struggling to understand the workflow that starts with gener…

In my part of the industry, a rite of passage is coming up with one's own homegrown data pipeline workflow manager/DAG execution engine. In the OpenAPI world, the equivalent must be writing one's own OpenAPI spec generator that scans an annotated server codebase, probably bundled with a client codegen tool as well. I know I've written one (mine too was a proper abomination) and it sounds like so have a few others in…

> In the OpenAPI world, the equivalent must be writing one's own OpenAPI spec generator

Close, it's writing custom client and server codegen that actually have working support for oneOf polymorphism and whatever other weird home-grown extensions there are.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#229

Post by bmilleare »

I'm not sure why the article picks these 3 options as if that's it.

An RPC API can happily exist over plain old HTTP/1 (no protobuf required) and it also doesn't mention the primary benefit of RPC over REST/RESTish (IMO) - and that's the ability to stack multiple RPC calls into a single request.

Post reply on HN