Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve setup for new developers #176

Open
lefnire opened this issue Aug 13, 2023 · 0 comments
Open

Improve setup for new developers #176

lefnire opened this issue Aug 13, 2023 · 0 comments
Assignees

Comments

@lefnire
Copy link
Collaborator

lefnire commented Aug 13, 2023

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).

@lefnire lefnire self-assigned this Aug 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ASAP
Development

No branches or pull requests

1 participant