Lanny Gilbert wrote:How much more effort will it be to implement a GraphQL version of the server-side code vs. ReST? Or is the effort the same (more or less)?
That's hard to say without seeing the actual REST API, but in most such APIs I've seen you do not have the capability to specify which parts of the data you want to get, exactly. You can usually specify things like a search term, or an ID for a specific data record, or a maximum number of items to fetch etc., but not select which data attributes, specifically, are returned. So the server-side code would not have the logic to deal with this. Which means that this question:
Our clients, for the most part, want to do as little as possible in order to comply with the change from CORBA and/or SOAP to ReST or GraphQL.
Given that these APIs have been around for 15-20 years, is it worth building GraphQL, with all its flexibility, instead of ReST, given that the clients will be sending and receiving the same data points, only in JSON format rather than wrapped up in CORBA or SOAP cruft?
is really: does the client want to build in that kind of flexibility, now that the code needs to be substantially touched anyway? I'd say there's no general rule to decide either way, but if the APIs have been running for 15 years without changes as to what data is returned (or even 5 years), and there's no call for that kind of flexibility NOW, then it's probably safe to say that building this capability would be misguided at the moment.
When building systems, it's always tempting to build in flexibility to accommodate future changes, but quite often the flexibility that's eventually required is different from the flexibility one envisions at the start (before the system is actually used). So in general, if the client is not asking for it, and you have no other reasons to suspect that it may be needed soon -which, obviously, you would discuss with the client- I'd say go without GraphQL.
Rancher Scavenger Hunt
Number Posts (43027/500)
Number Threads Started (168/200)