DEV Community: German Escobar

Zoom recording to S3 using an AWS Lambda

German Escobar — Tue, 01 Oct 2024 00:15:45 +0000

I was using Pipedream to store my Zoom recordings in S3 but they changed the pricing and it is not free anymore. So, I decided that this would be a fun project in any case.

ChatGPT wasn't very helpful, eventually this repo helped me. Here's the final code:

import { S3Client } from '@aws-sdk/client-s3';
import crypto from 'crypto';
import { nanoid } from 'nanoid';
import { Upload } from '@aws-sdk/lib-storage';
import got from 'got';
import { format } from 'date-fns';

const zoomSecretToken = process.env.ZOOM_SECRET_TOKEN;
const s3 = new S3Client({ region: "us-east-1" });

const bucketName = "...";

export const handler = async (event) => {
  try {
    const headers = event.headers;
    const zoomEvent = typeof event.body === 'string' ? JSON.parse(event.body) : event.body;

    if (zoomEvent.event === 'endpoint.url_validation') {
      const encryptedToken = crypto.createHmac('sha256', zoomSecretToken).update(zoomEvent.payload.plainToken).digest('hex');
      return {
        statusCode: 200,
        body: JSON.stringify({ plainToken: zoomEvent.payload.plainToken, encryptedToken })
      }
    } else if (zoomEvent.event !== 'recording.completed') {
      return { statusCode: 422, body: 'Invalid event type' };
    }

    const meetingId = zoomEvent.payload.object.id;
    const datePath = format(new Date(), 'yyyy-MM-dd');

    // Retrieve recording URLs from the event payload
    const recordingFiles = zoomEvent.payload.object.recording_files;

    const videoRecordings = recordingFiles.filter(file => file.file_type === "MP4" && !file.recording_type.includes("audio"));
    if (videoRecordings.length === 0) {
      return { statusCode: 409, body: 'No video recordings found' };
    }

    const file = videoRecordings[0];
    const fileUrl = file.download_url + "?access_token=" + zoomEvent.download_token;
    const filepath = `videos/${meetingId}/${datePath}/${nanoid(10)}.${file.file_type.toLowerCase()}`;

    // Download the file and upload to S3
    await uploadToS3(fileUrl, bucketName, filepath);

    return {
      statusCode: 200,
      body: 'Zoom recording successfully uploaded to S3',
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ message: 'Error uploading Zoom recording', error: error.message }),
    };
  }
};

// Helper function to upload file from URL to S3
const uploadToS3 = async (fileUrl, bucketName, key) => {
  const stream = got.stream(fileUrl);

  const upload = new Upload({
    client: s3,
    params: {
      Bucket: bucketName,
      Key: key,
      Body: stream,
      ContentType: 'video/mp4',
      ACL: 'public-read',
    },
  });

  const result = await upload.done();
  return result;
};

My package.json:

{
  "name": "zoom-to-s3",
  "version": "1.0.0",
  "description": "",
  "main": "index.mjs",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "zip": "zip -r function.zip ."
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@aws-sdk/client-lambda": "^3.659.0",
    "date-fns": "^4.1.0",
    "got": "^14.4.2",
    "nanoid": "^5.0.7",
    "postmark": "^4.0.5"
  }
}

And my .github/workflows/deploy.yml to deploy it when I push to main:

name: Deploy Lambda

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '20'

      - name: Install Dependencies
        run: npm install

      - name: Zip Lambda Function
        run: npm run zip

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Deploy Lambda
        run: |
          aws lambda update-function-code \
            --function-name zoom-recording-to-s3 \
            --zip-file fileb://function.zip

Book review: A Philosophy of Software Design

German Escobar — Tue, 31 Oct 2023 23:45:04 +0000

This book is about complexity in software and how avoid it. I think the ideas are reasonable and match my experience in general. For example, I do believe that:

A good test suite is crucial for a maintainable software.
Naming things right and comments are really important, it helps a lot when you are reading software (which is most of the time)
A variable with a wider scope should have a name that is more expressive that one with a narrower scope (and usually will be longer for this reason).
High cohesion (things that are related should be close together) and low coupling (minimize dependencies between modules) matter a lot.
Code should look like it has been written by the same person. Using formatters and linters help us somewhat with this.
Knowing about design patters help us having a common vocabulary and understand code easily.
TDD is great for bugs but not so much for software design IMO.
Having at least two possible design options before writing code is a good practice.
Writing comments or how you intend to use the software before writing it is also a good practice.

