File upload mutation with Abinthe giving "no query document supplied" error

Phoenix Forum Questions / Help
, ,
1

I’m trying to build an upload component to allow uploading of files over graphql. I’m using Absinthe for the server aspect and React + URQL (along with the multipart fetch exchange) for the frontend. I’ve followed the file uploads section of the Absinthe docs and I have it working via curl as follows:

curl -v -X POST -F query="mutation { uploadFile(input: {file: \"myfile\"}) { result }}" -F myfile=@avatar.png localhost:4000/graphql

However I can’t seem to get this same mutation to work when using URQL. The server just responds with a “no query document supplied” error.

Here’s an example of the multipart request from the browser:

-----------------------------283482549016739198714264561499
Content-Disposition: form-data; name="operations"

{"variables":{"input":{"file":null}},"query":"mutation UploadFile($input: UploadFileInput!) {\n  uploadFile(input: $input) {\n    result\n    __typename\n  }\n}\n"}
-----------------------------283482549016739198714264561499
Content-Disposition: form-data; name="map"

{"1":["variables.input.file"]}
-----------------------------283482549016739198714264561499
Content-Disposition: form-data; name="1"; filename="avatar.png"
Content-Type: image/png

‰PNG
 <rest of image data

Could there be a discrepency between implementations?

2

Yes, URQL is using a different pattern for file uploads. I’ve been fighting this spec forever because I hate the use of null as a marker for a value that is not null. However it seems this spec is getting popular and this is a fight I’m going to lose eventually. sigh.

3

I see. I agree with your thinking. It seems like URQL itself is pretty modular and I’m using the @urql/exchange-multipart-fetch package (which is part of the core repo) to provide this multipart functionality.

I guess it shouldn’t be too hard to make an Absinthe-specific equivilent.

It would be nice if there was agreement on a standard spec though.

4

There does seem to be a standard for this: https://github.com/jaydenseric/graphql-multipart-request-spec. Although I have no idea who has the final say on these things.

In any case, I managed to make a exchange for URQL that uses the pattern adopted by Absinthe.

5

Yes this is exactly the spec I’m talking about. To be clear, this is the proposed spec by one person. I grant that it has seen increasing adoption within the JS graphql ecosystem, but it is not an official spec by the GraphQL body.

You can read about my specific objects to that spec here: https://github.com/jaydenseric/graphql-multipart-request-spec/issues/4

6

I found this thread when googling. I didn’t want to rewrite anything on the client because that sounds pretty rough, so I went for the Elixir rewriting approach. I hooked into multipart_to_params, an option to the Plug.Parsers plug that’s usually put in Endpoint

This code works for my simple case locally. I didn’t test with multiple files because that’s not a use case for me. I also didn’t worry about graceful params handling. Use at own risk, but possibly a decent starting point:

defmodule RewriteMultipart do
  def multipart_params(parts, conn) do
    params =
      for {name, _headers, body} <- parts,
          name != nil,
          reduce: %{} do
        acc -> Plug.Conn.Query.decode_pair({name, body}, acc)
      end
​
    params = case params do
      %{"operations" => operations, "map" => map} ->
        map = Jason.decode!(map)
        operations = Jason.decode!(operations)
​
        # Transform the file map to the query variables
        vars =
          Enum.reduce(map, operations["variables"], fn mapping, vars ->
            {name, [path]} = mapping
            path = String.split(path, ".") -- ["variables"]
            put_in(vars, path, name)
          end)
​
        # New query drops operations/map in favor of query/variables
        params
        |> Map.drop(["operations", "map"])
        |> Map.merge(%{"variables" => vars, "query" => operations["query"]})
​
      _ ->
        params
    end
​
    {:ok, params, conn}
  end
end
1 Like