Tag: Sending

Sending Large Files

I’ve got a podcast that will be 10 years old this coming January! Most of those episodes have one or more guests (plus me and Dave). Despite fancy modern options for recording podcasts with guests, like Riverside.fm or Zencastrl where guests don’t have to worry about recording their own audio, we haven’t made the leap to one of those yet.

We have the guests record their own audio locally (typically Quicktime Player or Windows Voice Recorder) because that way our editor can make the most of the editing process. At the end of the show, our guest has a file that is ~100MB that they need to send over to us.

How that handoff happens isn’t always completely obvious. Typically we don’t share a Slack with our guests, but when we do, that works for sharing large files like that. Even a Nitro-boosted Discord won’t take a file that big, though. I’d say 70% of the time, our guests chuck the file into their Dropbox and create a sharing link for us to download it. From there, it’s probably Google Drive 20% of the time, and the last 10% is some random thing.

That last 10% is stuff like uploading the file to a web server or file storage service the guest controls and they link us up to the file from there. If we were smarter, we’d probably use “File Request” links on Dropbox or Box.

I usually say something like, Send us that file however you like to send large files, because I don’t want to be too prescriptive about what service someone uses. You never know if someone has a particular aversion to some specific tech or company. I would always mention Firefox Send because it was meant for one-off file sending and I find people generally like and trust Mozilla. Alas, Firefox Send shut down.

Unfortunately, some abusive users were beginning to use Firefox Send to ship malware and conduct phishing attacks. When this problem was reported, we stopped the service. Please see the Mozilla Blog for more details on why this service was discontinued.

I guess it’s responsible to try to shut down bad behavior, but of course it was used for bad behavior. Dickwads use any and every service on the entire internet for bad behavior. The real answer, probably, is that it was just a little random side project that didn’t make any money and they didn’t feel like investing the time and money into fixing it. Fair enough, but of course that always costs you trust points. What else is on the chopping block?

I ran across Wormhole the other day which looks like a direct, if not better, replacement. It uses end-to-end encrypted and has some nice UX touches, like getting a share link before the upload is complete. It doesn’t say anything about how they intend to pay for it and support it long-term, but I’d guess the cost is somewhat minimal as they only host the files for 24 hours. They also don’t say if they intend to prevent bad behavior or if it’s just a free-for-all. Even with all the encryption and whatnot, I would imagine if a site like Google or Twitter found that tons of wormhole.app URLs had malware on them, they’d be blacklisted. That wouldn’t stop people from using it but it certainly stops people from finding it too. I did hear from Feross on this, and they have ideas to fight bad behavior if it comes to that.

The thing I’m the most surprised by is that we don’t get more emails where the email service itself just hosts the file. That might sound silly, as email is notorious for not accepting very large file attachments, but that has changed over the years with some of the big players. When you select a file that’s larger than 25MB in Gmail, it’ll offer to upload it to Google Drive and automatically share it with the person you’re sending the email to. iCloud does largely the same thing with Mail Drop.

Me, I use Dropbox quite a bit, but rarely for sharing one-off files. If I want to make sure I have a copy in perpetuity, sometimes I’ll even use a personal Amazon S3 bucket. But mostly I’ll just upload it to Droplr, which I’ve used for ages just for this kind of thing.


The post Sending Large Files appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,

Netlify Functions for Sending Emails

Let’s say you’re rocking a JAMstack-style site (no server-side languages in use), but you want to do something rather dynamic like send an email. Not a problem! That’s the whole point of JAMstack. It’s not just static hosting. It’s that plus doing anything else you wanna do through JavaScript and APIs.

Here’s the setup: You need a service to help you send the email. Let’s just pick Sparkpost out of a hat. There are a number of them, and I’ll leave comparing their features and pricing to you, as we’re doing something extremely basic and low-volume here. To send an email with Sparkpost, you hit their API with your API key, provide information about the email you want to send, and Sparkpost sends it.

So, you’ll need to run a little server-side code to protect your API key during the API request. Where can you run that code? A Lambda is perfect for that (aka a serverless function or cloud function). There are lots of services to help you run these, but none are easier than Netlify, where you might be hosting your site anyway.

Get Sparkpost ready

I signed up for Sparkpost and made sure my account was all set up and verified. The dashboard there will give you an API key:

Toss that API Key into Netlify

Part of protecting our API key is making sure it’s only used in server-side code, but also that we keep it out of our Git repository. Netlify has environment variables that expose it to functions as needed, so we’ll plop it there:

Let’s spin up Netlify Dev, as that’ll make this easy to work with

Netlify Dev is a magical little tool that does stuff like run our static site generator for us. For the site I’m working on, I use Eleventy and Netlify Dev auto-detects and auto-runs it, which is super neat. But more importantly, for us, it gives us a local URL that runs our functions for testing.

Once it’s all installed, running it should look like this:

In the terminal screenshot above, it shows the website itself being spun up at localhost:8080, but it also says:

◈ Lambda server is listening on 59629

That’ll be very useful in a moment when we’re writing and testing our new function — which, by the way, we can scaffold out if we’d like. For example:

netlify functions:create --name hello-world

From there, it will ask some questions and then make a function. Pretty useful to get started quickly. We’ll cover writing that function in a moment, but first, let’s use this…

Sparkpost has their own Node lib

Sparkpost has an API, of course, for sending these emails. We could look at those docs and learn how to hit their URL endpoints with the correct data.

But things get even easier with their Node.js bindings. Let’s get this set up by creating all the folders and files we’ll need:

/project    ... your entire website or whatever ...    /functions/       /send-email/          package.json          send-email.js

All we need the package.json</code file for is to yank in the Sparkpost library, so <code>npm install sparkpost --save-dev will do the trick there.

Then the send-email.js imports that lib and uses it:

const SparkPost = require('sparkpost'); const client = new SparkPost(process.env.SPARKPOST);  exports.handler = function(event, context, callback) {   client.transmissions     .send({       content: {         from: 'chris@css-tricks.com',         subject: 'Hello, World!',         html:           "<html><body><p>My cool email.</p></body></html>"       },     recipients: [{ address: 'chriscoyier@gmail.com' }]   }); }

You’ll want to look at their docs for error handling and whatnot. Again, we’ve just chosen Sparkpost out of a hat here. Any email sending service will have an API and helper code for popular languages.

Notice line 2! That’s where we need the API key, and we don’t need to hard-code it because Netlify Dev is so darn fancy that it will connect to Netlify and let us use the environment variable from there.

Test the function

When Netlify Dev is running, our Lamba functions have that special port they are running. We’ll be able to have a URL like this to run the function:

http://localhost:34567/.netlify/functions/send-email

This function is set up to run when it’s hit, so we could simply visit that in a browser to run it.

Testing

Maybe you’ll POST to this URL. Maybe you’ll send the body of the email. Maybe you’ll send the recipient’s email address. It would be nice to have a testing environment for all of this.

Well, we can console.log() stuff and see it in the terminal, so that’s always handy. Plus we can write our functions to return whatever, and we could look at those responses in some kind of API testing tool, like Postman or Insomnia.

It works!

I’ll leave it to you to get fancy with it 😉

The post Netlify Functions for Sending Emails appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]