Prisma with Nextjs Guide
Prisma Generate and Prisma Migrate Dev
Caching behavior
With the introduction of nextjs 13 app router. Caching is greatly simplified.
There is no reason to use useSWR or react query. Simply move up the request up to the server page and pass it down as props.
Keeping them on the server components will allow for fetching data server side and passing down to the client components. This will also help to maintain global state that is entirely managed by the nextjs built in server caching.
Serverless Functions and Databases
Due to how serverless function database connections work it is recommended to use Neon Database as the production Database provider. This will allow us to use Prisma's serverless database drivers and not have to manage our own database connection pooler.
If you would like to use another provider, you will need to figure out a connection pooler strategy for the serverless functions. This is required as serverless functions generally wont function properly without it.
https://www.prisma.io/blog/how-prisma-and-serverless-fit-together-iaSfcPQVi0
https://www.prisma.io/blog/serverless-database-drivers-KML1ehXORxZV
init/prisma
Different Envs Different envs should allow for different prisma initialization. For example in development we attach the prisma object to global state
In test env we use a different connection url to connect to the test db.
init/prisma.
Database queries and mutations are kept in separate files as all the mutation functions in the file are converted into server actions.
Data queries on the other hand are kept as normal server functions and called on server pages. This allows query functions to be integrated into Nextjs internal caching system.
https://nextjs.org/docs/app/building-your-application/caching
Fetching data
For fetching data from a database, we will use regular server functions and call them on a server page.
We can then pass down this data to a child client component as props. This will allow us to use nextjs internal caching system and we dont need to setup our own on the front end.
React Query Data should be cached on the server and passed off to nextjs caching system. It can then be passed down to child client components as props. for this reason it is unnecessary to use a front end caching library.
Server Actions
Server Actions are a game changer for making API requests. They can be written and used like regular functions, completely bypassing the need to create API routes.
API routes
This project doesn't make use of many API routes. The only 2 routes in this project are set up because they are required for third party libraries.
It is always better to use server actions and regular server functions. There is generally no reason to use API routes if server actions and server functions are available.
Types and validation
Validation with ZOD.
Add validation to react hook form. Then add this same zod values the params for the server action
This will ensure that the data submitted from the form will always match the expected request params in the server action.
Type safety can further be done by setting the types on the prisma query data object.
todos/mutations.
It is also helpful to separate our server actions and regular server functions.
This is because for our queries such as getting data from a database need to be integrated with the nextjs cache system.
Also server actions under the hood are just POST requests which makes them less appropriate for making GET requests.