Ep. 109 Prisma and MongoDB - Better Together

Nikolas Burk: Prisma is an ORM and now with MongoDB support, it's also an ODM. And we'll talk a little bit about these terms, but before confusing everybody with abbreviations, what Prisma actually does it makes it easier for developers to work with databases. And in the past, we used to do that by supporting mostly relational databases. MySQL, Postures, and SQL server Sq Lite are the ones that we are supporting there. And now we are also broadening our support and support MongoDB as the first document database and non relational database with Prisma.

Mike Lynn: It's Nikolas Burk from the Prisma team. He's here along with Matt Miller, from the, also from the Prisma team. And they're here to tell us all about the amazing work that Prisma and MongoDB are doing together. Some great stuff going on there. Stay tuned for that.

Mike Lynn: This is The MongoDB Podcast. My name is Michael Lynn. I want to tell you about MongoDB world that's coming up. June is right around the corner. June 7th through the ninth MongoDB world is back in New York city. You can get tickets right now. You can register at mongodb. com/ world- 2022. If you use the code podcast, you're going to get 25% off of those tickets as well as some podcast swag. So make sure you head on over to mongodb.com/world- 2022. Use that code podcast.

Mike Lynn: Well, welcome to the show, everybody. Nikolas Burk and Matthew Miller. Welcome from the Prisma team. It's great to have you on the podcast.

All right, Mike. So my name is Nikolas Burk. I work as a developer advocate at Prisma. I've been with the company actually for more than five years. People who have been following us since then know that we actually started out as a different company called Graph cool. But it's been a wild and bumpy ride over these five years and I'm pretty happy where we are now. And yeah, I'm here today with my colleague, Matt Miller.

Mike Lynn: Hey Matt. Welcome to the show.

Matthew Miller: Thanks Nico. Thanks Mike. Yeah, My name's Matt. I work as a product manager for the Prisma client and for about the year, last year and a half, we've been working on the MongoDB connection. So we're super excited to be here. I've been with Prisma for three years now and it's been quite a ride.

Mike Lynn: It's really great to welcome you to the show. And I want to start, we had an episode, I think it was episode 60 with Daniel, from your team. And we talked about Prisma-

Nikolas Burk: Episode 80, I think.

Mike Lynn: Oh episode 80. Thank you. Yeah. Where we talked about a little bit about the basics of Prisma, but for the listeners that may not be familiar, Nico, maybe introduce us to what Prisma is and why it might be so, so interesting to developers.

Nikolas Burk: All right. Prisma is an ORM and now with MongoDB support, it's also an ODM. And we'll talk a little bit about these terms, but before confusing everybody with abbreviations, what Prisma actually does, it makes it easier for developers to work with databases. And in the past, we used to do that by supporting mostly relational databases. MySQL, Postures and SQL server Sq Lite are the ones that we are supporting there. And now we are also broadening our support and support MongoDB and the first document database and non relational database with Prisma. Being an ORM means that we basically provide an abstraction for developers that they don't have to write plain SQL themselves when they're working with relational databases, but instead they get an object oriented abstraction on top of that. With the ODM, instead of mapping from relational data into object oriented data, as it's the case with relational databases. Now with MongoDB, which is a document database, we're mapping from document structures into JavaScript objects using the Prisma database toolkit. So to say.

Mike Lynn: Great. So, I mean, I guess the overall goal here is to make it simpler for developers to write code and to abstract the data layer. Right?

Nikolas Burk: Exactly. And with Prisma, you also get a couple of nice additional benefits on that data layer that it's adding on top of MongoDB. For example, type safety auto completion are a couple of ones that we'll probably talk about in a bit more detail later on, but yeah, in essence, it's exactly what you said, Mike, to make it easier for developers and really like give them more confidence when they're working with databases. Because oftentimes the database feels like this intimidating component in your backend up architecture that you somehow need to get under control. And oftentimes it helps if you have some extra tooling around that.

Mike Lynn: Well, if I think about the life cycle of an application, you know, I've developed a few applications in my time and I start thinking about the data right around the same time I start thinking about the business logic and maybe I start noodling with some code. Maybe then I go in and I, you know, lately I work with MongoDB exclusively. I open a session in an editor and I start coding out the JSON structures for the data that I, that I'd like to manipulate in my code. And in that life cycle, in that kind of process, I'm starting to understand the data better. And I start looking at the types of data I'm going to have. And then, and then I might actually go in and create some, some MongoDB documents as the basis. Now, how will my workflow differ if I'm leveraging Prisma?

