DEV Community: Dan

Flexible Upsert With DynamoDB

Dan — Wed, 14 Oct 2020 09:28:31 +0000

I recently made a switch from Postgres to Dynamodb and have been learning some pretty basic stuff. I’m working with a single table with a single kind of item so none of the tough NoSQL relational paradigm stuff, just some basic putting and updating. In using DynamoDB's built-in update function, I came across what I imagine is a pretty ordinary case that was not covered in documentation: how to update records allowing any possible combination of properties.

Update Expressions from the Amazon DynamoDB docs, for reference

The Case

Here’s the case:

I have an item that I want to insert into my table, that has an arbitrary amount of properties;
I expect it will be updated, adding to those initial properties another, different set of arbitrary properties.

In other words: I’ll create an item with x and y properties, and later on will update it with property z.

I read that the default behavior for DynamoDB’s update is like Postgres’ UPSERT, ie it will create the record in the database if it cannot find it by its primary key. So it sounded like I could do my insert and update logic in the same function, which would be great.

By its nature, DynamoDB (and NoSQL databases in general, as far as I understand) have the flexibility to create records with any properties. That’s why it was surprising to me that the problem I kept running into was specifically of that nature: DynamoDB would not let me update a record with a property it didn’t already have if I didn’t supply all its other already-existing properties.

In the most simplified example, this is what was happening:

I create an item with x and y properties;
I then update that item with z property;
The update fails because I did not supply x and yproperties. The error message was: "ExpressionAttributeValues cannot be NULL" (if you're new to DynamoDB I cover ExpressionAttributeValues below).

Here’s a good Stack Overflow post with a similar problem.

Coding the Problem

In my project, I’m building a database of video games. I want to save some info about each one: title, developer, publisher, releaseDate, and a lot more. But let’s start simple, with just one attribute.

In the example below, let’s imagine we have a table where the primary key (Key below) is the title, and we already have a record in the database that exists with that Key. This is how we would update a single attribute, developer.


const data = {title: 'Uncharted', developer: 'Naughty Dog'}
const params = {
  TableName: process.env.DYNAMODB_TABLE,
  Key: { title: data.title },
  UpdateExpression: 'SET developer =  :dev',
  ExpressionAttributeValues: {
   ':dev': data.developer
    }
  };
  await dynamodb.update(params).promise()
}

So this works, but with this approach, we’ve totally hamstrung the flexibility of DynamoDB. We are expecting a specific bit of data to be sent in with the request, data.developer.

What happens if we want to add any other properties to this request? Well, if we don’t change the code at all and send a request with, say, a publisher property in the data with our developer and title, it simply won’t get written to the record. To accommodate new data to add, we'd have to change the UpdateExpression and the ExpressionAttributeValues like this:


const data = {title: 'Uncharted', developer: 'Naughty Dog', publisher: 'Sony'}
const params = {
  TableName: process.env.DYNAMODB_TABLE,
  Key: { title: data.title },
  UpdateExpression: 'SET developer =  :dev', publisher = :pub,
  ExpressionAttributeValues: {
    ':dev': data.developer,
    ':pub': data.publisher
    }
  };
  await dynamodb.update(params).promise()
}

Again, this works, but if you ever update your object without every single attribute, the request will fail with the ExpressionAttributeValues cannot be NULL error. You're not allowed to update just the developer, or just the publisher with this approach.

This completely goes against what I’d read and learned about as one of the main selling points of NoSQL: flexibility.

How We Fix It

So looking at the Stack Overflow article I posted above gave me a few ideas that got me to a solution I feel good about.

If you look at the structure of the params that you actually supply to the dynamodb.update() function, it’s just a simple object with UpperCamelCased keys. So rather than hardcode the attributes we want to update, we can dynamically build our update function based on whatever attributes have been provided.

So the key things we need to build are the UpdateExpression and the ExpressionAttributeValues.

Programming UpdateExpression

