(The alternative title would be “how to rebuild an app that already created a persistent database, from scratch”)
RedwoodJS is well recognized and respected by its clever use of generators and by that removing the need for most “pedestrian” steps (creating and managing the database is a good example of such steps).
The problem with this approach (where lot of “stuff” is created without the developer seeing that is going on) are the difficulties related to the decision to restart the application from some point onwards.
Application creation
RedwoodJS tutorial does a great job presenting the sequence of commands needed to create a Redwood application using Redwood CLI, starting with:
yarn create redwood-app ./my-redwood-app
This seemingly simple command created a complex file structure as presented here, implementing the basic implementation of both RedwoodJS sides. In particular, the /api side (aka back-end) contains the db directory with the plumbing for the database and by default that plumbing creates the necessary files for SQlite database.
The summary of this text: it is the RedwoodJS CLI that creates the database plumbing - and does that for the SQLite database only
In order to start a RedwoodJS app that uses some other database (in this text we will pay attention to the PostgreSQL database which is the most likely choice for a “read” (meaning serious) Redwood application. This time, setting the basic database plumbing requires two steps:
In addition to the
yarn create redwood-app ./my-redwood-app
we need to edit the schema.prisma file (created by the first step above) to be: (note the definition of the database provider )
This is the minimum change needed to start using postgres database, provided that you supplied the definition of the “DATABASE_URL” string in your environment (.env) file like
DATABASE_URL=postgresql://postgres:[password]@localhost/[database-name]
where you need to define the password and database-name to fit your app.
In order to proceed with the app using postgres database development, one would have to create the initial migration
yarn rw prisma migrate dev
in order to proper initial definition of the database plumbing (shown below):
As an example of the migration.sql, consider the “plumbing” for the newest Redwood-Stripe tutorial by Stanislas Duprey, “living” in GitHub - generalui/redwood-stripe: A market place prototype using Redwoodjs and Stripe repository, as migration.sql
Starting this application from scratch
While following the RedwoodJS tutorial (where by following, i mean writing the code and running the generators as described in the tutorial) I tripped every few minutes by either missing a line in the tutorial, problem that would pop-up at the later time and I had no clue what went wrong. The only remedy of course is to delete the code written so far and start again.
As I learned very soon, the app itself is not persisted anywhere - deleting the code makes you perfectly positioned to start again and again, until you manage to write the whole app correctly.
If the app uses the SQLite database - deleting the code is sufficient to start writing the app from the beginning, since the SQLite by default is not persisted. So, my repetitive efforts to create the Redwood Blog application finally yielded success, although that experience led me to create the post Monterey: on reversible rw applications.
The situation is different though because the data created while building the app remains persisted - so you cannot simply delete your code and run the very first step
yarn create redwood-app ./my-app
as it will rewrite the already existing prisma-schema and pretty soon you will be in a pretty deep trouble trying use postgres database with the schema.prisma declaring the intent to use SQLite database situation described with more details here.
At the bare minimum, before starting to write the same code from the beginning, you should use the command:
yarn rw prisma migrate reset