Nikolas Burk: That's a really good question. And I really like the point that you made there that before you sit down and actually start writing code for your application, you actually think about the data structures, right? You kind of want to see, have it visualized in some way, what the data that's going to end up being stored inside of your database actually looks like and you do this now by creating some sample objects. Basically where you don't actually care so much about the values that you're storing in these objects at that point in time, because you really only want to see the structure of these objects. So at this point, I would say that what you're basically doing is you're modeling data. You want to see what the data structures that you'll end up using in your application look like, but the approach that you took for it seems a little bit over complicated to me because you are now sitting down and you're writing out entire JSON objects. You have to think of placeholder values that you can use for these examples, but it really is not ideal. I think because just the way how you write the structure is probably a little bit verbose and also doesn't adhere to any kind of extra, extra benefits that inaudible you would get. With Prisma the way how it would work actually is that you would define a schema. So like Prisma has this main component that's at the start of all of your Prisma projects, that's called the Prisma schema. And that's where you model the data that you're going to store inside of your database. You can compare it a little bit with Mongoose, for example, I don't know if you've used Mongoose in the past, but that's also another tool that helps to add this schema layer to your database. And Prisma in that sense is very similar, it also enables you to add a schema and really make it explicit. What kind of data structures you're going to store inside of MongoDB. But the way how you create the schema is different in Prisma, because we don't use the JavaScript API that's used by Mongoose, but instead we have a dedicated schema language and a. Prisma file that you put into your project then holds the entire data model of your application.

Mike Lynn: So when I create this. Prisma file, what is in that exactly? Is it JavaScript? Is it type script?

Nikolas Burk: That's our own domain specific modeling language for data. It was heavily inspired by Graph Ql SDL. So if any of your listeners have used Graph Ql before, and they've seen the notations for defining data structures with Graph Ql, then they'll have a very easy time picking up Prisma actually, because it's very heavily inspired and like maybe even a little bit cleaner. I think we like made a couple of design choices with the Prisma schema language that make it a little bit more different compared to Graph Ql SDL. And Matt, I don't know, you were heavily involved also, I think with the design and the creation of the Prisma schema language. Is there anything that you would add to that?

Matthew Miller: Yeah, so I think one of the differences that's kind of unique to just databases is with Graph Ql, the Graph Ql schema optional is the default, and you have to kind of add an exclamation points to make it required in Graph Ql. With Prisma, we kind of made the decision that like for the database specifically, you want it to be kind of the opposite. You want it to be required by default and then optional it with a question mark after the fact. So one thing I will add is you don't need to necessarily write the schema totally by hand. Like you don't need to learn a completely new language. Like we have this inaudible code plugin that really helps you kind of model it and it provides auto complete for you. It will correct errors that you have. It will even kind of auto complete relationships and stuff like that. So it kind of helps you along with, with your modeling. And I think it's a kind of an indispensable tool for modeling data.

Nikolas Burk: True. And it's actually funny that we oftentimes hear that developers are repelled by the Prisma schema because it's indeed that kind of reaction that they now have to learn a new language just to use this tool. And they are like, not really inclined to do that. But the funny thing is that exactly these people that initially are repelled and then once they get their hands on the Prisma scheme might actually have that kind of experience inside of vs code. They often turn out to be our biggest proponents in the end and our biggest advocates. So I've had a couple of these interactions on, on Twitter and even on Reddit, where people always came with that argument. And I told them," Okay, if you don't like it, that's fine, but at least give it a try, at least try out what it feels like to model your data that way. And then you can make a judgment call." And yeah, oftentimes these people came back and told me," Okay, you're right. This is actually a really nice experience and are adopting Prisma."

Mike Lynn: Hmm. It's great to kind to drop that. So if you're listening to this and you're, you're curious about it, where do, where do folks go to get more information?

