So the need is to allow files to be a payload from the grapghql server. The current setup is the server is running express which is responsible for auth and grapghql.
The team in charge is wanting to avoid modifying express to allow rest endpoints and lock it down to just the graphql server.
So since we donโt have an easy option to add a rest endpoint to serve the files (large PDFs), I feel as though grapghql should have a way to serve files via the web sockets.
Can anyone give me direction in this?
Top comments (12)
Don't know much about graphQL if you can send the bytes through the socket, then you can reconstruct ithe file in the front end. with something like this:
This was my original thought and hope. We decided not to force gql into something it's not meant to do.
Generally, GraphQL endpoints don't deal with binary data. As a matter of fact I've been in charge in my team on providing upload and download of files from our GraphQL endpoint. In the end, I've settled on a /download express endpoint. If you insist on using the GraphQL layer, you can encoder the files in base64 and send the encoded strings.
We are also going to just go with our original plan and add a new restful service which shares the auth service. Base64 would have been fine had we not needed to deal with large files.
I was able to setup a mutation handling files up to 10Mb through "graphql-server-upload" on GitHub. If you want some help, feel free to hit me up and we'll initiate a conversation.
also, how was it for you? Easy to setup for the upload?
As far as speed, I didn't experience anything less than "normal". Downloads speed were good and overall download/upload experience of the End User was good.
For the setup, I really struggled at first, but that was because I had a custom apollo-server backend that needed retrofit. After the setup on that side was done, adding mutations and processing files is really easy.
So we can do this too, the issue is download. We just can't get it to deliver raw files and base64 didn't feel like a proper solution due to the size of the files.
Is external storage an option? For example, sending over an S3 URL via the server and then retrieving the file from there?
It could be a option and one that we discussed. The concern is if for what ever reason someone were to gain access to that url, they could gain access to protected information. We prefer it be locked down
That's fair! With S3 (and likely other solutions) you can generate expiring URLs which might solve for part of that problem, and set up access control to restrict things to requests from your application, but that might end up being more work up front than keeping everything in-house.
We deal with PHI, so we can not have a unsecured link, even if it expired right away. So unfortunately this was not a working solutions for us. But it is a good solution for other cases. Thank you for the suggestion. We are going to end up creating a new restful service to deliver the files behind the auth.