back to article Google open-sources HTTP/2-based RPC framework

Google has open-sourced something called “gRPC” that it says represents “a brand new framework for handling remote procedure calls” using HTTP/2. The Chocolate Factory says it has dogfooded gRPC on its own microservices and that it “enables easy creation of highly performant, scalable APIs and microservices” and offers “ …

  1. Norman Hartnell

    Performant... not a word. Probably.

    1. Joe Harrison

      Re: Performant...

      You're technically correct but surely it's one of those words like "truthiness" that somehow in your heart you want them to be real?

    2. Anonymous Coward
      Anonymous Coward

      Re: Performant...

      "Performant" is a French word which doesn't mean precisely what you are thinking of. "Performative" is an English word that has been around for longer, is already in the dictionary, and does mean what you are thinking of. However, this is not the first time English speakers have ended up using a French word for no reason other than language is wierd that way.

      In formal writing I would still prefer to see "performative".

      1. Eddy Ito

        Re: Performant...

        Wouldn't performant be a cognate of informant and therefore be simply, one who performs?

  2. h4rm0ny

    A critique of HTTP2.

    I imagine several readers of this article would also be interested in this:

    It's a short critique of HTTP2 from an annoyed programmer. Am sharing for interest.

    1. phil dude

      Re: A critique of HTTP2.

      And I didn't notice any corporate shilling at all.../s

      Netflix and Facebook "encryption of media is pointless". (the authors employers)

      And yet, they'll send you to jail for removing the encryption.

      This all feels a little ad hoc...


      1. pixl97

        Re: A critique of HTTP2.

        >Local governments have no desire to spend resources negotiating SSL/TLS with every single smartphone in their area when things explode, rivers flood, or people are poisoned

        Yea, I'm not sure what the writers of that were thinking, but that's exactly when you want the verifiability of TLS. Otherwise a third party could make things worse by pushing out fake updates or bad information. Yes, TLS has it's own issues, but non-TLS has no verifiability at all.

        1. LDS Silver badge

          Re: A critique of HTTP2.

          That's why also his rant about self-signed certificate management is wrong. Browsers are correct to signal a self-signed certificate as dangerous. You have no simple way (but perusing very technical details of them, and matching them against the expected ones) to ensure they're really the same self-signed certificates you expect. Performing MITM against a self-signed cert is pretty straightforward, and then you have really no security - sure, you're protected from casual eavesdropping, but just that.

          I do use my one certificates for example to protect my mail server and web mail, but I actually don't use a simple self-signed cert. I use certs issued by my own CAs. This way I can check they are actually valid.

  3. LDS Silver badge

    Google is trying to reinvent TCP/IP over and over...

    Google is obssessed with HTTP just because it's allowed to bypass firewalls. Thereby is trying to bolt on it everything that is already available in TCP/IP. Just FW will updated and start to inspect HTTP/2 sessions - MITM them if necessary - and decide what is allowed and what is not...

  4. Christian Berger

    I don't quite see where the improvement is supposed to be

    I mean we already have HTTP as a stateless "get your objects" protocol. Just remove the bugs like cookies and wrap it in TLS or its successor.

    For web applications we already have Websocket which provides authentication and session handling. You have a consistent connection which is hard to break into even when not encrypted.

    Where is the advantage of switching to an, apparently, much more complex protocol? HTTP already achieves very well performance. And in situations where HTTP performs badly, at least the SPDY I've heard of performed even worse. (low latency, high packet loss, 100 second round trip times are not uncommon on German mobile networks)

    The disadvantages are clear. A more complex protocol needs more complex code which contains more bugs. Also a more complex protocol might have protocol bugs hidden inside, bugs you cannot fix in your implementation and you will need to support for ever and ever.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020