You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Goal: Establish sensible defaults for GQty error handling in generated client for Pylon.
In my previous issue, I provided a general outline of how GQty could function on the server side. This issue is specifically addressing error handling in a Pylon backend services using GQty:
4. Error Handling with resolve
Unclear Documentation
GQty’s documentation doesn’t clearly demonstrate how to handle GraphQL errors when using resolve on the server. If there are recommended patterns or best practices, I’d love to learn about them ❤
With some assistance from the Discord community, I implemented a general error handling strategy for my web service by modifying the generated client/index.ts as shown below. Since I’m utilizing GQty’s resolve(), I expect to receive only one GraphQL error per request, so I handle it using error.graphQLErrors[0]:
/** * GQty: You can safely modify this file based on your needs. */import{Cache,createClient,defaultResponseHandler,GQtyError,typeQueryFetcher,}from'gqty';import{generatedSchema,scalarsEnumsHash,typeGeneratedSchema,}from'./schema.generated';import{GraphQLError}from'graphql';constqueryFetcher: QueryFetcher=asyncfunction({ query, variables, operationName, extensions },fetchOptions){letresponse;letdata;try{// Modify the URL "https://iam.netsnek.workers.dev/graphql" if necessaryconstresponse=awaitfetch('https://iam.netsnek.workers.dev/graphql',{method: 'POST',headers: {'Authorization': extensions?.authTokenasstring,'Content-Type': 'application/json',},body: JSON.stringify({
query,
variables,
operationName,}),
...fetchOptions,});data=awaitdefaultResponseHandler(response);}catch(error){if(errorinstanceofGQtyError&&error.graphQLErrors?.[0]){thrownewGraphQLError(error.graphQLErrors[0].message,{extensions: error.graphQLErrors[0].extensions,//path: error.graphQLErrors[0].path,});}}returndata;};constcache=newCache(undefined,/** * Default option is immediate cache expiry but retain data for 5 minutes, * allowing soft refetches in the background. */{maxAge: 0,staleWhileRevalidate: 5*60*1000,normalization: true,});exportconstclient=createClient<GeneratedSchema>({schema: generatedSchema,scalars: scalarsEnumsHash,
cache,fetchOptions: {fetcher: queryFetcher,},});// Core functionsexportconst{ resolve, subscribe, schema }=client;// Legacy functionsexportconst{
query,
mutation,
mutate,
subscription,
resolved,
refetch,
track,}=client;export*from'./schema.generated';
When a GQty error is caught, I extract the GraphQL error and rethrow it to ensure the same error appears in the Pylon playground. I omit the path because it should reflect the Pylon path, but all other error details are preserved from the original GQty error. The result is shown in the image below:
I’m looking forward to any feedback or suggestions to further refine this error handling approach @vicary@schettn.
The text was updated successfully, but these errors were encountered:
Hi everyone,
Goal: Establish sensible defaults for GQty error handling in generated client for Pylon.
In my previous issue, I provided a general outline of how GQty could function on the server side. This issue is specifically addressing error handling in a Pylon backend services using GQty:
With some assistance from the Discord community, I implemented a general error handling strategy for my web service by modifying the generated
client/index.ts
as shown below. Since I’m utilizing GQty’sresolve()
, I expect to receive only one GraphQL error per request, so I handle it usingerror.graphQLErrors[0]
:When a GQty error is caught, I extract the GraphQL error and rethrow it to ensure the same error appears in the Pylon playground. I omit the
path
because it should reflect the Pylon path, but all other error details are preserved from the original GQty error. The result is shown in the image below:I’m looking forward to any feedback or suggestions to further refine this error handling approach @vicary @schettn.
The text was updated successfully, but these errors were encountered: