5 ms·

Is this a replacement or a supplement/alternative to WCF?

fgonzag 7y ago
This is grpc, Google's remote procedure call framework based on protobuffers. You don't really use it to expose public services, you mostly use it when you control both client and server endpoints, such as microservices. 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?)
- mehrdada 7y ago
  > You don't really use it to expose public services 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.
  - james_s_tayler 7y ago
    I haven't played with gRPC much but just trying to get my head around pros and cons and use cases... 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...
    - heavenlyblue 7y ago
      It’s so much better to express your opinion when you at least have read the docs of the technology you are discussing.
      - james_s_tayler 7y ago
        "When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field. The default value can be specified as part of the message description. For example, let's say you want to provide a default value of 10 for a SearchRequest's result_per_page value. 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.
- vmarsy 7y ago
  > You get type marshalling and other niceties 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-compatibility-protobuf-versioning-serialization https://www.beautifulcode.co/blog/88-backward-and-forward-co...
- manigandham 7y ago
  I highly recommend using it for public endpoints too. It's much nicer than worrying about a supported up-to-date client library in your language or using yet another variation of JSON/HTTP/REST that's unique to every API. 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.
  - xarope 7y ago
    I'm starting to steer our dev team towards this as well, would you have any good links to the gotchas involved in using grpc for public endpoints (if coming from REST as a legacy base)? e.g. for authentication and authorization, throttling etc? I looked at kong, but it seems the plugins don't apply to grpc.
    - manigandham 7y ago
      Unfortunately no good reading I know of other than the official GRPC docs.
beauzero 7y ago
You are correct WCF will not be an officially supported part of .net core. I believe an open source port has been started though. gRPC is meant to replace it. https://www.ben-morris.com/why-isnt-wcf-supported-in-net-core/ https://www.ben-morris.com/why-isnt-wcf-supported-in-net-cor...
- beauzero 7y ago
  Without going into a lot of detail. WCF and SOAP were good for http 1 and gRPC is optimized for 2. Edit: spelling
algorithmsRcool 7y ago
Short answer is yes for most workloads. It's fast, scalable and well supported. 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://github.com/dotnet/core/issues/2278 https://github.com/dotnet/core/issues/2278
- pjtr 7y ago
  Are there options for machine local IPC over pipes in .NET Core?
  - avinium 7y ago
    Fairly limited, but anonymous pipes might fit your use case: https://docs.microsoft.com/en-us/dotnet/standard/io/how-to-use-anonymous-pipes-for-local-interprocess-communication https://docs.microsoft.com/en-us/dotnet/standard/io/how-to-u...
- paulio 7y ago
  I might be the only person who liked WCF.
  - algorithmsRcool 7y ago
    I liked kinda liked it, but trying to unify HTTP, TCP, Pipes and MSMQ into a single framework was probably overly ambitious. WCF always felt very complicated with all sorts of sharp edges to me.
    - WorldMaker 7y ago
      WCF also originally supported peer-to-peer network topologies, discovery methods like PNRP (Microsoft's competitor standard to eventual "winner" Bonjour/mDNS), various versions of the SOAP metadata formats, and WS-* standards, etc. 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]

This is grpc, Google's remote procedure call framework based on protobuffers. You don't really use it to expose public services, you mostly use it when you control both client and server endpoints, such as microservices. 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?)

mehrdada 7y ago
> You don't really use it to expose public services 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.
- james_s_tayler 7y ago
  I haven't played with gRPC much but just trying to get my head around pros and cons and use cases... 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...
  - heavenlyblue 7y ago
    It’s so much better to express your opinion when you at least have read the docs of the technology you are discussing.
    - james_s_tayler 7y ago
      "When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field. The default value can be specified as part of the message description. For example, let's say you want to provide a default value of 10 for a SearchRequest's result_per_page value. 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.
vmarsy 7y ago
> You get type marshalling and other niceties 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-compatibility-protobuf-versioning-serialization https://www.beautifulcode.co/blog/88-backward-and-forward-co...
manigandham 7y ago
I highly recommend using it for public endpoints too. It's much nicer than worrying about a supported up-to-date client library in your language or using yet another variation of JSON/HTTP/REST that's unique to every API. 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.
- xarope 7y ago
  I'm starting to steer our dev team towards this as well, would you have any good links to the gotchas involved in using grpc for public endpoints (if coming from REST as a legacy base)? e.g. for authentication and authorization, throttling etc? I looked at kong, but it seems the plugins don't apply to grpc.
  - manigandham 7y ago
    Unfortunately no good reading I know of other than the official GRPC docs.

beauzero 7y ago

You are correct WCF will not be an officially supported part of .net core. I believe an open source port has been started though. gRPC is meant to replace it. https://www.ben-morris.com/why-isnt-wcf-supported-in-net-core/ https://www.ben-morris.com/why-isnt-wcf-supported-in-net-cor...

beauzero 7y ago
Without going into a lot of detail. WCF and SOAP were good for http 1 and gRPC is optimized for 2. Edit: spelling

algorithmsRcool 7y ago

Short answer is yes for most workloads. It's fast, scalable and well supported. 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://github.com/dotnet/core/issues/2278 https://github.com/dotnet/core/issues/2278

pjtr 7y ago
Are there options for machine local IPC over pipes in .NET Core?
- avinium 7y ago
  Fairly limited, but anonymous pipes might fit your use case: https://docs.microsoft.com/en-us/dotnet/standard/io/how-to-use-anonymous-pipes-for-local-interprocess-communication https://docs.microsoft.com/en-us/dotnet/standard/io/how-to-u...
paulio 7y ago
I might be the only person who liked WCF.
- algorithmsRcool 7y ago
  I liked kinda liked it, but trying to unify HTTP, TCP, Pipes and MSMQ into a single framework was probably overly ambitious. WCF always felt very complicated with all sorts of sharp edges to me.
  - WorldMaker 7y ago
    WCF also originally supported peer-to-peer network topologies, discovery methods like PNRP (Microsoft's competitor standard to eventual "winner" Bonjour/mDNS), various versions of the SOAP metadata formats, and WS-* standards, etc. 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]