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

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

spatialos.improbable.io

Post reply on HN
Print view View original

111–120 of 139 posts

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

#111

Post by deno »

j_s wrote: post #110
deno wrote: post #100

Earlier quoted context omitted.

You can easily write an extension to in-browser Dev Tools to show human-friendly representation of any binary protocol for development/debugging purpose.

Nice. Are you aware of any Chrome extension for decoding Flash's 'application/x-amf' Action Message Format like Burp, Charles, and this Firefox extension do? https://addons.mozilla.org/en-US/firefox/addon/amf-explorer/

Nope, sorry! But Firefox addons will be soon switching to extension format compatible with Chrome, so you might get it for “free.”

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

#112

Post by daliwali »

wstrange wrote: post #91
daliwali wrote: post #48

Earlier quoted context omitted.

I made a small mistake in the first point, got downvoted to oblivion and people seemed to stop reading there: the binary serialization indeed has backwards and forwards compatibility. However, the textual serialization lacks this compatibility. I can't remember a petty detail of a vendor specification apparently. Pedants with encyclopedic knowledge of Google are out in full force today! I should have stopped at "coup…

Practically speaking, most REST based servers and clients are tightly coupled anyways. That is why SDKs are so popular with developers. They just want to call a method and not be concerned with how the bits get across the wire. And please do not cite the browser as a good example of a REST client. The browser is driven by an advanced AI (namely a human). We are not there yet with machine to machine interactions, and…

A good rule of thumb is that if a REST API has an SDK, then it's not really RESTful in the first place.

SDKs are an enormous effort to create and maintain for every HTTP API, I think it's a malpractice that is all too common.

Browsers (and by extension, websites) are not good examples of REST in practice? I don't know what world you're in.

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

#113

Post by oconnore »

lvh wrote: post #39
lstroud wrote: post #26

Stub generation? Remote access protocols? CORBA all over again? So, now I know the next big thing. Portable distributed objects. :-P

CORBA tried to make remote calls look local. Making them look remote (and potentially even making some local calls look remote) is a very different design principle that leaks through almost every bit of the standard, and definitely leaks through to every bit of the implementation.

It's funny to complain about CORBA's local/remote muddling in 2017 when we have moved on to microservices that also talk to each other locally with TCP/IP.

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

#114

Post by daliwali »

euyyn wrote: post #107
daliwali wrote: post #82

Earlier quoted context omitted.

Actually gRPC is about the same as other HTTP based APIs, it is just a more efficient RPC. All of them are lacking what made the web scalable in the first place. - HTTP APIs are worse than websites of the 90s. At least a browser could be expected to view a few websites. HTTP APIs require a custom client for each one. - Document media types, not APIs. This isn't such a novel concept, browsers (fancy HTTP clients) work…

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 a comeback: widespread interoperability is not much of a concern.

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

#115

Post by kybernetikos »

computerex wrote: post #92
cle wrote: post #60

Earlier quoted context omitted.

JSON is just a serialization format. Everything you send over the wire is just a bunch of bytes, including JSON and protobuf. JSON has types, and you can use it with a typed RPC system just fine. Whether or not clients can deserialize something you send them can't be known statically, even with protobuf. > What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system? Nothing. And the same applies to a ty…

Yes you don't have the guarantees of statically compiled/linked code but the entire point of using protobufs is that if you use the generated interfaces, you'll end up with fast binary serialization/de-serialization with type safety. That's a lot better than just using JSON. Which is very verbose. You could of course make your own protocol and type system and use JSON for transmission. Why bother when this is done fo…

> fast binary serialization/de-serialization with type safety

I'm not sure about Protobuf3, but certainly the older versions of protobuf could never be as fast as some other formats, because the message layouts were dynamic, meaning that you had to have lots of branches in the reading code.

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

#116

Post by wstrange »

daliwali wrote: post #112
wstrange wrote: post #91