UpdateExpression uses an SQL-like syntax to SET, ADD (increment), or REMOVE certain attributes on the item you’re updating. If you want to SET multiple attributes in a single expression it will look like what we did above:

SET latestUpdate = :updateTime, developer = :developer, publisher = :publisher

Those colon-prefixed keys like :updateTime will be found in the ExpressionAttributeValues. They're arbitrary placeholders, so name them anything you want as long as they match a value in the ExpressionAttributeValues. You can think of it as the value substitution (aka "Parameterized Queries") you find in SQL.

You can probably see how we go about solving this then:

we take all the keys found in data object we're updating,
map them to properties we want to update,
create a colon-prepended key for them, then
add those values to the ExpressionAttributeValues list.

The final result looks like this:

const data = {title: 'Uncharted', developer: 'Naughty Dog', publisher: 'Sony'}

const params = {
  TableName: process.env.DYNAMODB_TABLE,
  Key: { title: data.title },
};
params.UpdateExpression = "SET latestUpdate = :updateTime"
params.ExpressionAttributeValues = {}
for (let k in data) {
  if (k !== 'title') {
    params.UpdateExpression += `, ${k} = :${k}`
    params.ExpressionAttributeValues[`:${k}`] = data[k]
  }
}
params.ExpressionAttributeValues[':updateTime'] = Date.now()

await dynamodb.update(params).promise()

You’ll notice a few things about the above code:

we start our UpdateExpression with SET latestUpdate = :updateTime; the purpose of that is so we don’t need to deal with the edge case of the first item in our iteration through the keys. With that starting off our expression, we can simply concatenate the string with all the keys, starting with a colon to separate each value. Makes life easier, plus it's good practice to save that information. Two birds, one stone.
We have to set the initial value of ExpressionAttributeValues to an empty object {}, so we can write the keys and values to it.
In our for loop, there’s an if statement because we want to get every attribute except title, which is the Key to our table. Even if it hasn’t changed, we can’t put that in the UpdateExpression or DynamoDB will error. You're not allowed to put the Key in the UpdateExpression.

Now we should see no errors when we send two separate requests to the same endpoint, the first which will create the game, the second which will update it with a new attribute.

Personal Takeaway

I’m new to DynamoDB so I’m not sure if it’s crazy or clever that this was the way to achieve this type of behavior in the update function. I have my complaints about the default implementation of the update function, but at the same time it wasn't a huge leap of imagination to get the desired behavior, so perhaps in a sense this is as flexible as marketed.

In only a few days of playing with it, I'm starting to see the patterns one can utilize to fill in the gaps where desired built-ins might be missing. Let me know if this was helpful for you or if you've faced any similar blockers with DynamoDB!

Connecting AWS Lambda To A Postgres DB: Part 2

Dan — Wed, 07 Oct 2020 07:37:17 +0000

In the previous post, we got our Serverless function running locally, but hadn't set up our production database. This post deals with setting up an AWS RDS instance, configuring the security group to allow access, configuring the serverless.yaml file to hold different values for dev and prod environments, and setting up a Postgres Lambda Layer. It's a lot to cover, so let's get cracking!

Setting up AWS resources

Because this is going to be an AWS Lambda, we’re going to set up some AWS resources. Although we’re only going to manually set up an AWS RDS instance – aka our production database – this section will also touch upon, VPCs, subnets, and security groups.

Create an AWS RDS instance

Here I’m going to defer to Amazon’s instructions on how to purchase and set up an RDS instance. Follow their instructions up to the point where they begin discussing security groups. Very important: when creating the database, do not forget open the “Additional Configuration” section and enter a database name! If you don’t give it a name the database will not be created.

Also important: when you create a password for the database, do not forget it! Write it down somewhere. All the other information we’ll need soon can be read straight from the console if we ever forget it, but the database password is not so easily retrievable.

Configuring security group rules

If you don’t do anything to the Security Group rules in the AWS Console, you’ll end up with a Connection Timeout every time you try to connect to your database.