I would also add the following:

The flow of the code should go on one direction through the layers. For example, controllers call services and services interact with the DB. Controllers never call the DB directly nor they call each other.
Every line of code is a liability, the best code is the one you don’t write. In this regard every line you add will increase complexity. Once you grasp this, it changes the way you write code.
The same can be said about libraries. You should be really careful with the libraries you add, you will have to update them and update your code accordingly every time they change. Sometimes it is better to duplicate the functionality to avoid the dependency.
Every external system adds complexity (e.g. having to work on a browser environment adds a ton of complexity, using a Database adds complexity, and so on).

Complexity is not something you should avoid, but you should definitely try to minimize.

I would have appreciated if the author had discussed what Software Design is, and what is the difference with Software Architecture.

In my opinion Software Design is about how to structure your code, while Software Architecture is about the system in general: what are the main components and how they are going to communicate between each other (e.g we’ll have a SPA with a GraphQL API and a Relational Database, etc.), which architecture are we going to use: monolith, micro services or serverless, what kind of pipeline are we going to use to process from devices, etc.

About Prisma (ORM)

German Escobar — Tue, 26 Sep 2023 21:24:38 +0000

Prisma is an interesting ORM with a different philosophy to Sequelize and others.

In Prisma you define a schema file with their own DSL called Prisma Schema Language (PSL) and you can create migrations updating the schema (Prisma will diff the file and create the migration file).

The good parts of Prisma:

Schema file (single source of truth).
Generated types are good. Everything is typed.
The API in general is easy to use.
Creating migrations by just changing the schema is a great idea (which has it's own drawbacks).

The bad parts:

CLI command names are clumsy.
Migrations break if you change multiple things.
No easy way to attach methods to models.
No easy way to handle validation errors.
No easy way to share transactions between functions.
No support for joins?

All in all Prisma is a great project but not one I would recommend right now.

Using caret and tilde in package.json dependencies

German Escobar — Wed, 30 Aug 2023 21:03:05 +0000

By default npm install will use the caret (^) notation when installing a dependency. For example, if you run:

npm i jsonwebtoken

npm will add the following dependency to your package.json:

"jsonwebtoken": "^9.0.0"

which is equivalent to "jsonwebtoken": "^9" (why are they wasting valuable characters?).

This means that npm can install any version greater or equal than 9.0.0 but less than 10.0.0.

In theory this should work because the SemVer specification says that the minor version (second number) should be backwards compatible.

In practice, however, library authors don't follow this rule strictly and can cause a lot of headaches.

Another option would be to use tilde (~), which only allows the patch version (third number to change):

"jsonwebtoken": "~9.0"

In this case npm can install versions greater or equal than 9.0.0 but less than 9.1.0.

This is safer and the option I would suggest. You can configure npm to use this option with the following command:

npm config set save-prefix "~"

However, keep in mind that newer patch versions can also introduce other bugs, so if you want to be completely safe you should use an exact version:

"jsonwebtoken": "9.0.0"

And use a tool such as Renovate to update your dependencies.

Types vs Interfaces in TypeScript

German Escobar — Wed, 30 Aug 2023 20:34:27 +0000

Even though there's a lot of information about this subject on the Internet, I haven't seen a single one mentioning that having two similar concepts was a mistake from the designers of the language.

Even though you can interchange types and interfaces in TypeScript most of the time, I will argue that unless you are going to implement an interface you should always use a type.

interface Configurable {
  configure(): void
}

class Task implements Configurable {
  configure(): void {
    // do some configuration
  }
}

Remember that an interface is basically a contract, so they should include only method declarations.

In conclusion, I suggetst you should use types most of the time, and only use interfaces if you are planning to write implementations.

Imports in Node.js

German Escobar — Wed, 30 Aug 2023 20:06:40 +0000

There are two main ways in which you can import code from another file (module):

Import only the exports you are interested on (using curly braces)
Import all the exports into an object (using import * as ...).

However, keep in mind that the option you choose can impact the way you name your exports.

If you are going to import only the exports you are interested on you may want to append more information to the name of each export. For example:

// users.service.js
export function listUsers() {}
export function createUser() {}

// controller.js
import { listUsers, createUser } from './users.service'

On the other hand, if you are going to import all the exports into an object you can shorten the names of the exports

// users.service.js
export function list() {}
export function create() {}

// service.js
import * as userService from './users'

It seems to me that userService.list() is a bit more clearer and simpler.