docs/1.16/understand-prisma/prisma-introduction-what-why-how-j9ff.mdx
import Collapse from 'components/Markdown/Collapse'
export const meta = { title: "Prisma Introduction: What, Why & How", position: 10, description: 'Learn about Prisma's use cases, main benefits and how it fits into your stack.' }
Prisma is an open-source, GraphQL-based data access layer (DAL) that turns your database into a GraphQL API.
Prisma lets you:
Prisma's main use case is to provide the data access layer (think ORM) for API servers. Because of its GraphQL engine, Prisma is most often used to build GraphQL APIs but also works with REST or any other API paradigm.
Other use cases for Prisma are scripts, functions, queue workers or any other context where developers need to talk to a database.
When building a GraphQL server that uses Prisma as its data access layer, it is important to understand that the auto-generated Prisma GraphQL API is not consumed by your client applications - instead you build the actual API server on top of Prisma.
To prevent misconceptions about Prisma, here's a list of what Prisma is not:
Prisma is open-source and can be used as a standalone infrastructure component hosted on your favorite cloud provider. Prisma Cloud is an application (used through a CLI & web interface) that provides tools and services around Prisma. When you're using Prisma, usage of Prisma Cloud is optional.
The goal of Prisma Cloud is to ease the workflows in Prisma projects. It features a data browser, a deployment history (soon with automatic rollbacks), various team collaboration options as well as cloud provider integrations to make it easy for developers to setup and maintain their Prisma servers.
Get started with Prisma Cloud here.
</Collapse>Prisma's overall goal is to remove complexity from common database workflows and make it easy for developers to work with databases:
Some databases, such as RethinkDB or DynamoDB provide a realtime API out-of-the box. Such an API lets clients subscribe to any changes happening in the database. The vast majority of conventional databases however does not offer such a realtime API, and implementing it manually gets very complex.
Prisma offers a realtime API for every supported database, letting clients subscribe to any database event using GraphQL subscriptions.
Programming in a type safe way is the default for modern application development. Here are some of the core benefits type safety provides:
End-to-end type safety refers to having type safety across the entire stack, from client to database. An end-to-end type safe GraphQL architecture might look as follows:
When developing application servers, most complexity lies in implementing a safe and well-organized database access with respect to synchronization, query optimization/performance and security. This becomes even more complicated when multiple databases are involved.
One common solution to thius problem is the introduction of a dedicated data access layer (DAL) that abstracts away the complexities of database access. The DAL's API is consumed by the application server, allowing API developers to simply think about what data they need instead of worrying about how to securely and performantly retrieve it from the database.
Using a DAL ensures a clear separation of concerns and therefore improves maintainability and reusability of your code. Having some sort of database abstraction (be it a simple ORM library or a standalone infrastructure component) is best practice for smaller sized applications as well as for applications running at scale. It ensures the application server can talk to your database(s) in a secure and performant way.
Prisma is an auto-generated DAL following the same principles as industry-leading DALs (such as Twitter's Strato or Facebook's TAO) while still being accessible for smaller applications.
Prisma lets you start your project with a clean architecture from the beginning and saves you from writing the boilerplate that is otherwise required to glue together database and application server.
Despite being a fairly new technology, GraphQL sees a tremendous adoption. Many small and big companies are using it in production today and there's good reasons to assume adoption will further increase in the future.
As mentioned above, Prisma's main use case is building GraphQ servers. The process of developing a GraphQL server commonly follows the model of schema-driven development where a new API feature is first defined in the GraphQL schema and then implemented using resolver functions.
Using Prisma as the data access layer and GraphQL bindings that connect to Prisma, resolver implementation becomes straightforward.
To get advanced API features such as cursor-based/Relay pagination, powerful filters or sorting mechanisms you can simply piggyback on Prisma's GraphQL API instead of implementing them from scratch.
When working with Prisma, you'll usually work with multiple GraphQL APIs across your stack, each having a different responsibility (e.g. Application server, DAL, ...).
Prisma's auto-generated CRUD/realtime GraphQL API is the foundation for your application server. In the application server, Prisma's generic CRUD operations are re-exposed via GraphQL bindings and transformed into a domain-specific GraphQL API (with a custom schema) which is exposed to your client applications.
Another common approach is to use Prisma for developing "GraphQL microservices" with a GraphQL gateway layer on top, combining the underlying microservices (using GraphQL schema stitching).
Prisma is extremely flexible and can be used with almost any architecture. Here are some sample architectures demonstrating how Prisma fits into your stack.
This architecture is very common to start out with. It's often used for small- and medium-sized applications where you don't need to split up your data across several databases or use multiple services.
In this setup, the Prisma service provides the interface to the database (the data access layer). Its GraphQL API is consumed by the GraphQL application server which tailors the generic CRUD operations to the clients' needs.
When an application grows, it often makes sense to create separate "microservices" with distinct responsibilities. For example in a webshop application, one service could be responsible for user management, another could be responsible for payment and shipping, another one for storing products.
Creating multiple microservices (each backed by one Prisma service) with clear responsibilities improves the modularity of your codebase. It also makes it easier to work in bigger organizations as each team can develop and maintain their own microservice(s).
In the rare cases where your app doesn't require any authentication, authorization or other business logic on the server-side, this architecture might be appropriate for you. Exposing Prisma directly to your clients means that these are now effectively talking directly to your database (through Prisma's GraphQL abstraction).
Here's a few use cases where this architecture works: