What I wanted was to codify and standardize the types of things that we were already doing and just remove choice and remove friction and just give people the ability to sit down and say, "all right I know these technologies already, I have the prerequisite knowledge to do this."
Tom Preston-Werner - Full Stack Radio 138
|I - Redwood Philosophies||Part 1 - Setup|
|II - Full Stack React||Part 2 - Routes|
|III - Jamstack||Part 3 - Prisma|
|IV - Serverless||Part 4 - CRUD|
|Part 5 - Contact|
|Part 6 - GraphQL|
|Part 7 - Deploy|
|Part 8 - Auth|
In this part we'll get our database up and running and learn to create, retrieve, update, and destroy blog posts.
So far we've been working in the
web folder. In our
api folder there is a folder called
prisma for our Prisma schema.
It is similar to an ORM and was selected by Tom in the hopes of emulating Active Record's role in Ruby on Rails.
The Prisma schema file is the main configuration file for your Prisma setup. It is typically called
In order to set up Prisma Client, you need a Prisma schema file with:
- your database connection
- the Prisma Client
- at least one
We'll delete the default
UserExample model and make a
Post model with an
seeds.js is used to populate your database with any data that needs to exist for your app to run at all (maybe an admin user or site configuration).
yarn rw db save generates the folders and files necessary to create a new migration.
yarn rw db save
This will create our database migration.
It is named
migration by default.
- Data sources specify the details of the data sources Prisma should connect to such as a PostgreSQL database
- Generators specify what clients should be generated such as the Prisma Client
- Data model definition specifies your application models and their relations
A migration defines the steps necessary to update your current schema.
migrate command creates and manages database migrations. It can be used to create, apply, and rollback database schema updates in a controlled manner.
README contains a human-readable description of the migration.
It includes metadata like:
- when the migration was created and by who
- a list of the actual migration changes
- a diff of the changes that are made to the
schema.prisma in the migration folder is the schema that will be created if the migration is applied to the project.
steps.json is an alternative representation of the migration steps that will be applied.
Steps are actions that resolve into zero or more database commands. Steps generically describe models, fields and relationships, so they can be easily translated to datasource-specific migration commands.
This command generates the Prisma client and applies migrations. The database is migrated up to a specific state.
yarn rw db up
This will run the commands against the database to create the changes we need. This results in a new table called
Post with the fields we defined.
datasource defines a SQLite database.
After checking for data loss the database actions will be executed. In this instance we just have a single
CreateTable statement for our Post model.
The Prisma client will then be generated.
A scaffold quickly creates a CRUD interface for a model by generating all the necessary files and corresponding routes.
yarn rw g scaffold post
This will generate pages, SDL's, services, layouts, cells, and components based on a given database schema Model. Look at all the stuff I'm not doing!
Open the browser and enter
We have a new page called Posts with a button to create a new post. If we click the new post button we are given an input form with fields for title and body.
We were taken to a new route,
/posts/new. Let's create a blog post about everyone's favorite dinosaur.
If we click the save button we are brought back to the posts page.
We now have a table with our first post.
When we click the edit button we are taken to a route for the individual post that we want to edit. Each post has a unique id.
The title has now been changed from
01-deno-edit. Now we'll create another post.
If we click the delete button we will be given a warning.
Click ok to confirm and you'll receive a message saying your post has been deleted.
Lets add another blog post:
And one more:
If we make more posts they will start on the id after the deleted item. We already had an id 2. You can't call something else id 2, that would make your database a liar.
In the next part we'll look at the code that powers this functionality and learn about Cells. We'll also set up our frontend to query data from our backend to render a list of our blog posts to the front page.