Integrate sst.dev with @remotion/lambda

xinha-sh commented 1 year ago

The main issue with AWS lambda is that it's quite overwhelming to learn. People who're accustomed to Vercel / Netlify like DX, avoid tinkering with AWS console. For the same reasons, SST exists.

In SST, it's very easy to configure infrastructure using typescript. Ex: Configuring S3 buckets is as easy as following: https://docs.sst.dev/constructs/Bucket

import { Bucket } from "sst/constructs";

new Bucket(stack, "Bucket", {
  notifications: {
    myNotification: "src/notification.main",
  },
});

and deploying a VITE site is done using: https://docs.sst.dev/constructs/StaticSite

new StaticSite(stack, "Site", {
  path: "path/to/site",
  customDomain: {
    domainName: "my-app.com",
    domainAlias: "www.my-app.com",
  },
});

Integration with sst.dev can provide following benefits:

Lesser learning curve. It will make it easier to deploy and manage remotion apps.
Auth, APIs etc can be easily leveraged.
Other AWS services like, AWS Bedrock can be leverage easily. User, role, permissions management etc will be relatively easier with sst.

I can help with the sst side of things, as I've been developing with it for some time. I can also provide a $100 bounty if someone wants to take it up and push it through.

alexfernandez803 commented 1 year ago

@xinha-sh you want a documentation of sort?

xinha-sh commented 1 year ago

@xinha-sh you want a documentation of sort?

Yup that'll work.

alexfernandez803 commented 1 year ago

Happy to take it, if you want. Please define the scope of the documentation

JonnyBurger commented 1 year ago

I'm in favor of exploring better integration with SST, but I want to add some comments on the initial motivation:

Remotion already is a layer on top of the AWS complexity. Instead of new StaticSite, we have the await deploySite() API which you can use in a Node.js script.
Both Remotion Lambda and SST require a setup step in the AWS console. The Remotion one takes more steps because we only get the necessary permissions, while SST takes root permissions of the AWS account.

I also do not understand why adding SST will make auth and learning easier. Maybe you can elaborate more on this.

xinha-sh commented 1 year ago

I'm in favor of exploring better integration with SST, but I want to add some comments on the initial motivation:

Remotion already is a layer on top of the AWS complexity. Instead of new StaticSite, we have the await deploySite() API which you can use in a Node.js script.

Both Remotion Lambda and SST require a setup step in the AWS console. The Remotion one takes more steps because we only get the necessary permissions, while SST takes root permissions of the AWS account.

I also do not understand why adding SST will make auth and learning easier. Maybe you can elaborate more on this.

I guess I wasn't able to convey properly SST will make auth and learning easier.. SST has constructs for Auth and API Gateway. So, for example, if I am building a SaaS using sst.dev, most likely I will have a frontend, set of APIs including auth. And when we are able to deploy remotion lambda using SST and add endpoints to the existing API gateway configuration, we can leverage the existing auth implementation as well.

I feel learning will be easier with sst.dev because

Running the starter templates will be one command. NextJs / Vite + React, Lambda, APIs will all live in one AWS account. If you're configuring AWS infra, why not deploy frontend on the same infra.
Also, while running project locally, running deploy.mjs will become redundant, as SST doesn't require re-deployments in case of no infra change.
Configuring different environment variables for development, staging, production and passing endpoints to frontend for each environment etc will also get easier

xinha-sh commented 1 year ago

Happy to take it, if you want. Please define the scope of the documentation

Hey Alex I stumbled upon a message that you have some sst integration with remotion lambda. Can you please share a doc or sample code.

JonnyBurger commented 1 year ago

A quick update from our side:

I can see these benefits, those would only be achieved though if we also allow to deploy a Next app in an AWS account which is a different beast.

I see SST as one of three popular Infrastructure-as-a-service languages:

CloudFormation
Terraform
SST

But from my perception it is the least popular out of the three, which is why we will prioritize the other ones.

xinha-sh commented 1 year ago

A quick update from our side:

I can see these benefits, those would only be achieved though if we also allow to deploy a Next app in an AWS account which is a different beast.

I see SST as one of three popular Infrastructure-as-a-service languages:

CloudFormation

Terraform

SST

But from my perception it is the least popular out of the three, which is why we will prioritize the other ones.

Totally understand your priorities.

But I feel you should opt for ease of use. React JS developers (frontend mainly) should be able to do that with minimum learning curve. SST is built on top of CloudFormation, and creating infrastructure using Typescript will resonate most with remotion target user.

Once you're done with CloudFormation support, let me know, I will raise a PR for sst dev support. Thanks

JonnyBurger commented 7 months ago

Relevant: https://github.com/karelnagel/pulumi-remotion-lambda

Made by @karelnagel!

xinha-sh commented 7 months ago

Relevant: https://github.com/karelnagel/pulumi-remotion-lambda

Made by @karelnagel!

Great. Should I close the issue then ?

JonnyBurger commented 6 months ago

Will track all infra-as-code tools here: #1078

remotion-dev / remotion

Integrate sst.dev with @remotion/lambda #2853