Nikolas Burk: So we have a GitHub repository. So Prisma is entirely open source. So you can just go to the main Prisma repository. Of course, we also have a website @ prisma. io and the documentation where we have a quick art that hasn't been updated for MongoDB yet though. I think that just uses Sq Lite, but we do have proper getting started guides that explain how to get started with Prisma MongoDB from scratch. And also how you can use Prisma in an existing application that already uses MongoDB and even has some data stored inside of MongoDB already. And if you're in that situation, actually, it's pretty easy to get started with Prisma then, because Prisma has what it's called an introspection feature. And with that feature, you get started, you run a Prisma CLI command and Prisma then scans the structures of the documents inside of your collections. And it will kind of derive the actual Prisma models from that. So if you already have this existing MongoDB database, you just want to feel what it actually is like to work with Prisma in some capacity, there is a very kind of low effort way how you can just start playing around, just introspect your database. Then in the next step, you will kind of generate Prisma client, which is the, like the database client that Prisma provides. We can talk a little bit more about this as well and how it works, and then you can already start querying your application. So it's really just a pretty straightforward process from, to just like having your existing MongoDB database to actually then querying it with Prisma.

Mike Lynn: I mean, it sounds really easy to get started. I love the concept of an introspection capability. I love that but it does call out a feature of MongoDB. And I'm curious, let's say we have a collection of documents and from document to document in a single collection, MongoDB supports a flexible schema, meaning that you can have a different shape of document in one document compared to the shape of the document in the next, how does the introspection capability handle that?

Matthew Miller: Yeah, so that is like a feature. And I would maybe argue a little bit of a bug as you get a little larger. So it's a feature because you can kind of, you know, you're a super flexible database for kind of getting started, throwing some code in there. But as you kind of become a larger team, you really want to start like locking down what types of data are in your collection. So you're not kind of surprised and you've got a consistent way, like you know how to display this data in a consistent way. For the introspection it does like a bit of a trade off. So, first of all, it samples your database. It's not going to run through if you've got a 20 gigabyte database, it's not going to try to like figure out all the types of that. So I think it samples the first thousand rows and kind of tries to drive types from that if the types conflict, it will default to a JSON type. And so a JSON type could be a number, it could be a string, it could be an object, it could be an array. And the only thing that really changes is the kind of operations you can perform on it. So if we know that it's a string, when you query it, we've got like operations, like begins with or contains and stuff like that with the string. But if we, if it's adjacent, we just know like, is it equals or is it not equals like, so we are a little bit more limited in what we can provide, but it's kind of a nice fallback for these cases where we weren't able to figure out like, or there was inconsistencies in the data. And our kind of hope or maybe expectation is that over time, like you introspect, maybe you've got a couple of these inconsistencies and then over time you realize," Oh, I kind of, I kind of want this, these more rich operations is better type safety. So I'm going to kind of migrate my data incrementally to be more consistent and then kind of, not necessarily re- introspect, but kind of update the schema to, and generate a client that has more capabilities.

Mike Lynn: Well, when I think about modeling data and MongoDB specifically, well actually, I mean, modeling data in general, there are a couple of key things that jump out. Modeling data for a single document is super simple, right? You're just going to lay out your types of data and the structures. You're going to make some decisions about embedding versus linking with MongoDB. And that makes me think about modeling relationships between data elements. So there's some basic types like one to one, pretty easy, one to many, a little bit more difficult, many to many is even more difficult. Tell me how you begin to look at modeling those types of relationships using Prisma.

Mike Lynn: Maybe I can start and then I'll like defer to you Matt for the more in- depth stuff. But on a high level, at like Prisma, in the Prisma schema, you can define all of these different types of relations that you mentioned. So one to one relations, one to many relations and also many to many relations. And in relational databases Prisma will basically figure out under the hood what the right approach is for these. So in a relational database, if you want to have a one to many relation, then you'll just set a foreign key on one side. And in MongoDB you now have more choices when you want to model your relations, because you cannot only define your relations based on these references, but also using embedded documents, which is a whole other kind of category of relations where you physically store the data alongside the like document that it like contains, right? So a typical example of this is like an address that you want to store right alongside a user document instead of like referencing it into another collection. And I think for that, you have to make these kinds of choices in the first place. You have to be aware of that when you're modeling your data, but then like Prisma does support all of these different relationship types that you can do natively with MongoDB. And you can then kind of like model them in the Prisma schema with the right primitives. So for example, for lists, if you have a one to many relation, we just have this typical kind of square bracket array notation to indicate that something is a list. That's how you would declare a one to many relation in the schema using this notation. Yeah. Like I don't know, Matt, is there anything about relations that you think is worth adding here?

