You can find code example for this chapter here.
In this chapter we'll look into a different kind of API: GraphQL. It focuses on reducing the number of roundtrips between the frontend and the backend and as such it can provide a very fast experience especially when the connection is not ideal.
GraphQL is not the main focus of this book and we won't get into the details of how it works. If you are interested in running serverless GraphQL apps in the AWS cloud, you can learn everything about it from my other book: https://www.graphql-on-aws-appsync-book.com/.
In this chapter, we'll focus on the implementation of the photo-sharing app based on AppSync, AWS's managed GraphQL solution. We won't go into detail of how AppSync is configured or how it works on a lower level, but this chapter should give ideas how signed URLs are useful in other contexts.
AppSync is a serverless API. On the upside that means you don't need to worry about scaling and a solution is expected to work the same when it gets almost no requests as when it's running in production. On the downside, serverless also means some limits on request/response sizes and times. And that means it does not play well with files.
Of course, nothing prevents an implementation to encode a field as base64 for downloads or an argument encoded similarly for uploads. But that puts an implicit upper limit on the sizes: at some point AppSync will throw an error when data in either direction gets too large. When this happens is a bit blurry, but it definitely won't work for a site that serves videos, for example. The solution is, of course, signed URLs.
In this chapter, we'll implement the file handling part of a photo-sharing application where users can upload images into their collection and browse other users' uploaded files. Moreover, they can define whether their photos are public or private, in the latter case other users won't see them.