-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[apollo-datasource-rest] Handling 404 errors #203
Comments
I am also looking for best practices on this... My current challenge is how to handle this during a server-side render(SSR). In the case of the REST API returning a 404, it causes a 404 error to be thrown, which then has to be handled within a catch statement. I have logic in the Query component for handling this behavior but during a SSR this logic is never hit because it throws exceptions instead. Your solution is an option but painful like you said. Another option, which I am not happy with, is setting the errorPolicy="all" on the Query component. This causes the SSR to succeed and allows the apollo client to cache all the other successful responses. However, it then causes the client to re-issue the request and handle it accordingly, which results in the re-issuing same request the server already performed. |
I just ran into this myself, although in my case it was in the context of testing with an intentionally bad id for the API I'm hitting - i.e. Here's a less painful version of the original solution, making use of the fact that return dataSources.listingApi.getListing(args.reference)
.catch(err => {
if(err.extensions.response.status === 404) {
return null;
}
throw err;
}
})
.catch(err => ((err.extensions.response.status === 404) ? null : throw err) |
From my understanding of GraphQL data that is not available as part of a request should be returned as null, therefore allowing other parts of the query to return for the client to render as best.
If this is the case and your rest API returns 404 status codes however you'll need to write something like the following to capture the errors and return null;
This works but isn't particularly elegant for what seems to be a common use case. Have I misunderstood how to deal with 404 errors in GraphQL or is this part of the rest datasource that could have better handling around it?
I'd be interested to know how other people are dealing with this in a more elegant manor or at least encapsulating the null return inside the class which extends
RESTDataSource
. From skimming the code this didn't look easy to handle without rewriting some of the protected methods.The text was updated successfully, but these errors were encountered: