Ensure we perfectly understand Prisma workflows in production and support them with Wasp CLI and docs

wasp-lang / wasp

The fastest way to develop full-stack web apps with React & Node.js.

https://wasp-lang.dev

MIT License

13.78k stars 1.18k forks source link

Ensure we perfectly understand Prisma workflows in production and support them with Wasp CLI and docs #908

Open Martinsos opened 1 year ago

Martinsos commented 1 year ago

While we are doing relatively ok with Prisma, I believe we can learn more about the best way to handle it in production, and ensure that we support the typical use cases and workflows, both via commands in Wasp CLI and via our docs.

This is important as we go toward Wasp 1.0 .

Some related issues:

Martinsos commented 1 year ago

Consider how to run seeding for production db.

Dev can run DATABASE_URL=<production_db_url> wasp db seed but that feels bad, with data traveling around and db being exposed to the public internet.

@infomiho proposed doing this same way but via ssh tunnel maybe? Or running it on the machine where server is running?

Maybe flyctl postgres connect -a street-cred-db or fly proxy 5432 -a <postgres-app-name> are useful when dealing with Fly?

infomiho commented 1 year ago

Running fly proxy 5432 -a <postgres-app-name> was the first piece, but for the thing to work fully, I needed to find my Fly database username and password. I found that when I was first deploying my app with Wasp onto Fly. I'm not sure if we can get that info later on and provide it to the user? @shayneczyzewski

What worked for fly.io

After I ran fly proxy 5432 -a <basename>-db it tunneled the db to my localhost, which is great. Then I put the following in my env.

DATABASE_URL=postgres://<user>:<pw>@localhost:5432/<db_name>?sslmode=disable

shayneczyzewski commented 1 year ago

I don't think you can get the DB creds again @infomiho from Fly, which is why we warn them on launch with the warning that Fly gives about it.

Proxying to DB to get it sounds reasonable. One other thing to consider, can't we just ssh onto an app server and run it there? https://fly.io/docs/flyctl/ssh/ I would expect the app server to have access to the envar and if we have this already in package.json could we just call it that way?

Update: Just as a quick test, I tried it with flyctl ssh console -a waspleau and it does have the db envar, plus our app stuff lives under /app/server so we could in theory just have them do this?

Update 2: however I just noticed we were talking about Wasp CLI, so that isn't ideal to ssh onto it. I think in this case we can maybe just proxy to the app server/db instead and run it that way like you all suggest.

infomiho commented 1 year ago

@shayneczyzewski But they don't have Wasp installed in the deployed app. We could tell them to install it, or we could ship the binary as well, but that sounds a bit off to me. What do you think?

shayneczyzewski commented 1 year ago

@shayneczyzewski But they don't have Wasp installed in the deployed app. We could tell them to install it, or we could ship the binary as well, but that sounds a bit off to me. What do you think?

I was just thinking if all wasp db seed does is really call something in package.json anyways, it may not be too bad to just call it directly so they won't even need wasp installed. Proxying feels like the simplest though (but admittedly I haven't tried it yet).