-
Consider this mutation for uploading file: mutation UploadAttachment($companyId: ID!, $file: Upload!) {
uploadAttachment(companyId: $companyId, file: $file) {
error
attachment {
downloadUrl
errorCode
filename
id
insertedAt
status
}
}
} When running it, the payload URQL generates, follows the pattern described here: https://github.com/jaydenseric/graphql-multipart-request-spec#curl-request. Here's an example: The problem is that my server expects a different, incompatible pattern: https://hexdocs.pm/absinthe/file-uploads.html#example. Example: Is there a way to adjust the payload structure of file upload mutation, so I can make it compliant with the server? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
You'd have to make a custom exchange that operates separately from the default/built-in fetch exchange. However, it's more advisable to open an issue over at Absinthe (unless they have an existing one) to point out that, rather than custom modules for Apollo, it may be advisable to adapt and stick to the de-facto standard |
Beta Was this translation helpful? Give feedback.
You'd have to make a custom exchange that operates separately from the default/built-in fetch exchange.
Luckily, the fetch utilities are broken up into reusable pieces, and this used to be used in the legacy/deprecated multipart exchange: https://github.com/urql-graphql/urql/tree/16b9023f805683a0565a323bf26e70ce582a8f40/exchanges/multipart-fetch
So, you might be able to adapt this to your needs.
However, it's more advisable to open an issue over at Absinthe (unless they have an existing one) to point out that, rather than custom modules for Apollo, it may be advisable to adapt and stick to the de-facto standard