AWS Bites Podcast

47. Preview: How to build a File Transfer application - live!

In this special episode, we announce our next initiative: starting some YouTube coding live streams where we build something on AWS. Specifically, we are going to build a file transfer service, just like WeTransfer or Dropbox Transfer! In this episode, we announce why we decided to start this, the logistics, and some of the details of the product we are going to build. We are really looking forward to pairing with you all live on this build! Make sure you are subscribed to our YouTube channel so you are notified when we go live on Wednesday 17 August!

In this episode, we mentioned the following resources:

Let's talk!

Do you agree with our opinions? Do you have interesting AWS questions you'd like us to chat about? Leave a comment on YouTube or connect with us on:

Luciano
00:01:39

Sure, so just to put things into context, we are not going to try to build like a fully fledged Dropbox with file syncing and stuff like that. We're going to keep it a little bit more minimalistic, but still we want to build something that is going to be useful for people and you can use it in different contexts. So the idea is that it's kind of a very simple file sharing product. So you just want to upload one file and then have a URL that you can share with other people for them to download that particular file. And if you are thinking of different kind of examples or use cases, for instance, when we record these episodes, we always need to share video file and audio files between ourselves before we do the final production. So imagine that we will be using a service like this to just upload this video and audio file somewhere, and then we have an easy link that we can easily share between ourselves. Similarly, you might be thinking, okay, I need to send a bunch of receipts to my accountant. I have this big zip file, but it's too big to send it in an email. What do I do? My accountant probably doesn't have Dropbox, so let's send them a URL. Similarly, and this is actually a very common use case I had many, many times, and you probably can relate to that. You have multiple devices and you just want to transfer a big file between them. Every time it's like, how do I do that? If you have a service like this, you can easily just upload on one side and download from the URL on the other side. And at this point, why not to use Dropbox? Well, there might be many reasons. Maybe you just don't want to pay for Dropbox, or maybe you want to be in control of your own data and prefer to avoid third-party services and have something where you really understand what's going on, how the data is actually being processed and used. Or maybe this is actually a realistic use case I've seen in many offices that the network is actually blocking services like WeTransfer or Dropbox. In that case, you literally cannot use those services. One final reason that we can find is maybe you just want to use your own custom URL either for vanity or because you're actually building a business and it might make sense to have a little bit more trust by giving URLs that represent your company or your product. So I suppose, yeah, just to finish off, we are building this product mostly for ourselves to have fun, but in reality, a feature like this, it's something that could be integrated in every other product. Imagine you are building, I don't know, a chat application and you need people to be able to exchange files in a chat session, or you have just a file management system integrated in a CMS or other kinds of products. So it is actually a very, very common use case to having to deal with uploads and downloads in all sorts of SaaS products. So I think by doing this exercise, we're going to, well, first of all, learn ourself how to do this, but hopefully also teach and share with other people this learning so that you can go off and build the same functionality in other applications. So do you want to describe, Eoin, what's the plan?

Eoin
00:04:27

The starting point, I think what we can do as the MVP for our file sharing would be, imagine that you call it an API that we deploy onto AWS and it gives you an upload URL and a download URL. So you upload the file with your upload URL, and then you share the download URL with your friend or with your other device. And that's enough, right? For our MVP, that should work. It might be a little bit rough around the edges in terms of user experience, but fundamentally it achieves the goal. So for that, we could use things like S3, of course, maybe signed URLs integrated with API gateway, a bit of Lambda, a sprinkling of IAM and put it all together with Node.js Lambda functions, serverless framework. And since it's an MVP, you can just use curl to do the uploading and downloading. But that's the first MVP. And I think that would be the core of it from that point. Okay, you mentioned vanity URLs. So maybe the next thing would be to register a domain name, integrate it so that we have much nicer links that are branded and we could use Route 53 and certificate manager to help us achieve that. Maybe we have to pick a name for this product. So maybe people can let us know over the next couple of weeks, what funky name we could use for our WeTransfer clone. We can get the domain registered in time for the first episode. Beyond that, I guess we could start building a bit of a front end, right? Maybe not a React front end. How about a command line interface, something like an NPM CLI? What do you think?

00:06:22

But the very minimum is that you just easily are able to upload a file by just giving a path to the CLI. And we'll probably gonna do all of that with Node.js again, because it's the easiest for us. So yeah, it's probably gonna be like a package that you can just NPM install global and then you can use it from any bash terminal. After that, I think that there is a lot of room for different kinds of improvements. We can probably also listen to feedback and try to understand what are things that people are mostly interested in. But the ideas that we came up with are, for instance, showing how we could build a deployment pipeline. We also talk a lot about using GitHub Actions and OIDC providers. So that can be another excuse to showcase how we could actually deploy this product from a GitHub Action using the OIDC integration that we have been talking about. We could also think about securing this entire API, because up to this point, we haven't mentioned any level of security. As long as you know the host, you can just upload and download. But we might want to limit that. Maybe we can... The easiest thing we could do is just use API keys in API Gateway, but we might end up exploring other options as well. Maybe Cognito or something a little bit more sophisticated. And then another topic that we were thinking about is probably you don't want these files to live in a mystery packet forever. Most likely, if you are using this kind of service, you are transferring big files, you probably don't load them only once and then not using them again. So it probably makes sense to make this file somehow disposable. Maybe make sure they get deleted automatically after a week, a day, or whatever is the deadline that makes sense for the kind of application. We might discuss a little bit about quota, limits, pricing, and things like that. So definitely let us know if you already have specific topics in mind that you would like us to actually explore in a kind of live coding fashion, because that is going to drive us in selecting what can we do next after this. Yep. That's it. That sounds good.

Help us to make this transcription better! If you find an error, please submit a PR with your corrections.