In order to change the Security Group rules, simply click the link under VPC security groups, which will take you to the page where you can configure it.

From that page, scroll down to find the ‘Edit Inbound Rules’ section and change the rules to look like the ones in the screenshot below:
Two rules with

Type: PostgreSQL
Protocol: TCP
Port range: 5432

One of those rules with source 0.0.0.0/0 and the other with ::/0.

Save the rules and go back to your RDS. Keep the window with our RDS instance open because we’re going to use some of the info shortly.

Configuring our production settings in our application

So we have two main places that read information about our database: config/config.json, which sequelize-cli references for where to make migrations, and connection.js which our application uses to make connections to the database. We’re going to need to make sure the information in these places is now up to date with our newly created production db credentials.

Update config.json

Go into config/config.json and under production add the dbname, username, password, and host (the endpoint url) for our production database. Because this now has some sensitive information, it would be smart to add this file to our .gitignore, so go ahead and do that.

Update connection.js with environment variables

Next, we want to change the information we hardcoded into connection.js. Instead of just replacing it with the production database information, we’re going to configure our serverless function to be able to mock different environments depending on what we want to test.

So before we edit connection.js, first head over to serverless.yml and add the following, replacing the values with the values from your production and development databases:

custom:
  env:
    prod: 
      stage: production
      db_dialect: "postgres"
      db_name: sls-starter-production
      db_username: root
      db_password: "123456"
      db_host: rds-endpoint.c2j1xg2t94lm.us-east-1.rds.amazonaws.com
      db_port: "5432"
    dev: 
      stage: development
      db_dialect: "postgres"
      db_name: sls-starter
      db_username: dengel
      db_password: null
      db_host: 127.0.0.1
      db_port: "5432"

This is going to allow us to run serverless offline without having to alter code based on which environment we need. In the yaml above, custom is part of the configuration that’s reserved for items we want to add that aren’t necessarily included in the options provided by Serverless Framework. Under that we’ve nested env, and under that the two environments we intend to use: prod and dev. We’ll see how these values are accessible now.

Under the provider section of the yaml, paste the following:

provider:
    stage: ${opt:stage, 'dev'}
    environment:
    DB_DIALECT: ${self:custom.env.${self:provider.stage}.db_dialect}
    DB_NAME: ${self:custom.env.${self:provider.stage}.db_name}
    DB_USERNAME: ${self:custom.env.${self:provider.stage}.db_username}
    DB_PASSWORD: ${self:custom.env.${self:provider.stage}.db_password}
    DB_HOST: ${self:custom.env.${self:provider.stage}.db_host}
    DB_PORT: ${self:custom.env.${self:provider.stage}.db_port}
    NODE_ENV: ${self:custom.env.${self:provider.stage}.stage}

Let me break this down.

Let’s look at the first key, stage. The opt:stage that it is trying to read is from a flag we can pass to Serverless when we invoke it from the Command Line, we’ll do something like sls offline -s dev, which tells it to run in the development environment. We also could pass prod. The second part of the value here, after the comma, just tells Serverless that if no -s flag is provided when we invoke serverless, to default to dev.

So now we know that opt: captures values passed in when we invoke Serverless.

The values under environment will set values accessible through process.env, so we’ll be able to access them in our code. Let’s take a look at why they’re formatted the way they are.

They’re formatted like this DB_DIALECT: ${self:custom.env.${self:provider.stage}.db_dialect}. self:custom refers to the custom key we defined above in our serverless.yaml, and then we simply use dot-notation to access to values inside of that. Furthermore, we’re nesting ${self:provider.stage} to see if it should access the values under custom.env.dev or custom.env.prod. Again, if no flag is passed when we invoke any serverless command from the Command Line, it will default to the values under custom.env.dev.

Now that we have this dynamic environment setting, we can remove the hard-coded configuration in our connection.js and replace it with something more standard:

