Thanks, I see.
On reading those docs I found that the GraphQL server is also handling multipart requests, but at present Dgraph only handles the standard
application/graphql content types which come in as one single HTTP request and not as an HTTP request spread over multiple parts.
And, then the GraphQL multipart request specification that you shared has also defined a standard way of sending those request, and that is what enables them to be able to stream the file contents while the server is resolving it at the same time. This is very interesting.
In general, I don’t see any problems supporting
@remote scalars, as long as they can be represented in JSON. Because, JSON is what is the standard way of transporting GraphQL, and that is what we support.
But, for this use-case, it requires supporting multipart requests, which is not the standard GraphQL way, and that is the reason we didn’t support it yet. And, then the moment you lose a pre-defined structure (which JSON provides), there can be innumerous ways to represent something, and the server may not know in advance how to parse it. Like, this particular scalar expects file to be a stream and the GraphQL server which doesn’t already know about this scalar, won’t be able to handle it. So, I don’t see it working as a remote scalar.
Instead, a better ask would be to have Dgraph support the GraphQL multipart request specification, which in turn would make it support the
Upload scalar as well. Let me discuss it internally, and update you if this is something we would be able to work on in the near future.
EDIT: Linking a previous discussion about file uploads: Upload file mutation