Override file upload payload

[zorzysty]

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?

[kitten]

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

[zorzysty]

Absinthe guys are aware of the problem, but it seems they decided to fight the spec instead of adhering to it: jaydenseric/graphql-multipart-request-spec#4. It does not look like they're going to change the direction anytime soon.

So custom exchange is the only way to go. I'll try to figure it out.

[kitten]

Gotcha! Thanks for the links, that's very helpful for future reference! for what it's worth, I also do not like the spec’s quirks and the way in which it was implemented.

For what it's worth, if this only came down to striking the null value out of the spec, initially when we pulled this spec into @urql/core and replaced extract-files (which the legacy exchange used) the null part is something we overlooked, as we assumed the value should just be struck out and the file mapping would be used to patch the variables object anyway, which is not the case: #3169

On a side note, we pinned that legacy exchange to an old version of extract-files as well at the time, since its setup isn't compatible with all bundlers — I won't go into details on that 😅 But that's one problem with it.

It doesn't make sense to provide a file mapping and at the same time not treat it as a simple patch instruction that's preprocessed.

But, unless a spec is introduced into GraphQL over HTTP diverging from it meant that it'd cause an XKCD 927 situation.
We can only support one spec at a time, as a client, and while an API implementation has more freedom in that regard, we also weren't interested in pushing an alternative spec as providing separate upload URLs is more beneficial in a lot of cases.

Anyway, hope the extra details here help someone in the future ✌️