const { Sequelize } = require('sequelize');
const pg = require('pg')


const sequelize = new Sequelize(process.env.DB_NAME, process.env.DB_USERNAME, process.env.DB_PASSWORD, {
  dialect: 'postgres',
  dialectModule: pg,
  host: process.env.DB_HOST
})

module.exports = sequelize

Let’s test this to see if it’s working. Replace the msg variable in our main function in handler.js with process.env.DB_HOST like this:

/*...*/
app.get('/test', async function (req, res) {
  let msg;
  try {
      // comment this part out
    // await db.authenticate();

      // add this
    msg = process.env.DB_HOST
  } 
/*...*/

And then try running the function offline in dev mode

sls offline -s dev

And you should see your local server address when you visit http://localhost:3000/dev/test.

Then try it in prod mode:

sls offline -s prod

Visit http://localhost:3000/prod/test (don’t forget that when you test your endpoints it will add the stage before the endpoint), and you should see your production database host.

If you’re still getting connection timeouts, make sure your credentials are correct and that the Security Group is set up to receive inbound traffic as described in the earlier step.

Configuring VPC details

We have a few final things to configure before we deploy our Lambda. First, we want to tell the Lambda which security groups, subnets, and region to be associated with. These can be found on the page for the RDS database we set up. Simply grab any of the two subnets in the list and copy- paste their identifiers. Same with the security group. We’ll also add these values under the provider section:

provider:
 vpc: 
    securityGroupIds: 
      - sg-8888888
    subnetIds:
      - subnet-222222
      - subnet-1111111
  region: us-east-1

These are necessary for when we finally deploy it, but you wouldn’t know it now because it looks like our function is working! That’s a little misleading! It’s one of the takeaways I’ve gotten from this process: you might have what looks like a perfectly working serverless function, but it will error in production. Anyways, don’t worry about that just yet, we’ll be able to mitigate most of the problems before deployment, so don’t be discouraged if one pops up.

Moving on, we have one last thing to do, which is set up our Postgres Lambda Layer, which will allow our Lambda to speak to our production database.

Setting up a Lambda layer

There’s a lot of different tutorials out there on how to create a Lambda layer. I’ve tried several and this was by far the quickest and simplest approach for me, so it comes with my recommendation.

First, create a folder in the root of your project called layer.

If you’ve ever worked with Postgres before, you will have installed the native binaries, specifically one called libpq. To find out for sure, use the following command:

find / -name libpq

If you’ve installed Postgres before, you should see some file paths returned from this command (if you can’t find it, you can download the file from the layer folder in this Github repo which also has all the configuration boilerplate you need to get this up and running). If you do see it, cd into one of those and copy the libpq file (it might be called libpq.so or libpq.so.5) into the layer folder in your project that you just created.

Your folder structure should now look like this:

Next you’ll add some more configuration to your serverless.yml which will instruct Serverless to upload the layer to AWS, and have your Lambda utilize the layer. By doing this little configuration, Serverless takes care of most of the AWS configuration for you.

So let’s add two new details to the serverless.yml (full final config can be found a little lower, if you're not certain about any details):

1) At the top level of the yaml, add the following. Note that path: layer refers to the folder our Postgres binary is located. We’ve named it pg here but we could name it anything:

layers:
  pg:
    path: layer

2) In the section of the yml that describes the app, under function add :

functions:
  app:
    handler: handler.index
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'
    layers:
      - {Ref: PgLambdaLayer}

We describe that the function in app make use of the layer which gets named PgLambdaLayer, based on what we called our layer in the previous step. If we named it postgres instead of pg we would have to instead write {Ref: PostgresLambdaLayer}.

serverless.yml in its entirety

Now that we’ve added all this configuration, let’s look at what our whole serverless.yml file should look like:

service: sls-new-project
custom:
  env:
    prod: 
      stage: production
      db_dialect: "postgres"
      db_name: sls-starter-production
      db_username: root
      db_password: "123456"
      db_host: rds-endpoint.c2j1xg2t94lm.us-east-1.rds.amazonaws.com
      db_port: "5432"
    dev: 
      stage: development
      db_dialect: "postgres"
      db_name: sls-starter
      db_username: dengel
      db_password: null
      db_host: 127.0.0.1
      db_port: "5432"
layers:
  pg:
    path: layer
provider:
  name: aws
  runtime: nodejs12.x
  vpc: 
    securityGroupIds: 
      - sg-8888888
    subnetIds:
      - subnet-88888899
      - subnet-22222222
  region: us-east-1
  stage: ${opt:stage, 'dev'}
  environment:
    DB_DIALECT: ${self:custom.env.${self:provider.stage}.db_dialect}
    DB_NAME: ${self:custom.env.${self:provider.stage}.db_name}
    DB_USERNAME: ${self:custom.env.${self:provider.stage}.db_username}
    DB_PASSWORD: ${self:custom.env.${self:provider.stage}.db_password}
    DB_HOST: ${self:custom.env.${self:provider.stage}.db_host}
    DB_PORT: ${self:custom.env.${self:provider.stage}.db_port}
    NODE_ENV: ${self:custom.env.${self:provider.stage}.stage}
functions:
  app:
    handler: handler.index
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'
    layers:
      - {Ref: PgLambdaLayer}
plugins:
  - serverless-offline
  - serverless-sequelize-migrations

Deploying

Now we’re ready to deploy. Make sure to change your function code back to using db.authenticate() as that will be the proof that we’ve made a successfully db connection and that our Serverless app is utilizing the layer we just created to talk in Postgres to our RDS instance.

This first deployment will be slower than the rest because it will have to create the Lambda layer, but subsequent deploys will skip this step. When you’re ready, go ahead and deploy it with the following command:

sls deploy -s prod

Serverless will output in the terminal all the steps it’s taking to deploy your Lambda, including the step of building your lambda layer. When it’s done, visit the link it’s provided you or directly go to the endpoint you created in order to see it in action!

And if you see that your connection is successful, congrats! If we’re still seeing errors, I recommend again to check to see if your connection credentials are correct and that the security group is configured as mentioned earlier, allowing Postgres TCP connections from 0.0.0.0/0 and ::/0.

If it’s working, you can move onto the next step, which is creating some migrations and models locally, pushing those migrations to your production server, which will be covered in the next (much shorter) post coming soon.

Connecting AWS Lambda To A Postgres DB: Part 1

Dan — Wed, 07 Oct 2020 07:35:20 +0000

Part 0: Pre-requesites

Serverless functions are, at their core, extremely simple. Configuration ends up being the biggest bugger. Still, there are a few things I assume in this tutorial:

Familiarity with Javascript, Node, npm. All installed
An AWS account. Sign up for one if you don't have it.
Serverless Framework configured. Serverless Framework's benefit is it creates and deploys a lot of AWS resources on your behalf. To do, though, that it needs be able to access those resources, so there is some initial configuration that needs to take place. For that, instead of re-write their docs I'll point you to the Serverless blog.

Part 1: Setting up a Project with Serverless Framework

Scaffolding the Project

To scaffold a Serverless project run in your Terminal:



$ serverless create —template aws-nodejs —path sls-new-project

This will create a folder called sls-new-project that contains just two files, handler.js which has your function’s logic, and serverless.yaml which contains all the configuration. Very minimal to start.

Setting up a local database and Sequelize

We want to use Postgres and an object-relational mapper (ORM) called Sequelize. So let's install those dependencies into our project via npm.

First npm init to create a package.json in our project. Then start installing some dependencies:



npm install --save pg
npm install --save pg-hstore
npm install --save sequelize
npm install -—save-dev sequelize-cli

Because we’ll be running some migrations we want to use sequelize-cli to generate those migrations. We can run npx sequelize-cli init which will create a migrations folder, config which tells the cli how to connect to the database for each environment, models folder for our various models, and seeders. You can get the full instructions for initializing sequelize-cli here.

If you read the contents of the just-created config/config.json you’ll see it’s configured for MySQL. Few things to change:

Go ahead and change those to postgres and save them.
Also, change the username value under development to the name of your root user of your device.
Also, please change the name of the database to something like sls-starter or something related to the name of your project.

Remember, this config only tells the CLI how to access the database, so we also have to tell our application to access the database. We’ll do this in a separate file, in the next step.

We don’t have any models yet, but we’ll start creating them soon. But last step before that we have to create the local database: do so with the command npx sequelize-cli db:create.

If it fails, you probably missed changing something in the config/config.json file. Follow the steps above to make sure the user is the root user on your device, the database name is unique, and you’re using the correct type of database postgres. For now you only need to change those values under development.

For reference, here’s my config/config.json



{
  "development": {
    "username": "dengel",
    "password": null,
    "database": "sls-starter",
    "host": "127.0.0.1",
    "dialect": "postgres"
  },
  "test": {
    "username": "dengel",
    "password": null,
    "database": "database_test",
    "host": "127.0.0.1",
    "dialect": "postgres"
  },
  "production": {
    "username": "dengel",
    "password": null,
    "database": "database_production",
    "host": "127.0.0.1",
    "dialect": "postgres"
  }
}

When it succeeds you’ll see the message:



Sequelize CLI [Node: 10.16.0, CLI: 6.2.0, ORM: 6.3.5]

Loaded configuration file "config/config.json".
Using environment "development".
Database sls-starter created.

The link above can help with creating models too; for this tutorial we're going to leave that to the end, first simply ensuring we can make database connections successfully.

At this point your project file structure should look like this:

Connecting to the local database in the application

Okay, we’ve installed a lot of things and now it’s time to write some connection logic.

We'll do that in a separate file called connection.js, which we'll create at the root of the project.



const { Sequelize } = require('sequelize');
const pg = require('pg')

const sequelize = new Sequelize('sls-starter', 'dengel', '', {
  dialect: 'postgres',
  dialectModule: pg,
  host: '127.0.0.1'
})

module.exports = sequelize

You’ll notice a few things about the above code:

that we’ve hardcoded the dbname, username, password (which is null) and db.endpoint.url in the configuration. This isn’t good practice and we will look at how to improve this and use environment variables to make this dynamic based on the environment in the next post.
We require the pg postgres node_module here and pass that object in as the dialectModule option in the Sequelize constructor. This is necessary for the Lambda function, Sequelize, and Postgres to work together harmoniously.

We’ve exported that connection logic, now let’s import it into our handler.js.

Delete everything that the serverless create command created earlier in this file and let’s start fresh.

We’re going to be using http triggers for the functions, so we also want to install the following packages:



npm install —-save serverless-http
npm install --save express

Then require them in our handler.js



'use strict';
const db = require('./connection.js');
const serverless = require('serverless-http');
const express = require('express');
const app = express();

And now we can add a function to test our database connection.



app.get('/test', async function (req, res) {

let msg;
try {
  await db.authenticate();
  msg = 'Connection successful'
} catch (error) {
  msg = 'Unable to connect to the database:'
  console.error('Unable to connect to the database:', error);
}

  return res.send(msg)
})

module.exports.index = serverless(app)

We’re almost ready to test our function.

When it comes to testing things, one of the most important factors is finding ways to speed up the feedback loop. It would be a shame if the only way to test our functions was by deploying them and seeing if they work on production. That’s why we’re going to install some more plug-ins.

Speeding up our feedback loop

The Serverless Framework plugins we use assist our development, serverless-offline to test our functions locally to speed up the feedback loop (crucial) and serverless-sequelize-migrations which takes our migrations and runs them on the production environment for us. We’ll use it a little later in our project. These aren’t npm packages, but plugins that we install via the serverless CLI then refer to in our serverless.yaml.

So first, from your project root run in the terminal the following commands:



serverless plugin install —name serverless-offline
serverless plugin install —name serverless-sequelize-migrations

Then go into your serverless.yaml file which we haven't touched at all yet.

You can take a look at all the different options that are commented out. I will only touch on the ones that are important for us now.

You can leave the server and provider configurations, and now we’re going to add a plugins section at the highest level of the yaml.



plugins:
  - serverless-offline
  - serverless-sequelize-migrations

We can also change the details of the functions section to more accurately reflect what’s now in our handler.js:



functions:
  app:
    handler: handler.index
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

This tells Serverless how to configure out AWS Lambda when we eventually deploy it, but also what options will be available to use locally, and how to access our function (via handler.index, where handler refers to what we named the file, and index refers to what we exported in module.exports.

Now it’s time to check if it’s working.

Local Smoke Test and Next Steps

A smoke test just a simple test to see if things are working as expected. The logic of our only function runs Sequelize’s db.authenticate() function and prints whether it successfully connects or not.

To test, we’ll run sls offline which now starts a local mock of our serverless function. We can visit http://localhost:3000/dev/test to see if our function is successful. And if everything was followed correctly, you should see “Connection successful” or whatever your success message in the function was in the browser.

But, if you were to run sls deploy at this point and try this in production, it would fail because

we don’t have a production database and,
AWS Lambda can’t speak Postgres without some more extra configuration.

That’s what we’ll do in the next post, as well as separating our environments.

Loading Local Files in Firefox and Chrome

Dan — Thu, 21 May 2020 03:41:47 +0000

One of the many cool things about working in the browser is you can just drag and drop a local HTML file into it and see your work. No local server running or anything, just files and a browser, like Adam and Eve. But due to browser security settings, developing this way can still trigger CORS-related errors when you load in local files, such as an mp4.

Let's see how to eliminate pesky CORS errors while doing this most foundational style of local development!

The Problem

So, I just spent about 10 minutes trying to load in a local audio file, and I kept getting the following error in the browser console:

The HTMLMediaElement passed to createMediaElementSource has 
a cross-origin resource, the node will output silence.

In Chrome you may see something like:

MediaElementAudioSource outputs zeroes due to CORS access 
restrictions for file:///Users/dengel/code/experi/dengel.m4a

I tried a few things that did not work:

adding the crossorigin="anonymous attribute to the <audio> tag
passing in the absolute filepath to the .mp4

These attempts just ended up raising different errors. It turns out you need to look to the browser settings to get past these errors.

Fixing this in Firefox

In Firefox, first you need to navigate to about:config in the Firefox browser, search for the privacy.file_unique_origin setting, and set it from true to false by double-clicking it. Voila, super easy!

Fixing this in Chrome

If you're working in Chrome it's a little more laborious and requires using the Terminal (I'm on a Mac, but judging from this StackOverflow post, for PowerShell users it's not much different):

In the Chrome address bar, navigate to chrome://version
On this page, find and copy the value of "Command Line". It will look like /Applications/Google Chrome.app/Contents/MacOS/Google Chrome.
Open your Terminal and paste in the file path to the Chrome executable you just copied
If it's not recognizing the path, the spaces in the file path might need to be escaped with a forward-slash like Google\ Chrome.app
Before you hit enter, two more things to add to this command
Add the following flag to the end of your command: --allow-file-access-from-files
Finally, add the folder or file you want to open at the end, like audio.html

Your final command in Terminal will look something like this (assuming you're within your project folder):

$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome  
--allow-file-access-from-files audio.html

If the command is successful, it should open up a Chrome window with your folder or file that you specified in the last step.

One gotcha I encountered was I needed to close my already-open instance of Chrome for the allow-file-access-from-files flag to register.

After that, my audio file was loaded and I got on my merry way. Hope this saves you a few minutes of searching!