Live data from Hacker News

gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

spatialos.improbable.io

131–139 of 139 posts

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#131

Earlier quoted context omitted.

REST (in the pure sense) vs RPC is a valid comparison, but GraphQL solves a different problem. GraphQL is an alternative to other gateway API or backend-for-frontend solutions. The benefits of a gateway API to both developers AND users are hugely significant. These are decidedly NOT micro-optimisation.

What's a gateway API? I acknowledge, I don't do a lot of frontend work. As I see it, GraphQL is just a query syntax that uses a JSON like language and where the query engine is built in code on the backend. You could replace all queries by REST requests, or build your own query language on top of JSON or RPC. In my experience though, anything approaching a query language was too expressive for an API, and it was bett…

Gateway APIs: http://microservices.io/patterns/apigateway.html

Assuming you've read that then I'd add the following. If you don't have something approaching a gateway, you're probably doing a big disservice to your users (assuming clients fetch data via API, rather than using a traditional render-on-the-server framework like Django or Rails).

The value proposition of GraphQL is based on the assumption you're already doing things right by users, and its possible to fulfill the data requirements for a single page or app screen in a single API call. What this probably means is:

* You have a custom endpoint per screen

* That endpoint to either a) be versioned or b) support as many historical versions of your app as are in production

* You might have a gateway per client (this is the full backend-for-frontend pattern)

* Every time you add functionality, or change existing functionality, you're adding to what quickly becomes a huge set of endpoints

What GraphQL promises (and delivers on) is the ability to get all the benefits of the backend-for-frontend pattern, without anyone ever having to write an endpoint specifically for a give client use case. The clients convert their data requirements into a query, and the GraphQL server returns the exact data you need, no more, no less. It requires some discipline when it comes to evolving the schema over time, but it works really really well. And when implemented intelligently has comparable performance to hand-crafted endpoints (I've written about how to approach this here: https://dev-blog.apollodata.com/optimizing-your-graphql-requ...)

When you experience the front-end workflow of using a library like Relay or Apollo (both are GraphQL clients) and having perfect synchronisation with UI and data, it's a really magical moment. You end up in a world where you can just get on with building UI, it's amazing.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#132

I first saw this one a few weeks ago, and have been trying to weigh up its pros and cons over GraphQL (my tool of choice). gRPC-Web: * Speaks protocol buffers, a fast and compact format compared to JSON * Allows clients to use the same APIs as backend services. GraphQL: * Enables a client-centric view of the system. I have abstractions in my GraphQL server that only make sense to clients. It's a query-centric impleme…

> Speaks protocol buffers, a fast and compact format compared to JSON This is definitely important at Google-scale, but for the rest of us compressed JSON typically isn't that bad.

Last time I tried protocol buffers it was dog slow, json was pretty fast, and msgpack was insane fast. This was on a heavily nested dict of dicts structure.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#133

Earlier quoted context omitted.

It is worth pointing out that the Python implementation is particularly bad. Perhaps gRPC is really pleasant to use with Java and Go, but the Python implementation is neither usable nor stable enough for it to be worth considering its use for one's own services.

My instinct would be that it'll be just inherently nicer to use in a statically-typed language.

Python can be statically typed.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#134
post #107

Earlier quoted context omitted.

I don't understand your point about third-party clients. APIs defined in .proto files can have both clients and servers implemented by anybody.

APIs defined in XMLRPC, CORBA, SOAP, et al, can have clients and servers implemented by anybody. Programmers don't seem to learn from history and struggle with thinking over time. These formats worked well in a time when a single party (or second party) controls the server and client, when services were very consolidated. Now that the web is becoming more and more centralized and closed, it follows that RPC is making…

Sorry but you're not addressing your own point:

> RPC is a great fit if you are constrained to a single vendor and don't care about third-party clients

If I'm not constrained to a single vendor, and care about third-party clients, what makes RPC a bad fit? In specifics, not vague historical comparisons.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#135
post #106

Earlier quoted context omitted.

I agree, I love protobuf and JSONSchema and Thrift, I think they're great ideas that solve important problems. But the hype is getting carried away--they aren't a silver bullet for distributed systems, they're just a way to manage schema. Define a schema in an IDL, and Protobuf/Thrift/whatever generate schema validators and serializer/deserializers for clients and servers. But they are not type safe across systems, a…

Sure, and gRPC doesn't guarantee that the server is turned on when the client makes a request. Some expectations are unreasonable. On the other hand, if you publish one set of proto files and all clients & servers consume these artifacts, the system as a whole is more "typesafe" and reliable than if you just post swagger docs and expect all your developers to check them daily for updates. gRPC means API changes stand…

Couldn't have put it better myself.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#136
post #106

Earlier quoted context omitted.

I agree, I love protobuf and JSONSchema and Thrift, I think they're great ideas that solve important problems. But the hype is getting carried away--they aren't a silver bullet for distributed systems, they're just a way to manage schema. Define a schema in an IDL, and Protobuf/Thrift/whatever generate schema validators and serializer/deserializers for clients and servers. But they are not type safe across systems, a…

Sure, and gRPC doesn't guarantee that the server is turned on when the client makes a request. Some expectations are unreasonable. On the other hand, if you publish one set of proto files and all clients & servers consume these artifacts, the system as a whole is more "typesafe" and reliable than if you just post swagger docs and expect all your developers to check them daily for updates. gRPC means API changes stand…

I agree completely which is why I love proto.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#137

Earlier quoted context omitted.

gRPC generates rpc server and client stubs based off a protocol buffer definition. Saying it's a replacement for REST makes little sense since it's possible to define a REST API within it. It's also possible to write a totally not RESTful API in a modern http api framework. In fact that's what Google's API design guide does. Encourages RESTful API design then describes how to implement them using proto and gRPC. The…

Interesting! When I first looked at gRPC I missed the option(google.api.http). Are you aware of the reason why REST mapped gRPC is not possible in GAE (http 1 only on the server end of our code)?

Probably because it's pretty bleeding edge.

Google Cloud Endpoints, which released earlier in the year, allows you to write a gRPC server, and offers the HTTP proxy as part of the service.

The ecosystem still isn't quite there though. It could be easier to just write a thin webserver that just points at services over tcp (using something like ZeroMQ) rather than writing a service with gRPC from the ground up.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#139
It is still a bit shocking to see how many people are not getting the distinction between an API and a RESTful service.

They are very different things and they have very different goals. The hint is in: how much do you value the client?

If you have full control over both client/server or if we don't care about any 3rd party developing a client library for your service, then go with something like GraphQL or gRPC or SOAP with a nice, typed spec you can generate your code from and optimize the heck out of the bytes coming through the tubes.

If OTOH you have an interest to create a RESTful service that is discoverable, that doesn't require constant client changes, that offer a wider variety of resource representations, that need to stand the test of time, then use HATEOAS and a RESTful architectural style.

gRPC is yet another ... RPC. Nothing good or bad about that. Just make sure you understand the consequences.

Post reply on HN