|
|
|
|
|
by hardwaresofton
1949 days ago
|
|
It looks like you've picked the right tool for the job in that case, and I can't argue with that -- but the submission is for tooling that people have created in Swift for a problem that was already relatively solved by OpenAPI bindings for Swift. Would you mind going into what that low value server code was doing? Was it simply aggregating results of multiple requests? It's quite possible it wasn't that hard to solve with slightly more intelligent (but not a completely separate paradigm) code to start with. However all-in-all I'm not out to argue that GraphQL doesn't improve velocity. I'm saying that the tooling that it has built in (pipelining, horizontal/vertical filtering, etc) could have been available from REST, and gained all the other benefits without a dramatic paradigm shift but no one seems to have bothered, and instead we're finding ourselves rebuilding bits that were already available/worked out in OpenAPI land for a few features that weren't too far away/hard to implement there. |
|
> Was it simply aggregating results of multiple requests?
Pretty much. The company I was at was an early proponent of microservices so we had to have a service that operated as our entry point to all of it. Thats easy enough, but layering on versioning of the APIs for native apps on different platforms added complexity that definitely didn't seem worth dealing with in our at the time REST paradigm. We did have frameworks that generated clients for different platforms against that API so I'm not even talking about the boilerplate of sending and parsing JSON.