The current setup is very hard-coded; strongly tied to gnothiai.com, the primary gnothi email address, etc. Further, it uses a sort of production setup even for development, which creates (1) a VPC with private subnet and NAT gateway; (2) Aurora Serverless v2 cluster in that private subnet; (3) EFS in that sub; (4) deploys the ML Lambdas in that sub. This racks up a total bill of $70/m for anyone who wants to even just play with the project. So:
Step 1: only use private subnet & aurora serverless v2 in staging/prod
This will require overhauling the SST stacks to (1) check if in dev-mode (app.mode === "dev"), and if so using the public subnet so that a NAT gateway isn't required; (2) skipping Aurora Serverless (RDS) and instead using a localhost Postgres setup.
See a sample codebase I posted here on how this can be done. Also scroll down from that comment, someone has another sample codebase which may be better.
Step 2: upgrade SST for native Docker support
The ML stuff from (4) above deploys ML to AWS via ECR. This means we can't test / debug anything Python locally. This was because SST didn't used to support Docker functions or Python at all; you were on your own. Now they have native support for both, so you can live-debug Python / Docker stuff locally. This means a smaller dependence on VPC, EFS, etc. So with the SST upgrade we'll want to rework all things Docker / Python in the codebase.
Step 3: remove stage:shared from dev
You'll see the way to deploy things currently, you need to run npx sst deploy --stage=shared-staging and npx sst-deploy --stage=staging (I need to revisit if that even works, this stuff is pretty old). Since steps 1 & 2 above would remove all need for the shared stack when in dev-mode, we should skip that stack entirely on localhost. You'll see an example of that in that post from above. This would make setups much less confusing for new devs too, just one npm start (or better: npm run sst:dev, so we can have npm run vit:dev for web).
The current setup is very hard-coded; strongly tied to gnothiai.com, the primary gnothi email address, etc. Further, it uses a sort of production setup even for development, which creates (1) a VPC with private subnet and NAT gateway; (2) Aurora Serverless v2 cluster in that private subnet; (3) EFS in that sub; (4) deploys the ML Lambdas in that sub. This racks up a total bill of $70/m for anyone who wants to even just play with the project. So:
Step 1: only use private subnet & aurora serverless v2 in staging/prod
This will require overhauling the SST stacks to (1) check if in dev-mode (
app.mode === "dev"), and if so using the public subnet so that a NAT gateway isn't required; (2) skipping Aurora Serverless (RDS) and instead using a localhost Postgres setup.See a sample codebase I posted here on how this can be done. Also scroll down from that comment, someone has another sample codebase which may be better.
Step 2: upgrade SST for native Docker support
The ML stuff from (4) above deploys ML to AWS via ECR. This means we can't test / debug anything Python locally. This was because SST didn't used to support Docker functions or Python at all; you were on your own. Now they have native support for both, so you can live-debug Python / Docker stuff locally. This means a smaller dependence on VPC, EFS, etc. So with the SST upgrade we'll want to rework all things Docker / Python in the codebase.
Step 3: remove stage:shared from dev
You'll see the way to deploy things currently, you need to run
npx sst deploy --stage=shared-stagingandnpx sst-deploy --stage=staging(I need to revisit if that even works, this stuff is pretty old). Since steps 1 & 2 above would remove all need for the shared stack when in dev-mode, we should skip that stack entirely on localhost. You'll see an example of that in that post from above. This would make setups much less confusing for new devs too, just onenpm start(or better:npm run sst:dev, so we can havenpm run vit:devfor web).