04-03-2023 11:07 PM - edited 04-03-2023 11:09 PM
A few years ago, in my "Monday Morning Thoughts" series, I published this post:
Monday morning thoughts: considering GraphQL
in which I looked into GraphQL and how it compares to HTTP, REST and OData.
Yesterday I read and tooted about an article GraphQL: From Excitement to Deception which got me thinking again.
While I would of course encourage you to read both posts, I'd also love to know what you think about GraphQL, and about the thought conveyed in deliberately provocative title of this discussion.
I remember the advent of SOAP, and the dismay I felt in how it was over complex, orthogonal to HTTP (some might go so far as to say it abused HTTP as an application protocol), and not the golden solution to the perceived challenges.
GraphQL reminds me a lot of SOAP and those memories.
Change my mind! Point out the error of my ways! What do you think? I'd love to know.
04-04-2023 10:14 AM
I get the comparison - but I'm not sure about it because I sort of think SOAP is... better? GraphQL is overrated while SOAP is underrated.
SOAP is still used many critical path business integrations today. While clunky for newbies to get their heads around - its been proven at this point that a really well architected SOAP integration can carry on undisturbed for decades. A lot of SOAP to REST conversion projects overlap with EDI to API conversion projects - technically sounds nice but may not have real meaningful business value and introduce unnecessary new risk to apps. Sometimes its best to just let that SOAP do the thing its already doing really well. Very importantly - sometimes when it seems like the SOAP service is screwing you, its actually because you screwed it first. There's robust features in SOAP for error handling that easily get taken for granted if you don't replicate similar logging/error capture in your supposed new and improved REST service.
GraphQL APIs on the other hand notable examples that deprecated in business use relatively quickly. With some grumbles, but relatively few real show stoppers. This is sort of a good thing, but makes you wonder: why was GraphQL ever needed in the first place? If I remove GraphQL support from a production API, does anyone care? If I design particularly for GraphQL, what's the benefit really achieved that I couldn't already do with openAPI/Swagger or oData?
04-04-2023 10:38 PM - edited 04-04-2023 10:39 PM
Hey Ryan, great to see you here, and thanks for replying. I don't doubt that SOAP is still alive and kicking and supporting integrations that have run for years. I was around when SOAP came about, and had a ringside seat (as a member of various mailing lists and discussions) in the early days. What I saw in those early days (when SOAP still stood for "Simple Object Access Protocol") was anything but "simple", a hybrid (in the original meaning of the word, i.e. "arrogance" or "insult [to one or both of the species]") concoction of a request-response* protocol embedded in an existing request-response protocol (HTTP) while ignoring all that latter protocol's qualities (and effectively using it merely as a transport).
*SOAP did have a document oriented approach to use too, and we still see that in places, but request-response was the norm.
What I also saw in the early days was interoperability chaos, which arguably is not the case with GraphQL, but time will tell.
Anyway, you make some great points, and I'm glad that you have contributed to the discussion. To your (perhaps rhetorical) question about why GraphQL was ever needed in the first place, the answer lies with what Facebook (now Meta, I guess) was trying to do with their mobile clients and with efficiency of API calls. The reason is of course more complex than that, but basically it was all about trying to address the multiplicity of HTTP requests to fulfil an app's data requirements.
That said, one of the things I find the most fascinating is that the (perceived) shortcomings (of HTTP or REST) described in this context, the ground for inventing GraphQL, seems to completely ignore the features of perhaps the most widespread and well-established REST based protocol out there (and which you mention): OData.
A lot of the "too many multiple calls to too many HTTP endpoints" criticism levelled at the REST approach seems to be a little naïve, perhaps deliberately so, in that perhaps the solution would be to improve the design of those endpoints (or adopt OData) rather than invent an entirely new approach.
Anyway, food for thought, thanks again!