Prisma Client

Objectives

By the end of this lesson, you should be able to:

• Explain what prisma generate produces, and when it needs to be re-run
• Import and instantiate PrismaClient in a Node.js script
• Explain why Prisma Client is generated rather than hand-written

💡 Why this matters: Every query in Modules 4 through 6 goes through the object this lesson introduces. Understanding where it comes from, and when it needs regenerating, avoids a confusing class of “my new field doesn’t exist” bugs.

⚠️ A note on verification: as in the last two lessons, the Prisma CLI can’t run inside this course’s own sandboxed tooling. The command and code below reflect Prisma’s stable, current, documented behavior. Try it against your own schema, following the setup from the last two lessons.

Generating the Client

npx prisma generate

✔ Generated Prisma Client (v7.x.x) to ./node_modules/@prisma/client in 45ms

Start using Prisma Client in Node.js (See: https://pris.ly/d/client)

This reads schema.prisma, and generates a fully typed JavaScript client based on every model block in it, into node_modules/@prisma/client. It’s not hand-written, it’s regenerated from the schema every time this command runs, which is why prisma generate needs to be re-run any time a model changes.

Importing and Using It

const { PrismaClient } = require('@prisma/client');
const prisma = new PrismaClient();

async function main() {
  const students = await prisma.student.findMany();
  console.log(students);
}

main()
  .finally(() => prisma.$disconnect());

prisma.student exists because model Student exists in schema.prisma, one lowercase property per model, generated automatically. There’s no separate step to define what methods are available on it, findMany, create, update, delete, and more (all covered starting in Module 4’s exercises and in full in Module 6), come from Prisma Client itself, generated fresh for every project’s exact schema.

Why Generated, Not Hand-Written

A hand-written client would need updating by hand every time a model gained or lost a field. A generated one is guaranteed to match schema.prisma exactly, in an editor with TypeScript or JavaScript type-checking enabled, prisma.student.create({ data: { ... } }) even autocompletes the exact fields Student actually has, and flags a typo’d field name before the code ever runs.

When to Regenerate

prisma generate needs to run again any time schema.prisma changes, a new model, a new field, a new relationship (Module 5). In practice, Prisma’s migration command (Module 4) runs it automatically as part of applying a migration, so this is rarely a separate manual step in normal day-to-day work, but it’s worth knowing what’s actually happening underneath.

Try It

1. Run prisma generate against your own schema from the last two lessons.
2. Import PrismaClient in a script, instantiate it, and call prisma.student.findMany().
3. Add a new field to your Student model, but don’t run prisma generate again, then try to reference that field in code, and see what happens.
4. Explain, in your own words, why prisma.student (not prisma.Student) is the correct property name, based on what this lesson showed about how the client is generated.

Recap

• prisma generate reads schema.prisma and produces a typed client in node_modules/@prisma/client, regenerated any time the schema changes.
• PrismaClient is imported and instantiated once, prisma.<modelName> (lowercase) exposes query methods for each model.
• Being generated, not hand-written, is what keeps the client’s available fields and methods exactly in sync with the schema.

This is the final lesson of this module before exercises. Next module: defining real models and turning them into real database tables with migrations.