'GraphQL vs REST: API Design Best Practices For Long-Running Operations' api graphql
I've recently read an article where the author stated that GraphQL is "not appropriate for long-running operations". I'd like to show that GraphQL can very well be used for long-running operations.
From your own perspective, when you click a button on the web, how long until you get nervous when watching the progress bar? You will probably allow the service to run for a few seconds if you understand the complexity of the task. However, we're used to seeing some kind of progress after less than 5 seconds, at least when we're using a desktop browser.
However, as we've said earlier, this operation might take forever to complete and the user might cancel it. A better approach would be to design our API as an asynchronous API.Let's now turn the synchronous API into an asynchronous API. Instead of returning a response immediately, we should return a response with a unique identifier so that the client can poll the server for the result.The request has been received but not yet acted upon.
subscription { jobStatus { __typename ... on SuccessfulJob { id url sentiment } ... on QueuedJob { id url } ... on FailedJob { id url reason } ... on CancelledJob { id url time } } }Comparing REST and GraphQL for long-running operations