Use file buffer instead of writing to the filesystem to proxy multipart request to a graphql api

[timojokinen]

I have a nodejs express app that serves as a proxy between a client application and a graphql api. The graphql api implements the graphql-multipart-request-spec. I am using the graphql-request package to query it. The proxy application uses nestjs and multer for the upload.

According to graphql-request docs you can upload files like this

const UploadUserAvatar = gql`
  mutation uploadUserAvatar($userId: Int!, $file: Upload!) {
    updateUser(id: $userId, input: { avatar: $file })
  }


request('/api/graphql', UploadUserAvatar, {
  userId: 1,
  file: createReadStream('./avatar.img'),
})

But that implies that the uploaded file has been saved to the file system. Is it possible to do the same thing using the buffer of the file?

I tried to turn the buffer to a ReadableStream like this:

const readable = new Readable()
readable._read = () => {} // _read is required but you can noop it
readable.push(file.buffer)
readable.push(null)

request('/api/graphql', UploadUserAvatar, {
  userId: 1,
  file: readable,
})

But the graphql api returns the following error:

Unexpected end of multipart data

[kuksik]

I have the same question. @timojokinen did you find solution?

[timojokinen]

No, unfortunately not.
We solved this by saving the file to the disc and then making the graphql request, but it's not the optimal solution.

[Sczlog]

I am facing the same issue and I use memfs to create a in-memory file then send it, it seems work well.

[Anubiso]

Hey @Sczlog, can you provide an example with memfs?

[frangrolemund]

Bump. I was using memfs myself and found that when paired with container deployments, it is failing with larger files. Any chance an interface with a Buffer could be prioritized? Seems like a very natural use case, maybe even more likely than reading from the filesystem.

[jasonkuhrt]

#500