Can you create a complete web application backend with Slash GraphQL?

I understand using Slash is a graphQL and server less platform, and I understand you can store data using GraphQL queries and mutations. However, the biggest question maybe, how can you build a complete app backend if we cannot store media files? Like photos and other media which just about every app needs?

Is there a solution to this with just using the Slash platform and not hosting anything on our side?

2 Likes

Slash GraphQL doesn’t currently store media files. But you can write a lambda that saves things in S3 if needed. We’re also considering adding this feature to our roadmap if there are more requests from the community.

@gja and @chewxy might be able to provide more info.

1 Like

In my opinion, Dgraph services (SaaS) is meant to target the functionalities of the DB itself. Any other type of data should be handled in their best practice. Like images, they should be in buckets or some other image services. Which are focussed to deliver the best service for it.

The DB itself can hold the links for those media. Encode it and send it to the DB isn’t a good idea. Also, I don’t remember any other service covering this like this. They would do the same as AWS would do.

But dunno, maybe Tejas or Chewxy might have other opinions or say that we support it somehow. You never know.

1 Like

Oops my bad. I thought I had replied.

But the long answer short is that I agree with @MichelDiz. However, there is a solution to be had: You can use lambda functions to actually store your media on a S3/GCS/AzureBlobStorage bucket, and the field of your type stores the path to the media file on your cloud buckets.

There are plans to somewhat integrate this functionality (either by means of a written tutorial, or having it as a product feature). But I cannot give you the timeline. That’s @gja’s jam.

EDIT: I see that’s what @zhenni had written lol.

1 Like