Is this a replacement or a supplement/alternative to WCF?
WCF could operate over pipes which was cool for machine local IPC, but beyond that I think gRPC is superior.
But I asked your exact question to the dotnet team and architect David Fowler gave me a decent answer.
> "I don't know that we have a definitive answer as yet and the GRPC experience while great isn't nearly as smooth (as of writing) as the WCF experience. I would say that it's definitely going to be one of the main RPC option of choice going forward but it;s a bit early to say that this is THE blessed new way."
https://docs.microsoft.com/en-us/dotnet/standard/io/how-to-u...
It was definitely ambitious. When it worked it was sometimes magic, and when it didn't it was a giant mess to resolve.
[ETA: In one past life I made the mistake of trying to use WCF Peer-to-Peer for a project and I still have scars from that. :O]
I personally like sharing `interface.cs` rather than what appears very similar `interface.proto` plus a bunch of tooling.
Ahh well, things go in circles I guess.
"The new thing isn't immediately going to replace the old thing going forward" and then it does.
(And it should. I just don't get why they're always tiptoeing around that same point.)
They are just being non-committal about gRPC being the successor. But I have seen Fowler poking around in the RSocket codebase recently, so who knows.
You get type marshalling and other niceties with it that you don't get with REST, and it is much lighter and less complex than SOAP (on which WCF is based). Another decent alternative is json-rpc. Cross-platfofm compatibility is also miles better (ws-security and soap exceptions anybody?)
Why not? Google Cloud certainly does. Google Ads also exposes gRPC API. Google Assistant SDK is basically gRPC too. You get efficient typed client libraries in 10 or more languages for free. No reason not to consider it for public-facing endpoints.
I was under the impression that you can't specify fields as null. Instead they just get assigned whatever the default value is for that type.
That seems like a significant drawback for me if it is indeed the case. Especially in the case of a public facing API.
I like the idea of a lot of client libraries able to generate easily, I'm just not sure on this one point how to deal with it nicely...
optional int32 result_per_page = 3 [default = 10];
If the default value is not specified for an optional element, a type-specific default value is used instead: for strings, the default value is the empty string. For bytes, the default value is the empty byte string. For bools, the default value is false. For numeric types, the default value is zero. For enums, the default value is the first value listed in the enum's type definition. This means care must be taken when adding a value to the beginning of an enum value list. See the Updating A Message Type section for guidelines on how to safely change definitions."
Well according to the docs on protocol buffers at least my understanding is as I have read elsewhere.
I don't know what your problem is guy.
My favorite other nicety is forward and backwards compatibility. Having an older binary being able to easily handle the next version of the incoming proto, and also to not loose any of the not-yet-understood fields.
Short blog giving a concrete example: https://www.beautifulcode.co/blog/88-backward-and-forward-co...
Some databases and queues are starting to use this now and it makes it incredibly easy to get started since we can generate our own clients and integrate at whatever level we need.
Edit: spelling