Mike Lynn: Yeah, one thing I would say is, so when we talked about introspection, we're able to pick up embedded documents. So when we scan, we realize," Oh, this is a nested object or a nested array. And we're able to kind of pick up the types from that." One thing we aren't able to do is actually infer the relationships. So if I've got a user and I've got posts, like what is the relationship between them? So to set up those relationships, you actually need to go in and kind of write, set up that relationship by hand in the Prisma schema. We'd love for a way to kind of be able to infer from MongoDB, the database itself, that there is a relationship here. We're looking into like some heuristics we can maybe apply, but it's not, nothing's concrete just due to the flexibility of what MongoDB provides in terms of relationships.

Mike Lynn: So, okay. So that seems pretty straightforward modeling relationships and leveraging the additional choices you get with MongoDB. What about additional benefits of Prisma? Now you mentioned all of those relational databases that you support, some other non- relational, or document databases. Talk about the benefits of Prisma as a layer that supports multiple databases. Do you find people using it in that way for a single doc for a single application?

Nikolas Burk: That's actually a really interesting point that you're making there Mike. And one that we've also discussed internally quite a bit, because it's indeed the case that with many object relational mappers, you have the case that they kind of abstract over SQL entirely, and then you can use it for any kind of SQL database and like, don't have to be aware of the specifics anymore. However, this is actually something that we decided not to optimize Prisma for in the end, because it was something that didn't struck us as an important enough use case to say that," Okay, in my application, I'm starting out with my SQL, but later on, I'm going to migrate over to Postures." And that's why it's important for us to build a layer on top. That's compatible with all of the and databases. Instead, what we do is we really want to try and leverage the strength and the individual capabilities of each underlying database by pointing out its individual features. So as an example, Sq Lite won't support enium types, for example, but like Postures does. So in a Prisma schema where you're using an enium type and you're suddenly switching your data source from Postures to Sq Lite, Prisma will give you an error because there is nothing that it can map these enium types to inside of Sq Lite. Yeah. Like that's one example. I think, where we kind of made that decision and actually found that even though people kind call it out as an interesting use case, to be very, or to like very easily switch between databases, that's not something that struck us as a really important use case that we should optimize for. And yeah, we had a long internal conversation about that Matt. You were also part of that convo, I think.

Mike Lynn: Yeah. I would just like to add the analogy that I like to use is kind of this learn once apply anywhere sort of thing. So it's not right once apply anywhere. It's more like it's similar to what react and react native do. Like, it's not like you can just write your application and boom, it's on like an iOS app and it's on the web. You do need to make some modifications, but the concepts' kind of carry over between the databases. And so yes, you cannot switch your database provider from Sq Lite to MongoDB and expect no changes to need to be made, but the same concepts apply. So that kind of transition wouldn't take like it's instead of maybe months or weeks, like it would take days to kind of make that transition.

Mike Lynn: Yeah, that makes sense. So what other benefits have we not talked about in terms of leveraging Prisma over another ORM or ODM? I mean, we pretty much covered not using an ORM and ODM versus using Prisma. Are there benefits over other ODMs and OMS?

Mike Lynn: So I think that one big benefit is just the way how you model your data and that the experience that comes along with it. I think that is one big benefit. And that also is one that certainly gets called out repeatedly by our community who say that this way of modeling their data just makes it really easy. And also if they're working on a team, it just makes the data structures that are inside the database really explicit to everybody. So onboarding new engineers becomes easier and overall there is less communication needed because everybody can just take a look at the schema and kind of understand what the data looks like. But one step further, actually I've mentioned this before that Prisma also provides you with this database client called Prisma client. And the special thing about Prisma client actually is that it's, auto generated based on your Prisma schema. So what actually happens is that Prisma looks at the Prisma schema and then it reads all of your models that you have there. Maybe you have a user, maybe you have a post model, a comment and a profile, all of these different models. And then Prisma is going to generate a database client typically into your node modules, but you can configure where you want to have it located and then you can import it from there, instantiate it, and then can use this Prisma client to query your database. And the big difference compared to, for example, the native MongoDB client here is that Prisma and Prisma client specifically will be aware of the schema that you have defined. That has the big advantage that it can generate the right Type Script types for you that are needed to make sure you can send the right queries. And these types of types, even though you might not be using type inside of your application, but the types they are still available, they're still there. And they then help to provide things like auto completion inside of your editor. So that auto completion holds when you don't know what kind of query you want to send to the database. And now you would actually have to go and look up the reference documentation for a specific query. You might have to search through the documentation to find the right argument that you want to provide for the filter. For example, if you want to filter strings or dates or integers with ranges, whatever you want to for filter for typically have to go and have to like find the right filter in the documentation first. With Prisma, all you do really is hit control space in your editor to bring up the auto completion and then select what you need. So you're getting a lot more productive because you save this context, switch from your editor, back into the documentation. Everything is now right there at your fingertips inside of your editor, where you can explore it.

