Continuing the discussion from: Can we have @remote scalars?
When building applications that use databases, often binary data has to be stored somewhere. This is often done by storing the location of the binary-blob in the database and the blob itself somewhere else on the backend. Usually this requires custom business logic for storing and retrieving this data.
File-Uploads and Downloads with GraphQL are often implemented using the GraphQL Multipart Request Spec
Dgraph GraphQL is currently missing this Multipart-Scalar and it is therefore impossible to use a
@custom mutation that relays the upload request to the custom graphql business logic. Currently the client has to:
- upload the file to
- store the file ID to the database
Similar, the client has to take these two steps to retrieve the binary files from the backend.
Using two different URLs for database access and binary data upload/download is cumbersome and error-prone. It would be great if dgraph-graphql would support the upload-scalar using multipart spec referenced above.
Thinking this one step further
When the upload-scalar is implemented, the next step would be to add native support for binary uploads/downloads. binary data could be either stored on disk or on a 3rd party s3 solution like minio (which is already used by dgraph for backups so I guess it could be integrated without much effort).
This would be super convenient for clients as dgraph would take care of all the nasty stuff that comes with CRUD operations (data-storing, -fetching, -deleting, … ) and I think it would give dgraph-graphql even more of an edge over competitors
Looking forward to discuss this!