Schemas Everywhere: Understanding GraphQL, Databases & Prisma

Rate this content

In a world run by data, we as developers have turned to schemas to help describe and organize that data. But what happens when you have a ton of schemas to keep track of? In this talk you will learn the role of all the different schemas in a GraphQL API.

9 min
08 Dec, 2022


Sign in or register to post your comment.

AI Generated Video Summary

Welcome to the talk! As developers, we manage and understand the data that the world runs on. Each individual schema in your infrastructure defines your data in the context of its own domain. The Prisma schema is used to generate migrations and create a mapping between the database and API, enabling type-safe interactions. The GraphQL schema allows clients to safely query the database via the API. By using Prisma and GraphQL Code Generator, you can achieve an end-to-end type-safe environment.

1. Introduction to Data Management and Modeling

Short description:

Welcome to the talk! As developers, we manage and understand the data that the world runs on. Data modeling can be challenging, especially when dealing with data from various sources. Schemas provide a way to represent data models, but the proliferation of schemas has led to the question of the source of truth.

Welcome, everybody. Thank you so much for joining me for this talk. I am very excited to be giving this in a lightning talk format. I've given the same talk before in a full length format and I've condensed it down into just the necessary pieces. So, looking forward to see how this will go. If you have any questions about the talk after I've given it, feel free to shoot me a message on Twitter and I'll be happy to answer any questions you might have.

But before we get into the meat and bones of this talk, let's talk about the bigger picture concept that the world itself runs on data, whether it's your cell phone, whether you're using Facebook, or maybe your refrigerator or whatever you have that's connected to the internet, everything runs on data and as developers, it's actually our job to manage this. So it's a heavy load to put on our shoulders, but that's what we signed up for when we became developers is to actually take this data, do something with it, and spit it out in a format that other pieces of software can use.

So the TLDR of all this is that in order to manage a set of data, you have to have some sort of knowledge about its structure and its purpose. You have to know why you're dealing with your data and why you're doing what you're doing in your application's code to your data. So to revise this original statement, not only is it our job to manage this data that the world runs on, but it's also our job to at least to some degree understand it.

And this is hard because in general, data is hard to model. As technical people, we have a lot going on. We're doing a lot of technical things. We're developing applications. We have a lot of this knowledge to keep in our heads. There's not a whole lot of room to understand the whole data domain of whatever industry you're working in at the time. So a couple of other reasons though why your data is hard to model, as your data flows through different areas of your application, you have to know how to interact with this data. So it needs to be modeled in a way that with different pieces of your application. Your data model may change as your application evolves. So as new requirements come up in your industry, you may have to evolve your model a bit and doing that in a way that's safe for your application can be difficult at times. Another one, and this is a big one, is that your data may not have been modeled by you. And I would also revise this to say that your data probably wasn't modeled by you. You're probably consuming data from someone else and using it within your own application.

So for all of these reasons, we as developers came up with this idea of schemas, which is a way to clearly and concisely represent your data model. But there's still a problem, even with schemas. Schemas are now everywhere, so we've solved this problem of being able to model out our data in a way that makes sense. But now that we found a good solution, we're using it everywhere, and the original intent for the schema is now lost. So what the schema is supposed to be is a source of truth for what your data looks like. But as you start adding different schemas everywhere, it begs the question, now what is the source of truth? So this causes the problem that you now have multiple perceived sources of truth, and each schema may describe your data a little bit differently, which is what probably causes the question, what is the source of truth? And also, each schema has a different role.

2. Data Management and Schema Definition

Short description:

Each individual schema in your infrastructure defines your data in the context of its own domain. We'll look at the database schema, which is written in a data description language. Prisma has its own language, the Prisma schema language, that allows for easier modeling of the database schema. The GraphQL schema is different from the database schema as it defines what the API exposes, not the data itself.

And if the data, if the schemas look similar, it's kind of hard to determine what the role is of each individual schema. So to put this shortly, each individual schema in your infrastructure defines your data in the context of its own domain. So whether it's your database, your API, or something else, the schema is describing the data for that individual piece of your application.

So we're going to look at a stack that has a database graph QL API and Prisma thrown in there as well. So that we can look at the individual schemas and how they relate.