Mike Lynn: I love this and it really speaks to developer efficiency. And I was going to ask you about, for folks that are not familiar with type script and with type safety; I was going to ask you to go into a little bit of like why they should be thinking about this, but you really talked about it. It comes down to developer efficiency and really helping you in the process of writing code. Not only in like syntax, but actually as it relates to your data. When you have type safety, when you're leveraging type script, I'll ask you to talk about that. When you're leveraging type script and type safety, what are the benefits to the developer specifically as it relates beyond syntax but to the data?

Nikolas Burk: Right, in my mind, it really like comes down to the confidence that you can have into your application and that the data that you're storing in there, you can kind of trust that it has a certain shape. If that weren't the case and if you didn't have this kind of trust would basically mean that you inside of your application, you would always have to include these IF statements where you check," Does this object now really have this property.?" And if not, then I have to take a different code path or even throw an error because I need to expect this kind of like property on this object here. So I think that this is in general, just one big benefit of Type Script, that it just validates the structure of the data that's flowing through your application. And it does that already at compile time. So it also tightens the feedback loop between you, the developer writing code, potentially making an error, but with Type Script, this era is already caught before you even start the application and go into your, like into the demo feature that you're currently building and test it out where with plain JavaScript. Only Then you would see the runtime era. But with Type Script, you see the era already ahead of time because the types of compiler won't even let you get to the point where you can run the application.

Mike Lynn: Great. Well, I appreciate that overview. I do want to touch on the work that has been completed. The MongoDB Prisma relationship has been solidified. It went through a beta phase. It's now production ready? Is that correct?

Mike Lynn: Yes, it is now production ready at the time where this is going on air. This should be during the Prisma MongoDB launch week where we have a lot of fun activities planned with you with the MongoDB team, with a lot of people from our community. So this is super exciting to us and yeah, it took a long, long time. I mean, we started working on MongoDB like, I don't know when we started working on it very seriously, but at least like one and a half years ago, I would say. And then last summer it entered preview stage. But even at that point it meant a lot more about this than I do, but at this point there was a lot more work to be done yet. So now pretty much a year later after the preview release, or three quarter of a year later, is where we are finally releasing it for production.

Mike Lynn: Yeah. All of the features we've been talking about have happened since summer, basically like our first iteration was just make it look kind of like a SQL database. We didn't have embedded documents support, which is like MongoDB shining feature. We didn't have it. We didn't have introspection, so you couldn't get started easily. We didn't have raw query support. So where places where like the MongoDB database supports something that we don't quite yet support, we didn't have a way for users to build, to kind of upgrade to Prisma after the fact now we've got raw querying capabilities. So if you do need that kind of extra complex aggregation pipeline thing that we don't quite yet support, you can still do it with, with Prisma and all of that came. Yeah. All of that came recently.

Mike Lynn: So, so Matt, what's, what's your background? How did you get involved in the work you're doing at Prisma?

Matthew Miller: Yeah, I can, I can talk about that. It's a bit of a long story, but I'll, I'll try to keep it concise. So I was working on a similar kind of tooling in actually the Go language. And I was working on basically introspecting Postures databases and just generating a like custom tailored database clients. So the main thing for me was wanting to, as you made changes to your database, you migrated your database, you'd regenerate the client and then you kind of have... It's this confidence that Nico was talking about. Like say I removed a field in the database as soon as I regenerate my client, like I would get red squiggly lines in my editor. And then I would kind of know," Oh, I actually made a mistake here. I need to like change this again, or I need to refactor the application." So it's just, as you're making, adding features and changing things, it's just gives you a lot of confidence. And so I was working on a Go client, very similar to what Prisma was doing. And I learned kind of what Prisma had just transitioned more away from like graph Graph Ql focused applications, more to kind of like a lower level database, client generations and database tooling. And they were kind of working on the same thing. So I hopped on board at that time.

