Recommendation for deploying and database
Hi I have been thinking about the deployment of my app and the database. I currently already have a postgress database running with lots of data in it (but i dont use it yet in development).
What i did with development now is add these exact tables that are in the "actual" postgres database in the "development" database through the prisma scheme (for testing purposes). Now I have been thinking on what to do when deploying my app:
1. Add the Models (tables) that are in the "dev" table to my own database, that are not there yet like: Auth, AuthIdentity etc.
2. Maybe there is some way to keep the current local database (fill the tables with the actual data) and deploy this one.
What would be the easiest and what are your recommendations?
17 Replies
Hi @Sven. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the information provided in the knowledge sources, here are some recommendations for deploying your app and managing your database:
1. Database Migration: You can use the
wasp db migrate-dev command to synchronize your development database with the current state of the schema (entities). If there are any changes in the schema, it generates a new migration and applies any pending migrations to the database. This could be useful for adding the models (tables) that are in the "dev" table to your own database source (https://wasp-lang.dev/docs/general/cli#database-commands).
2. Database Seeding: Database seeding is a term used for populating the database with some initial data. This could be useful if you want to fill the tables with actual data source (https://wasp-lang.dev/docs/data-model/backends#seeding-the-database).
3. Deployment Providers: Wasp supports several deployment providers including Fly.io, Netlify, Railway, and Heroku. You can choose the one that best suits your needs source (https://wasp-lang.dev/docs/advanced/deployment/manually#different-providers).
4. Environment Variables: You can use environment variables to provide the DATABASE_URL to your application. This allows you to switch between different databases (e.g., development and production) without changing your code source (https://github.com/wasp-lang/wasp/issues/173).
5. PostgreSQL: If you're using PostgreSQL, you can specify it as a provider in the app declaration's db field. You can also use Docker to run a PostgreSQL database for development source (https://github.com/wasp-lang/wasp/issues/173).
Remember to ensure that your production database is accessible from the server and that you provide the server with the correct DATABASE_URL environment variable source (https://wasp-lang.dev/docs/advanced/deployment/manually#4-deploying-the-database).
As for which option would be the easiest, it depends on your specific needs and circumstances. However, using the wasp db migrate-dev command to synchronize your databases and using environment variables to switch between them could be a good starting point.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Not really the answer i was looking for
When you deploy your app, your server connects to your production app and runs the migrations that you have in your migrations dir. This happens every time you add new migrations and decide to deploy. This way the shape of your production database matches the development database.
Having your data from development database in the production database doesn't happen automatically because it usually doesn't make sense to copy stuff from development which has a lot of test data etc.
You can however, use the database seeding functionality of Wasp that enables you run some JS code to populate your database with some initial data: https://wasp-lang.dev/docs/data-model/backends#seeding-the-database
This way, you get the same shape of the database + the intial data that you need to get your project going. Usually, the development and the production database are two different things and their data differs by quite a bit since you have real users in the production database and some test data in the development database.
Databases | Wasp
Entities, Operations and Automatic CRUD together make a high-level interface for working with your app's data. Still, all that data has to live somewhere, so let's see how Wasp deals with databases.
yes I understand thanks, the thing is i want to showcase actual measured data in a graph in my app. Right now as in development phase i have seeded the "ProductData" table with some tesst data. But eventually i want it to use the actual data from my own postgress database's "ProductData" table.
I was think about what the best/ optimal way is to do this?
But eventually i want it to use the actual data from my own postgress database's "ProductData" table.Where do you want to use this "actual data", in the deployed production app or in development?
deployed production app
I don't understand the problem you are trying to solve. If you have a production DB and the production app connects to it, you'll see the data from the production DB. That's it 😄
Yeah but my product database doesnt have the all the table wasp created intially:
all these^
Did you create these tables manually or via editing the Prisma file? If you created them via the Prisma file, you are good to go. The same tables will be created in the production DB.
Wasp creates the Auth, AuthIdentity and Session tables for you in production as well, as explained here: https://wasp-lang.dev/docs/auth/entities#entities-explained
Accessing User Data | Wasp
First, we'll check out the most practical info: how to access the user's data in your app.
Ahh nice! thats good to hear, could i also connect to my actual database in the development app? by adding the
DATABASE_URL in the env.server?You can of course, but you'll need to be careful if you want to experiment with new tables / adding / removing fields. You can mess up your production env and then it's a pain to fix it. Better to keep these things separated 😄 but of course, you can!
what do you mean mess up production environment? what could happen? Not that i am any of those myself, besides that i know wasp will now generate the Auth, Authidentity etc. tables for me but that wouldn't mess up right?
Developing against a production database is considered a bad practice because you might be experimenting and affect the production environment. This is beyond Wasp's scope, it's just my advice to you 😄
I still dont get this part, you always keep a dev database and a production data base right? Once deployed everything will be running and the productiondatabse will be filled with data. So what do you mean with developing against a production database?
Hoe would you properly migrate devrlopment changes to production databse then?