Earlier quoted context omitted.

Practically speaking, most REST based servers and clients are tightly coupled anyways. That is why SDKs are so popular with developers. They just want to call a method and not be concerned with how the bits get across the wire. And please do not cite the browser as a good example of a REST client. The browser is driven by an advanced AI (namely a human). We are not there yet with machine to machine interactions, and…

A good rule of thumb is that if a REST API has an SDK, then it's not really RESTful in the first place. SDKs are an enormous effort to create and maintain for every HTTP API, I think it's a malpractice that is all too common. Browsers (and by extension, websites) are not good examples of REST in practice? I don't know what world you're in.

> SDKs are an enormous effort to create and maintain for every HTTP API,

Hence the attraction of generating client and server stubs with gRPC

> Browsers (and by extension, websites) are not good examples of REST in practice?

The "client" of a website is a human being - and we are very good at interpreting dynamic content.

As an example: There are probably 100+ websites out there where you can book a ticket for a flight. It might be painful, but as a human, I can figure out how to navigate and book a flight on any of those systems.

I challenge you to write a REST client that can do the same.

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

#117

Post by kybernetikos »

decwakeboarder wrote: post #34
andrewingram wrote: post #6

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.

You should also test the speed. JSON.parse is surprisingly fast in modern browsers and binary access is surprisingly slow.

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

#118

Post by daliwali »

wstrange wrote: post #116
daliwali wrote: post #112

Earlier quoted context omitted.

A good rule of thumb is that if a REST API has an SDK, then it's not really RESTful in the first place. SDKs are an enormous effort to create and maintain for every HTTP API, I think it's a malpractice that is all too common. Browsers (and by extension, websites) are not good examples of REST in practice? I don't know what world you're in.

> SDKs are an enormous effort to create and maintain for every HTTP API, Hence the attraction of generating client and server stubs with gRPC > Browsers (and by extension, websites) are not good examples of REST in practice? The "client" of a website is a human being - and we are very good at interpreting dynamic content. As an example: There are probably 100+ websites out there where you can book a ticket for a flig…

Every single one of those websites use HTML, a common media type, with semantics defined in that standard. What's missing are the application-level semantics like what's a "flight search" and "flight booking", which can be solved with linked data. In fact, this already exists! [0]

In theory, using a common media type and linked data vocabulary, one can make this hypothetical scenario of an automated machine-to-machine flight booking system happen. In practice, it requires either changing how people think, or build APIs to begin with. It's a steep uphill battle to change how people think, making this happen is much easier.

[0]: https://schema.org/FlightReservation

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

#119

Post by IshKebab »

cle wrote: post #60
IshKebab wrote: post #55

Earlier quoted context omitted.

> There's nothing about REST+JSON that prevents type safety, as far as I'm aware. Well, except for the fact that JSON is pretty much untyped? I don't understand what there is to not get. If you want type safe RPC you have to use an RPC system that at least has types ! What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system?

JSON is just a serialization format. Everything you send over the wire is just a bunch of bytes, including JSON and protobuf. JSON has types, and you can use it with a typed RPC system just fine. Whether or not clients can deserialize something you send them can't be known statically, even with protobuf. > What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system? Nothing. And the same applies to a ty…

> And the same applies to a typed RPC.

Erm. It clearly doesn't. Because with typed RPC the generated functions will be something like this:

    sendDetails(name: string, age: int);
And you'll get a compile error if you use the wrong type (assuming you are using a language with proper typing - which they are). With JSON you can't do that (without crazy hacks anyway).

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

#120

Post by IshKebab »

neon_electro wrote: post #57
IshKebab wrote: post #53

They sure do like spikes... whatever that means.

"A spike is a product-testing method that is used to determine how much work will be required to solve or work around a software issue." [1] [1] https://en.wikipedia.org/wiki/Spike_(software_development)

Ah, agile mumbo-jumbo.
Post reply on HN