Mike Lynn: And Nikolas, what's your background? How did you end up at Prisma?

Nikolas Burk: That's also a little bit of a long story. I mentioned at the beginning, I've been in here for more than five years by now. And before that I actually was a mobile developer doing mostly Swift and like working on the Apple platforms and-

Mike Lynn: So core data.

Nikolas Burk: ...Yeah, exactly core data was kind of the first local database that I have been exposed to and kind of the Apple based object, relational member, I guess. And I always been very excited about not only writing code, but also about talking about code. So very early, I kind of got into developer communities, conferences and all that stuff. So like I always was on that path of becoming an educator as well, because I also enjoyed like teaching so much. And back then, like five and a half years ago, I've met with a friend of mine who used to work at a company that was called Graph cool back then. He introduced me to the entire team. I was just having a nice lunch with all of them. And then next day they called me and asked me if I wanted to do a trial week with them, which I did. I ended up staying there. And that company then turned into Prisma with a big rebranding that we did, I think three or four years ago.

Mike Lynn: That's a great start. So is there anything else we need to let the listeners know about Prisma, about Prisma and MongoDB together? What are we missing?

Mike Lynn: So I think one thing that we can talk about is also that like Prisma, when you use it to model the data inside of your MongoDB it actually also makes the process or some parts of the processes of kind of like migrating some of the data that you have inside of your MongoDB database, or just like putting certain structures into place also makes that easier. For example, what Prisma will do when you add a default value to a field on a Prisma model that maps to a collection in the underlying MongoDB database that Prisma can backfill the default values for all existing documents inside of that collection. So it will make sure that if you've set this default value. And like, for example, it's a inaudible field and you want to have all new records to like this field to be initialized with faults. Then Prisma can actually also do that for the old documents that you have already inside of your collection and the same for index management. So in MongoDB, I think you can define indexes that apply on certain fields in your MongoDB documents as well. And with Prisma, you can also define these indexes on your Prisma models. And then again, just apply these changes from your Prisma schema against your MongoDB database. The command that you're using for that is called Prismatoid push. You're just pushing all of the changes from your Prisma schema into the database and that's where they're going to be applied. And I think these little details also about just in general, having a bit more control and visibility into the structures inside of your MongoDB database also make a big difference and they really add up in the end when you're using Prisma.

Mike Lynn: Yeah. Reminds me of like the migration operation. When you make changes to your schema, similar to the way that some of the PHP frameworks work, you make changes to the schema definitions in your PHP, and then you want to migrate.

Mike Lynn: Exactly. And in fact, for relational databases, we have the same concept of database migrations. But because with MongoDB, you don't have this inherent schema that you even have to manage and that you have diversion. The concept of migrations doesn't really apply in the exact same way. So the tool that we have for that is called Prisma migrate. And Prisma migrate itself, it's not really relevant when you're working with MongoDB, but you still can apply these schema changes. It just works slightly different, slightly differently than you might be used to from working with relational databases.

Well, I want to thank both of you for spending some time with me talking about Prisma. I want to remind folks that they can go to prisma. io to find more information about the Prisma ODM, ORM. And Nikolas, where can folks find you on line?

All right. So you can find me on Twitter and on GitHub. My handle is Nikolas Burk. That's Nikolas with a K and Burk, also with a K. And that's how you can find me online.

Mike Lynn: Okay. Fantastic. Matt, are you, are you in the socials?

Matthew Miller: I am. Yeah. I'm on Twitter @ Matt Mueller, M U E L L E R.

Mike Lynn: Well, I'm going to link all of this in the show notes. So if you're, if you're curious and you want to reach out to these folks, you can find their socials in the show notes. Make sure you check those. Thanks everybody. Have an awesome day.

Matthew Miller: Thanks a lot, Mike.

Nikolas Burk: Thanks so much for having us, Mike.

Thanks so much to Nikolas and to Matt for joining us today. Thanks to you, the listeners for listening on Apple podcast. We'd love to hear from you. Leave a comment, feedback rating. Let me know what you think of the show. That'll help me improve. Thank you. Make sure you check out mongodb. com/ world- 2022. MongoDB world is coming to New York City, June 7th through the ninth. It's an amazing conference for developers by developers. Use the code podcast when you register to receive 25% off the ticket price and some free podcast swag. Hope to see you there. Thanks everybody.