I noticed that the Serverless deployment docs mention setting the production database URL in the environment variable rather than including details on how to create a database in AWS.
Obviously this is because creating an RDS database in AWS is a relatively big task that requires a bunch of skills.
However I think there is definitely a solid argument for making it easy to host the entire Redwood stack from DB to frontend on AWS. There are a lot of reasons why a project might require or prefer hosting soley on AWS but I won’t make that argument here and instead assume it is a widely held view.
In addition AWS Aurora Serverless V2 has recently become generally available (April 2022) and has some great features which make it a solid option for a low maintenance database.
So the discussion I’d like to start is about adding a deployment plugin that leverages the popular AWS CDK infrastructure as code project as well as the new Serverless Stack (SST) project.
Also worth noting is that you can use the RDS proxy with Aurora Serverless V2 ( from the docs )
You can use RDS Proxy with Aurora Serverless v2 clusters but not with Aurora Serverless v1 clusters.
I have been using Redwood for a side project at work. If the project graduates into something we will continue with our CIO will 100% want to bring everything inside our AWS account and in line with all our security and infrastructure policies. Something like you suggests is very interesting.
I used SST in my debut journey into serverless, I was really impressed by the experience. We currently use Serverless Framework for the AWS serverless deploy setup, but I think it can be a great to try with SST !
The serverless deployment didn’t fit well for us, using custom domain, CDN, preventing preflight CORS calls and other details. Now we are full AWS but using serverless deployment only for the api side, and improving our IaC to reduce manual deployment steps. But database was not a thing we planned to automate.
@janaka I mean, we actually automated the database creation but since it’s a one-time setup, we don’t see advantages including another asset in the serverless.yml to increase deploy time(even when it’s already created, cloudformation needs to check for updates) and add a new deployment failure point.
@gilliard ah yes, I understand what you meant now. That makes total sense.
I believe all these serverless frameworks couple the deploy with the infra change set.
I think that’s one of the reasons I’ve not been too keen with them, at least Serverless Framework and AWS SAM. Not tried SSTs but sounds like it’s the same.
I’m just working on a setup using Pulumi where they are decoupled. Let’s see how well it works.