So to start off, we'll look at the database schema, which you see on the right is the code that you would need to write to create a basic database schema. This is written in DDL or a data description language. And it's typically a database specific language here. So this is a little bit complicated. These languages tend to be a little bit harder to learn than something like, um, something like JavaScript or something a little bit easier to look at on the eyes.

And for this reason, we at Prisma created our own language here called the Prisma schema language. And this allows you to model out your database schema within a Prisma schema file. The only difference is that it's written in this language that's a little bit more like graph QL. That's a little bit easier to read. This is important here because now as new developers come into your application, or maybe someone who's non-technical come in, they can actually look at this model and sort of see what's going on. This is also important because it's in a simple enough model that we can actually use this within Prisma to generate a type safe Prisma client that interacts with your database in a way that's safe and ensures that the data you're accessing is actually available.

And then finally we have the graph QL schema here. So this looks similar to the Prisma schema. However, there is a big difference. This is where a lot of people end up getting confused with schemas. The graph QL schema tends to look very similar to your database schema because it's exposing data from your database. But the problem here is that it should probably not look exactly like your database schema. This isn't defining your data here. This is defining what your API exposes. So, for example to elaborate on this, you may be exposing data from your graph QL API that's not even in your database. Or you may be not exposing certain fields from your database for security reasons. And because of these things your graph QL schema is a completely separate thing from your database schema. It may feel a little bit like code duplication as you're actually writing them. But if you understand this difference between the two different schemas here, it starts to make a little bit more sense. So, just to recap, we've got our database schema which is the schema running on your database server that defines your data shape.

3. Prisma and GraphQL Schema Mapping

Short description:

The Prisma schema is used to generate migrations and create a mapping between the database and API, enabling type-safe interactions. The GraphQL schema allows clients to safely query the database via the API. By filling the gaps with tools like Prisma and GraphQL Code Generator, front-end types can be generated based on the GraphQL schema. When all schemas and tools are used properly, you achieve an end-to-end type-safe environment. Thank you for joining me today to discuss the differences between schemas. If you have any further questions, feel free to reach out to me on Twitter.

You have the Prisma schema which will live in your API and your API's code. And this is actually what is used to generate the migrations to update your database schema. And it's also what's used to sort of create that mapping and to fill in the gap between the database and the API so that you can have nice type-safe interactions between the two.

And then finally you have the GraphQL schema which is what the client uses to safely query your database via your API. But there is another gap there. So, right here on this slide I've got the gaps, and if we fill those in, what we get is Prisma in-between the database and the API, as I mentioned, and you also get something like GraphQL Code Generator, or maybe another tool out there that does something similar. And what this does is it generates types for your front-end client based off of your GraphQL schema.

So, when you have all these pieces in place, all these schemas used properly, with these nice tools in-between them, you get a nice end-to-end type-safe sort of situation and environment, where your types, even from your client, are based off of your database types. So, thank you so much for joining me today to talk about the differences between all of the different schemas that you might work with in your application. I hope you cleared some of those little things up about the different schemas that often confuse people. If you still have any questions though, feel free to shoot me a message on Twitter about them, I'd be happy to answer.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!

Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.
For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.

GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Rock Solid React and GraphQL Apps for People in a Hurry
In this talk, we'll look at some of the modern options for building a full-stack React and GraphQL app with strong conventions and how this can be of enormous benefit to you and your team. We'll focus specifically on RedwoodJS, a full stack React framework that is often called 'Ruby on Rails for React'.
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.
Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q

React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
installed on your machine (12.2.X / 14.X)
- It is recommended (but not required) to use
VS Code
for the practical tasks
- An IDE installed (VSCode recommended)
- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contents
Part 1 - Hour 1
      a. Relational Database Data Modeling
      b. Comparing Relational and NoSQL Databases
      c. GraphQL with the Database in mind
Part 2 - Hour 2
      a. Designing Relational Data Models
      b. Relationship, Building MultijoinsTables
      c. GraphQL
Relational Data Modeling Query Complexities
      a. Data modeling tool. The trainer will be using
      b. Postgres, albeit no need to install this locally, as I'll be using a
Postgres Dicker image
, from
Docker Hub
for all examples
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.
In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.
By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.