Out of curiosity, are you looking to interface with a resource that provides GraphQL support or are you looking to implement your own support for GraphQL APIs?
Interface with an external .We currently have a very minimal integartion thats fairly new.
They support GraphQL and REST APIs but are apparently deprecting the REST API calls. Responses will be in JSON so SRP_JSON/X can still be used to process responses internally.
No problems. We can build the GraphQL structure manually, like we did with JSON before I discovered the joys of SRP_JSON!
No, that's not what I'm saying. I'm sure it offers quite a few benefits but these aren't benefits that are better than or more than pre-existing solutions. I think GraphQL was created because some were under the impression that REST APIs aren't suitable for these kinds of queries. I disagree, which is why I think it is a solution that didn't to exist.
We agree that GraphQL is a solution to a problem that didn't exist. We're noticing some larger platforms are moving to purely GraphQL (such as Shopify) though and we're wondering if this will be an ongoing trend we should prepare for on our platform. Is there a tipping point where you would feel compelled to develop a GraphQL query solution at SRP if this is the way the industry goes?
Hi Shane - Sure, I imagine there could be a tipping point where we would create something like SRP GraphQL.
I also assume that you are mostly interested in a way to build a GraphQL structure versus parsing one, at least for now. Is that correct?
We tend to think about building something for ourselves when the use cases become more commonplace. Thus far, for whatever reasons, this hasn't been the case.
We also build things when there are client requests. Thus far, no client has requested this.
A quick bit of looking shows that there are some open source C++ libraries for GraphQL, including this builder and this parser. Thus, it probably wouldn't be a huge lift to create our own utility, but that assumes these libraries are good.
Thanks Don, that's correct we're really only looking to build the Query structure as the response looks to come in JSON for the integrations we've come across.
Will keep that in mind and let you know if this is something we need to engage as billable work with yourself down the track (which may be looking likely).
Comments
They support GraphQL and REST APIs but are apparently deprecting the REST API calls. Responses will be in JSON so SRP_JSON/X can still be used to process responses internally.
No problems. We can build the GraphQL structure manually, like we did with JSON before I discovered the joys of SRP_JSON!
This is one reason I'm not a fan of GraphQL. I also think it is a solution that didn't need to exist.
We agree that GraphQL is a solution to a problem that didn't exist. We're noticing some larger platforms are moving to purely GraphQL (such as Shopify) though and we're wondering if this will be an ongoing trend we should prepare for on our platform. Is there a tipping point where you would feel compelled to develop a GraphQL query solution at SRP if this is the way the industry goes?
Kind Regards
Shane
I also assume that you are mostly interested in a way to build a GraphQL structure versus parsing one, at least for now. Is that correct?
We tend to think about building something for ourselves when the use cases become more commonplace. Thus far, for whatever reasons, this hasn't been the case.
We also build things when there are client requests. Thus far, no client has requested this.
A quick bit of looking shows that there are some open source C++ libraries for GraphQL, including this builder and this parser. Thus, it probably wouldn't be a huge lift to create our own utility, but that assumes these libraries are good.
Will keep that in mind and let you know if this is something we need to engage as billable work with yourself down the track (which may be looking likely).
Kind Regards
Shane