4 ms·

Yes, it has come full circle - but SOAP XML and friends were rightfully despised. The spec is a mess and there are so many broken implementations all over the p

by lima 8y ago

Yes, it has come full circle - but SOAP XML and friends were rightfully despised. The spec is a mess and there are so many broken implementations all over the place. I have fond memories of debugging the PHP SOAP client in order to build a bug-by-bug compatible Python version :-) gRPC and other modern RPC protocols/SOA frameworks are basically "the good parts from SOAP".

vbezhenar 8y ago
I feel that the difference is that SOAP was a proper spec made by multiple parties, for better or worse. And GRPC is just a published spec from Google with code from Google. Of course it won't be such a mess and it will be good enough. Is it good to rely on Google adopting its tech as an industry standard? That's a philosophical question.
- thisgoodlife 8y ago
  I personally use this rule to decide whether I should use a Google service/library: it has to have more than 1 billion active users or it's an important part of such services. gRpc more specifically protobuf, imo, is very important to Google. So I won't be worried about its future.
- skybrian 8y ago
  From a philosophical point of view, it seems like a design critique should be focused more on the design and less about where it came from? (Assuming it's open source and there aren't intellectual property issues.) Industry standards tend to take on a life of their own, even if they came from one company. (Consider Docker.)
- dankohn1 8y ago
  gRPC was contributed by Google to CNCF. Google remains extremely engaged in its ongoing development. https://www.cncf.io/projects/ https://www.cncf.io/projects/ You might also be interested that Google is hosting the first ever gRPC Conf, which is being organized by CNCF the gRPC community: https://events.linuxfoundation.org/events/grpconf-2019/ https://events.linuxfoundation.org/events/grpconf-2019/ (Disclosure: I'm executive director of CNCF.)
pbowyer 8y ago
> I have fond memories of debugging the PHP SOAP client It's no better now :) I use it frequently with SOAP endpoints from various companies (all with varying authentication measures/encodings/versions) and it's a nightmare. Unfortunately the travel industry hasn't gone for anything else yet...
- core-questions 8y ago
  I used to use https://github.com/econea/nusoap https://github.com/econea/nusoap back in the day, take a look

by lima 8y ago

vbezhenar 8y ago

I feel that the difference is that SOAP was a proper spec made by multiple parties, for better or worse. And GRPC is just a published spec from Google with code from Google. Of course it won't be such a mess and it will be good enough. Is it good to rely on Google adopting its tech as an industry standard? That's a philosophical question.

thisgoodlife 8y ago
I personally use this rule to decide whether I should use a Google service/library: it has to have more than 1 billion active users or it's an important part of such services. gRpc more specifically protobuf, imo, is very important to Google. So I won't be worried about its future.
skybrian 8y ago
From a philosophical point of view, it seems like a design critique should be focused more on the design and less about where it came from? (Assuming it's open source and there aren't intellectual property issues.) Industry standards tend to take on a life of their own, even if they came from one company. (Consider Docker.)
dankohn1 8y ago
gRPC was contributed by Google to CNCF. Google remains extremely engaged in its ongoing development. https://www.cncf.io/projects/ https://www.cncf.io/projects/ You might also be interested that Google is hosting the first ever gRPC Conf, which is being organized by CNCF the gRPC community: https://events.linuxfoundation.org/events/grpconf-2019/ https://events.linuxfoundation.org/events/grpconf-2019/ (Disclosure: I'm executive director of CNCF.)

pbowyer 8y ago

> I have fond memories of debugging the PHP SOAP client It's no better now :) I use it frequently with SOAP endpoints from various companies (all with varying authentication measures/encodings/versions) and it's a nightmare. Unfortunately the travel industry hasn't gone for anything else yet...

core-questions 8y ago
I used to use https://github.com/econea/nusoap https://github.com/econea/nusoap back in the day, take a look