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 “ …
"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".
I imagine several readers of this article would also be interested in this:
https://queue.acm.org/detail.cfm?id=2716278
It's a short critique of HTTP2 from an annoyed programmer. Am sharing for interest.
>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.
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.
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...
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
