`map` field in context of backward compatibility

[o-rumiantsev]

Hi, I am upgrading old GraphQL dependencies on my project. For file uploads apollo-upload-server@2.0.3 is used (I understand that now there is version 11 :)). We have a lot of users using mobile client, so we have no ability to update all our clients. How should I deal with map property which is required now, but is not sent from most of the clients?

I am using: Fastify - as a web framework Mercurius - as fastify gql plugin MercuriusUpload - as gql upload plugin

[jaydenseric]

It's a tricky situation; I've answered over here:

https://github.com/jaydenseric/graphql-upload/issues/227#issuecomment-742211820

[mike-marcacci]

It looks like version 3 of graphql-upload (apollo-upload-server) introduced v2 of the spec, which means that you will have to deal with a field name change and a change in field ordering. From the perspective of the spec, this is a breaking change. It was released only a couple months after the first version was published, so I suspect that a migration path was not an important criteria (and honestly this is the first case of this that I've seen in the many years I've been following this).

The only real solution here without updating the clients is to add a layer that detects and translates the spec v1 request into a v2 spec request. You mentioned you're using the JS libraries so this should be quite practical to do, but certainly isn't trivial:

1. detect a multipart GraphQL request
2. take ownership of the request stream without yet calling graphql-upload
3. create a new stream in place of the real request stream
4. begin consuming the request stream, buffering its contents into memory
5. if you detect that the first part is named operations you know you have a v2 spec request:
   1. replay the contents from your buffer into your replacement stream
   2. pipe the rest of the request stream into your replacement stream
   3. allow graphql-upload to proceed as normal
6. if you detect that the first part is named files you know you have a v1 spec request:
   1. buffer the entire files part into a new memory buffer
   2. once you detect the second part (which should be named operations) send any contents from the initial buffer and begin streaming the contents of the operations part to your replacement stream
   3. once the end of the operations part is reached, immediately replay the contents of the files buffer into the replacement stream
   4. pipe the remainder of the request into your replacement stream
   5. allow graphql-upload to proceed as normal

Again, this is non-trivial and probably represents a solid couple days of work, but is certainly doable if the scale of your operation demands it. This is obviously out of scope for the project at this point, but best of luck!