Schemas Everywhere: Understanding GraphQL, Databases & Prisma

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 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 works 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 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. And 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, a graphql 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. What 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 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 graphql, 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 will 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 graphql 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 graphql 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 graphql 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 graphql 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. 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 we get prisma in between the database and the api, as I mentioned. And you also get something like graphql code generator or maybe another tool 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 it 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. So thank you again, and I hope you have a good rest of your conference.