Episode 55 - Free
Sabin: [00:00:00] with Prisma, it's all in one place. So within one single repository, you can define that data model. You can generate those types, and you don't have to change things in multiple, like disparate areas just to get nice type safety.
Andrew: Hey, before we get started, I'd like to remind you that the full episode is only available to our paid subscribers. The current platforms you can subscribe to us on our Patrion, Spotify, and apple podcasts.
In the full version of this episode, we talk about savings opinions on NN type safety Prisma studio. And of course, all of our tool tips.
And with that, let's get onto the episode.
Andrew: Hello, welcome to the Dev Tools FM podcast. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host, Justin.
Justin: Hey everyone. Uh, today our guest is Sabin Adams. Uh, Sabin is a developer advocate at Prisma, and we're really, really excited to have you on Saban. Uh, but before [00:01:00] we dive into our questions, would you like to tell our audience a little bit about yourself?
[00:01:04] Sabin's Background
Sabin: Yeah, for sure. Like, like you said, I'm Sabin Adams, uh, I've been a developer advocate at Prisma for just over a year now, a year and a couple months. Um, it's been great. It's been awesome to dive into the community, um, and just sort of see what's going on in, in the space. When you're working in like an engineering team, it's hard to get that wide view, but it's, it's really cool to be able to see what's going on everywhere right now.
So I'm excited to be on here with you guys.
Andrew: Awesome. So, uh, you haven't always been a developer advocate. Uh, how did you get into first engineering and then what, like prompted your transition into Del Developer advocacy?
Sabin: Yeah, so I actually, I actually grew up, uh, developing software with my dad. Uh, he, he was a developer since I was little, and we kind of grew up making little games together. Um, and then, yeah, I ended up going to college for marine biology actually, and halfway through I decided like, what am I doing? I like, I like coding.
So, uh, ended up leaving college actually, and have [00:02:00] worked in various positions doing front end backend, full stack development, um, uh, DevOps. So I've kind of been all over the place. Um, and then, you know, after around, I think it was around nine years, like nine to 10 years of that, um, I started to realize that, um, a lot of what I liked doing was going into teams, documenting sort of their processes.
Teaching, you know, newer technologies to the team members to help push the companies forward and realize dev advocacy was sort of the, a great transition to do more of that. Um, that way I could do sort of some of my more creative stuff, uh, as well as the more technical, you know, coding and all that.
Justin: Yeah. That's awesome. I, I think finding that natural, sort of, that natural fit on any team is, is hopefully where we all go in our careers, is finding the thing that Yeah. Yeah. This, this like gives us a lot of energy.
Andrew: that's cool how like your, you and your dad like got into coding. Like that is, that is awesome. Like, I was literally thinking just the other [00:03:00] day, like, my future children, like if I taught them coding and told them to go to college, would I tell them to go to college for coding?
And my, my, my gut reaction would be no. And I think you kind of had the same gut reaction. Like what did you originally want to do with that degree and like, what was like the final, like I, I, I love coding. Let's just go all in on that.
Sabin: Yeah, well, I, uh, I, I like coral reefs and like anything having to do with coral reefs. So I was going from marine biology specifically to hopefully join a research lab, um, and just study sort of environmental effects on coral reefs. Um, and after going to, uh, one college for a while, for a couple semesters, and then I ended up switching to another one, um, the head of the marine biology department actually told me like, just so you know, you probably won't get a job at a lab because there's not a lot of demand for that.
You'll probably be a teacher. Um, and at that point, it, that was a little bit of a bummer, but I kept going, kept doing it, and [00:04:00] then I, I was doing a lot of software development on the side just for fun. Um, and I started getting full-time job offers that were. Already reaching, you know, pay levels that I wouldn't have gotten after years of working in marine biology.
So it was like, it was the kind of thing where it was like a, a hard choice. Like, do I follow this passion that I'm trying to like, or do I follow something I've done forever? Um, and just keep going with that. And so after, after talking to a couple people, I ended up deciding to go the software development route.
Andrew: It's a hard decision. I had a few friends in college who were like in the same boat of like, oh, I already know how to code. I could get a job at an entry level position already. They were even going for like computer science and they were like, what am I doing here? And they all eventually ended up dropping out too.
[00:04:44] Intro to Prisma
Andrew: So let's circle back to Prisma developer advocacy a little more. so what is Prisma and why would I wanna use it?
Sabin: yeah. So, um, Prismas a couple things and we're actually evolving recently, so that question gets a little trickier right now. [00:05:00] Um, in the past we've primarily been known as an ORM so, and that's our still our primary offering. We're an open source orm. Um, our goal is good developer experience as well as, uh, like complete type safety.
So what what we allow you to do is we allow you to, uh, define your, your database schema. We allow you to perform migrations, query your database, do any sort of operations against your database, as well as like raw queries. Um, and we've uh, specifically built this in a way to where any of those things you do result in a completely type, safe experience in a type script application.
Andrew: So how does that like, compare with like traditional things, like I'm creating a NoSQL database on Mongo. Like what's the workflow different? How, how is the workflow different?
Sabin: Uh, yeah, so the workflow is different because what this does is it sort of unifies your, um, the whole database setup where before, uh, with Mongo, I guess it's not so big a deal cuz there's no schema, but with like a traditional. Uh, relational database, you would have to sort of define your schema in the database.
[00:06:00] Uh, you would then, uh, you know, define your schema again in your application code using, um, um, some sort of type script language so that you can define what your schema looks like in the database. And then if there's changes to that schema, you'd have to also make those same changes to, um, the representation in your code, um, that was required to get that nice type safety.
Uh, previously in ORMs there were a few outliers who covered some, uh, some more detailed stuff that we're doing now. Uh, but for the most part, that was how you had to do it. Whereas with Prisma, uh, it's all in one place. So within one single repository, you can define that data model. You can generate those types, and you don't have to change things in multiple, like disparate areas just to get that experience.
Justin: Something I've always loved about Prisma is that the tooling is really, really good. The developer tooling, especially on around, so you sort of like define the, your, your schema and kind of a DSL kind of nod, I guess. Uh, and, and, and it's, it's, [00:07:00] I don't know, the, the tooling around that was always really excellent.
So I just have been wondering like, what is the culture for tooling inside the company? How do you think about like, I don't know what the developer experience is like, I mean, because type interface is really good and like, it seems like developer experiences is pretty key there. So what's the culture around DX inside of Prisma?
Sabin: it's taken to an extreme, I would say, um, to where that's the top of our mind in whatever we're doing. In fact, there's things that people are, It can go the other way too. It could be almost a negative thing. Sometimes there's things people want Prisma to support that we won't do yet because we're trying to figure out a way to do it with a good developer experience.
We won't just put something out there to get it working for people. We want it to be good. So, um, uh, a lot of the people that I work with come from backgrounds working in dev tooling. Um, if they weren't working in dev tooling, they were working on, um, tools within larger companies. So, um, it's, uh, it's something that everyone is [00:08:00] thinking about and everyone expects everyone else to be thinking about as well.
Justin: That's awesome.
[00:08:05] Powerful Schema
Andrew: So, uh, we've talked about the database schemers a little bit, but something that's interesting about Prisma is it doesn't just support one database type. So, uh, like. How does that work? Like what databases can I use and how is like this schema language, uh, influenced by that?
Sabin: Yeah. So, um, that, that's one of the cool parts of Prisma actually, is that for the most part, there are specific scenarios where this is not true, but there's the, for the most part, uh, the schema language isn't affected by that for, there's usually, uh, when you're setting up your schema, you get to define what sort of data based provider you're using.
Um, say you're using Postgres, for example, you can define your schema, and then oftentimes it's as easy as switching that provider key to MySQL or Mongo, uh, to switch to a different database. There's specific features of the individual databases that. Make that vary, [00:09:00] of course. So, um, our tooling will tell you when that happens.
Um, but yeah, for the most part it's pretty much the same. We support Mongo, uh, MySQL, Postgres, and there's other ones too. There's a whole long list of 'em, and I haven't memorized all of 'em, but most of the traditional re relational databases you're gonna work with.
Justin: That's really awesome. Uh, I mean, just touching back on the DSL for a second, the building ORM is hard and like anybody who's ever tried to do this or is like used ORMs, know that they can be kind of inconsistent, um, and sometimes gonna, it's hard to get them to do the exact thing you want or generate the exact sequel you want.
So, um, how do you, especially when you're thinking about multiple databases, how do you provide sort of like clarity and consistency in this? DSL is like, do y'all have like a, I don't know, some sort of, uh, like guidelines or rules that you govern about, like, here's, here's what we do when we add new features, or here's how we think about consistency [00:10:00] across databases and all that stuff.
Sabin: Yeah, yeah, yeah, definitely. We do. We, um, in fact, our engineering team is split up into a bunch of smaller engineering teams that have specific focuses, and we have an entire team of a couple of people that are completely focused on schema language changes. So if anything ever requires a change to that schema language, it goes through them.
They write a docs and specs on it. We verify that it won't break anything that exists already. Um, and, uh, the shape of that is something we very tightly govern. Um, Prisma, if you weren't aware, it comes very much from like a GraphQL background, and we try to treat the Prisma scheme of the same way. GraphQL schemes were treated before, where they were, um, a strict set of rules that you had to keep to, um, and you didn't really change unless it was absolutely necessary to add a new feature or something.
Andrew: So one thing I like about the schema, uh, stuff in Prisma. Is how automatic it is. Like the first time I used it, I was kind of blown away that, like, as I'm editing, [00:11:00] it's just like connecting all the models for me. Uh, have, have you run into like situations where that like, makes things harder, I guess?
Like do you feel, feel like that's a net good? Does it lead to discoverability or does it like, maybe even h hurt that at the start?
Sabin: Um, honestly, I think it, I, I've only seen it as a net good. I haven't found a scenario where someone sort of complained that,
you know, the tool under the hood was doing stuff for them. Um, there are specific, like really niche data requirements where you have to have specific joint tables, you have to have things working in a specific way.
Um, and even there, uh, you can still represent those in. You're a prisma schema. It just might be different than what we have in our docks, but there's almost always a way, uh, to set up your data how you need to.
[00:11:49] Prisma Accelerate
Justin: Yeah. That's really cool. Um, so not to jump too far ahead, but y'all are working on something new. Uh, it's advertised on the site. Uh, so [00:12:00] what is, uh, Prisma accelerate? Can you give us the scoop? Uh,
Sabin: Yeah. So Prisma accelerate. Um, uh, I guess just for some context, first, we have what we call prisma data proxy. Uh, and that's already out and available to use. And what this gives you is like, uh, connection pulling so that from a serverless or edge environment, you can connect through this as a proxy server, uh, to access traditional nons scaling relational databases from a serverless setting where you might scale to infinity. Um, what Accelerate does is it builds upon this, um, specifically for people, uh, working at the edge. Where, when you connect through accelerate and you run queries, you can define on a per query basis how you want that data to be cached. And not only is it cashed, but it's cla cashed globally, uh, on Cloudflare's, uh, worker network. So it gives you really, really quick sub 10 millisecond queries for the most part. Um, uh, I say for the most part because it's sometimes even significantly lower than 10 milliseconds. Um, [00:13:00] uh, on, on the Edge, which currently, uh, is mostly unheard of, um, in this way because what we consider this is a specialized cache where you're not just, uh, cashing everything that goes in and out of the, the query engine.
You're caching differently per query.
Justin: That's, that's really awesome. That reminds me. So I think Lenix Scale has a similar kind of feature that they, they, they did like a global Query optimizer. Um, and just while we're on the, the note, something that I've always wondered, and we ask a lot of dev tools, companies this, especially ones that do a lot of open source.
And when I think about Prisma, I think about sort of this rich open source history. Um, what is, how does Prisma position itself in the market to like, you know, be a profitable organization? Because it's like, these dev tools are all great, but you have to pay people's salary. So it's like, what do you kind of do to, to keep the lights on?
What are the, the product offerings there?
Sabin: Yeah. So, so far we've been mostly, uh, [00:14:00] funded. Uh, we have, uh, a really great, um, uh, board of investors who have like seen our vision and our, our vision of our products moving forward and, um, have trusted that we'll build those. And so that's been really great. Um, uh, the data platform that I just mentioned and accelerate are examples of paid products that are gonna be out. Um, and that's where we'll be, uh, starting to generate some income we already have because of those. And it's been really great. Um, we, the, we, we have a plan ahead of us to release, uh, a couple of different products. I, I, I'm struggling to find the words because they are fairly secret at this point, but we have
a couple of things coming out, um, that will be sort of our, our, our money makers, our, our more commercial offering.
And, uh, it's very exciting. There's a lot of cool stuff coming ahead.
Andrew: Yeah, I, I, I think that serverless offering is a great first step because we've had a bunch of serverless people on the past and I ask 'em like, oh, what do you use for your database? And it's like, oh God. [00:15:00] And then they start talking about fauna or something that's like this completely new database, and it's just like, ah, that's such a huge lift.
The fact that there's a way to easily do this now is such a boon. Like I personally have a website where I was like, okay, let's try Serverless. And then got to the end and was like, oh, no connections. Like I had to worry about this as a front end developer. I didn't even know it was a thing that there was a connection limit.
So like tools like this really help help developers with their every day.
Sabin: Yeah, for sure. And then it, it's something that not a lot of people think about, like you just said, where, um, if you're working on a brand new project, a greenfield project, sure it's fine to start with a, a new serverless database. But what if you're an existing company and you're wanting to, you know, push forward in the industry and move to serverless?
Um, if you have a traditional relational database, it's, it's not really, it's possible right now, but it's not gonna be very good. So it's, uh, yeah, it's a exciting stuff moving forward. There's a, there's a lot of room for, uh, [00:16:00] for development and there's a lot of room for, uh, expansion I guess, in this, in this part of the industry.
Justin: Yeah, it's pretty exciting. One of the things that I love about dev tools companies in general is because they focus so much on developer experience and they're generally focused on something like this, it's like, oh, well, we'll, we'll make it easy to query something. But then getting to like some of the hard parts are like operations.
It's like managing infrastructure or like setting up stuff or doing integrations and, and. Sort of Vercel had their big announcements this week of all their like, sort of data storage options and offerings and, and that tight integration is so important and like making that user experience really good.
I think there's still tons of opportunity there, so I'm excited to see what y'all do with it.
Sabin: yeah, for sure. For sure.
[00:16:47] Type Gen vs Type API
Andrew: So let's go into like how Prisma can help with like your developer experience while developing with your database. So like, uh, generally [00:17:00] there's two ways to get types from something that isn't. Well, there's really one way to get something types from something that isn't type script and that's code gen.
The other, uh, way you could go with this type of thing is like use a zod like API, where you kind of like build up your, your database definition with type script. And now you don't have any generation. So, uh, like what, what do you see as like the pros and cons versus like code generation versus like building out a type script interface that like fits the situation?
Sabin: Yeah. So it's, uh, there are a couple different pros and cons, and we see people bring this up a lot in our GitHub issues. We, we've taken the code generation route. Where whenever you make database changes, it'll generate a new Prisma client for you. Uh, and it generates it into our node modules, so you can import it as if you were importing any other, uh, library.
Um, this is good and bad. Uh, this is, I guess some of the good parts about it is that you get that nice experience that you would have before where you can import not [00:18:00] from, um, a file path in your library, but you can import it, um, directly using, uh, the node modules folder. That's the default. Um, the, the negative part is that it's not stored with your code.
So the, when you download it for, say, on Vercel or if you're deploying, uh, I think Netlify has the same issue. Um, they'll preemptively sort of cache you node modules, um, so that on deployments, they're not re regenerating, re downloading stuff. They don't need to. And sometimes this in the past has caused problems with the Prisma client because it's generated into your node modules.
So you might end up using. Uh, an older version. We've recently fixed those issues, but things like that are just, um, little problems that arise the same, on the same strain of issues. The same thing happens with certain, um, uh, tooling around mono repos. So like NX for example, um, when you use nx, you need to define a certain specific output path for your generated client.
That way it's not generated into the node modules. So, um, I think [00:19:00] that's a long-winded way of saying that generating code leads to complications that you wouldn't really expect. Um, whereas if you just have a zod definition, uh, it sort of stays with your code base and you don't have to worry about it changing. Um, what's cool though is that the, the pluggable system that Prisma provides, the community has built zod generators, um, using Prisma client. So when you generate Prisma client, it'll also automatically generate ZD types for you based on everything. Uh, that's really cool because it allows you to generate those types and even maybe publish them.
Um, in a private NPM package that you can then pull into like a front end client or some other client that you're using, um, and get that type safety there. Um, so there's pros and cons to both. It's just really depending on what your team looks like and what your project requirements are.
Andrew: Yeah. One of the, the big benefits of the code generation is probably like the migrations wouldn't really be at all possible if that was defined via code. It's a lot simpler that like, oh, we have one schema turned into schema two, go [00:20:00] from schema one to schema
Sabin: mm-hmm. Exactly. Mm-hmm.
Justin: I mean, you kind of explicitly have to do code-generation because you're, I mean, the schema language itself is based off of a dsl, so it's like you've gotta generate something. Um, but I, I, I do think that that makes a nice trade off, at least in my experience, of, of using, uh, of using Prisma. It's like, The schema language is pretty simple to wrap your head around.
The tooling is like pretty really solid. You know, like Andrew was saying, it's like automatically, you know, completing, it's like, oh yeah, this field is connected to this field. You have like a mini to mini relationship or one to mini relationship or whatever. Um, and then the cogen there, it just kind of feels natural, like works.
Sabin: Yeah. We, we've seen a couple different times where, um, people in our issues or discussions have said, oh, I don't like code-generation and it's because of the schema. I don't like the schema, so I'm gonna move to something else. And then, uh, oftentimes they'll come back a couple months later and be like, oh, [00:21:00] it clicked.
I get it now. I like it. So it's like, it's the kind of thing where it is a mind shift because there's not a lot of other people doing this thing right now, and you really have to try it and actually work with it for a little bit to realize the benefits that you're getting.
Justin: Yeah, something always, I, I, you know, going back to like the comparison with GraphQL, something I always appreciated about GraphQL is like you define your whole schema on the server or whatever, and you know, you have this like, complex representation of what the reality there is, but it generates out this like really nice document for you.
Um, And while there were some people who did like, oh yeah, I want a, like a clean English, uh, schema that like generates out, like handlers and stuff, and that got really complicated. But overall, I think the, just having an artifact that you can look at and very neatly, especially on like some smaller screen real estate, kind of see what's going on and see the relationships between things.
That's huge. It's huge because, I mean, you know, code is, is written to be read, so, you know, that's, [00:22:00] that's massive.
Sabin: Yeah, absolutely. And I, um, before I was actually working at Prisma, I worked at a company and we were setting up microservices. Um, And, um, all running on no JS type script. And we were using Prisma and it was really cool because when new developers came on board, they could just pop open our, our prisma schema files and sort of generally see like, this is the sort of data this microservice, uh, uses.
This is how it relates to everything else, and it's all on one page, um, where you can sort of make those connections really easily. So sometimes we would even give it to like a product manager who wanted, um, to see which data, where we were accessing in the service and what it sort of relates to and does.
Um, and with the schema and some comments in the code, it was easy enough for even a non-technical person to go in and, um, and see what's going on, sort of there.
[00:22:49] Building for the Next Wave
Justin: Like you're saying, there's a lot of buzz that's around Versace right now, especially, and next, um, You know, kind of tying the, our topics together a little bit. How has, [00:23:00] how has Prisma been thinking about, you know, end-to-end type safety, if, if at all, and integration with these sort of like newer, uh, newer frameworks like, or newish frameworks like remix and, and next, you know, this like next generation of like backend for front end kind of frameworks.
Uh, how are y'all, what is your strategy for integration there?
Sabin: Yeah. So integration wise, um, honestly, we haven't had to do a whole lot in that area just because, um, even if you look at the remix docs, if you look at the next docs, um, Prisma kind of already ingrained in there. They're we're in their documentation, sort of the default to use. Um, the type safety just kind of works with them.
Just, um, by the nature of how it's built, what we have had to focus a lot on, um, as people move towards these new paradigms of deployment, that that's mostly where we're, we're being focused right now, is these, uh, serverless and edge deployment models require us to rethink sort of how our ORM works, how our products work, and adjust them to get [00:24:00] them working properly in these settings.
Justin: So what kind of a, what kind of adjustments? I mean, what does that, what does that look like?
Sabin: Yeah. Um, uh, a lot of it recently has been, uh, performance changes. So, uh, y you might have seen, I, I wrote a couple of articles recently that I put out that were really focused on, uh, how we've been changing Prisma to, uh, to be more performant, especially around cold starts. The way Prisma was built originally, we. We're more focused on GraphQL. In fact, we used to be another company called Graph Cool. Um, and sort of the underlying technologies that we use in our Prisma client, um, used GraphQL, um, specifically within the engines that generate and run your queries. Uh, this turned out to be really slow, and as people started deploying more and more at Serverless, it became more and more apparent how slow that actually was.
Um, so our focus has been sort of ripping that out, replacing it with a new protocol that's in preview right now. It's been doing really, really well. Um, as well as just [00:25:00] other little findings as we're diving into research, um, into the serverless and edge environments of how to like tweak the way we, um, manage the code even, and how we generate our assets in a way that works quicker in a serverless runtime.
Justin: I forgot all about graph. Cool.
Sabin: Yeah, yeah. I, I, I wasn't around for those times, but I remember hearing about it and, uh, yeah, it's, it's, it's old history at this point.
Justin: Yeah.
[00:25:29] Query Perf
Andrew: Yeah. One piece of feedback I've heard when talking about Prisma to other people is that the way it builds queries can sometimes, like, not be performant. Like I'm, I'm wholeheartedly a front end developer. And when I got into the backend code to here at Descript, I was writing terribly un performant, uh, sequel queries.
So what does Prisma do? Anything to help build like more performant queries as I'm using the interface.
Sabin: Yeah. So when, when we [00:26:00] generate queries, the logic behind that, that generates those, we put a lot of work into trying to generate the most performant queries we can. Um, we, we've gotten this feedback a lot as well, and it is a tricky one because there's a couple of different aspects to this. Um, and I think anyone at Prisma will tell you that we don't generate the most performant queries because just by default in ORM can't really.
Handle every possible scenario, you know what I mean? Like, if you're using a query builder, um, like, like next, or like Drizzle for example, you're gonna get probably a more performant query generated because you're explicitly defining it. Um, our layer of abstraction over it sort of, um, intentionally takes away that control from you so that you don't have to worry about it.
Um, however, that being said, we are focusing now that we've gotten through this Cold Start performance, um, sort of initiative, um, our goal right now is to speed up query performance by generating more performance queries. I have heard it, uh, a lot of this happened before I was around at Prisma, but I've heard it said by a couple [00:27:00] of the, uh, product managers who've been around a little bit longer than I have, that when we were first developing this, we were really focusing on.
Potentially large queries and optimizing for really heavy queries, uh, basically for large enterprises who are running, uh, pretty heavy queries. Uh, that's great. Uh, those queries are gonna run fast. A lot of the ways we generate like, uh, we don't use joins, we do like subsequent data waterfalls sort of selects, um, people have complained about that we did it that way so that in a larger query, um, it would be more performant cuz that ends up being more performant in larger queries.
Um, but we've realized recently that, um, we focused so much time speeding up these, uh, this sort of like edge case where it sort of leaves the, the majority of the queries behind a little bit. So we may be saving, you know, A couple hundred milliseconds on the really expensive queries, but it's making the, the smaller queries, uh, a little bit slower than [00:28:00] even those were.
Uh, so we're sort of shifting that focus back to where we need to, uh, sort of find the, the right balance and the best of both worlds to make sure both are performing properly. I know that was probably a longer response than you were looking for, but, um, that Yeah, that's, that's sort of our, our, our goal right now.
Justin: This is always a trade off. With an OM though. I mean, it's like you, you either have to build your interface such that it's like it is a query builder. Essentially. You're just like a thin wrapper over sequel or. You know, you have to sort of like build those performance concerns because it's hard to get both of those.
[00:28:35] Hidden Gems
Justin: Um, so it's, it's interesting to see, uh, just a, a general question here. What do you think are some like really, really interesting, really under, uh, advertised features of Prisma? What are things that like get you really jazzed that you feel like not enough people know about?
Sabin: Yeah. Um, uh, this one is something that I think people know about but don't use enough. [00:29:00] Uh, and that is interactive transactions. Um, not a lot of tools actually. If you, if you go around and look at the other ORMs, uh, that are out there in this ecosystem, not a lot of 'em allow you to run interactive transactions.
Um, and I feel like the fact that we offer it, uh, isn't quite enough yet. We need to advertise it more so that people start realizing this is why you might need interactive transactions, cuz it can really save, save you on a lot of things.
Andrew: So let's start here. I have no clue what an interactive transaction
is. Why? Why would, why would I want one? And how is it cool?
Sabin: Yeah. So, um, interactive transactions allow you to basically batch different sets of queries into, uh, into one large query that could be rolled back if it fails. So in, in this sense, it would be, say you have like an email sign up flow. Um, you sign up a user, you send them out an email, and maybe you store a couple of other things.
Maybe you update some analytics, uh, in your backend, and it's all gonna be run in a series of different queries. Um, but if any one of [00:30:00] those steps fails, you don't want any of it to happen. So what you could do with us is we have a, uh, interactive transaction function where you can pass it in a callback.
Basically you can run a set of prisma queries, you could do any application logic within the JavaScript there, um, to update values, massage your data, um, and then update more in the database. Um, and then if anything fails, we, there's a rollback piece of it where you could say, okay, everything I just told you to do, don't do it anymore.
Um, so it. Allows you that flexibility to, uh, batch multiple operations. And it also, since it runs it as one individual transaction, if you're doing like a mass update or something and you're gonna be updating a lot of data, you can run it within one of these transactions. That way it's not a bunch of, um, a bunch of consecutive queries taking up a lot of your, your, uh, your io.
It's instead just one large transaction to the database. Uh, does that make sense or is any of that
Andrew: Oh yeah. Oh, that ma made, made a bunch of sense. I think I've actually used [00:31:00] those before in our own code base. Uh, they're just Postgres tasks
is what I, I knew them by. Um, yeah, I could, I see how those are super useful. Like, uh, if you're doing a bunch of things in a row, there's such a large chance that things will change out from underneath you.
Uh, do you guys provide any like tooling to help, like, kick me in that direction? Like an es lent rule that's like, oh, you called the database three times in a row. Use a, use a, a transaction dummy.
Sabin: Uh, we don't actually, we have a, a little esent plugin actually that's kind of in the works. We had a couple people working on it, and right now it's sort of under my ownership. I haven't really done too much on it yet, but what we're looking for is to, to, to provide a lot of these things. Like a good example is, um, when you do a create with Prisma, by default it returns you all the fields that you created.
Um, if you're working, which God forbid, hopefully you're not, but if you're working in a company who has a table that has like a hundred fields, which is more common than you'd think, um, and you create a [00:32:00] record, you don't necessarily wanna send all a hundred of those fields back over the network. So, like the Eslint plugin we have for that right now, uh, tells you, Hey, when you do a create statement, you have to provide a select statement and pick what you want back.
Um, so we, we do have some of that, but nothing quite towards the transactions yet. We're sort of defining what we wanna do with it right now.
Andrew: It seems like a great start though cuz like as I've said a few times already, I'm a stupid front end developer and I'm not gonna think about any of these things.
Sabin: Yeah. Well that's, that's the mindset we try to take when we design these APIs and stuff, is that we wanna assume that the developer doesn't know what they're doing, which is usually not the case, but it e even when you do know what you're doing, it's helpful to, to just have that assumed that you don't.
Justin: Yeah, I mean, try to do the right thing by default. Give people good feedback, you know, in the common case. Yeah. That's cool.
Sabin: Yeah. I, I think, um, um, another feature that [00:33:00] is newer to Prisma, but I think, uh, it really gets me excited, is our Prisma client extensions sort of expands upon what middleware used to be for Prisma client and allows you to extend the client. Um, so you can add your own functionality, you can add your own sets of queries, um, In the past, you would basically get our set of functions that were defined in our api, but now you can actually, uh, intercept those or add to those, um, and create your own.
And I think that's a really cool feature. We've seen people use it already, um, to, to build some cool stuff. We use it to build our, like accelerate extensions. This is basically just a really glorified, um, uh, Prisma client extension.
Justin: So these are runtime extensions, right? To the Prisma client library. Okay, great, great, great. Uh, what, so way back earlier you talk, you were talking about people building zo uh, adapters onto, like, cogen for Prisma. Is, is there, is there like a, a plug-in system to hook into the generator too, or is, or are they just [00:34:00] doing their own thing?
Sabin: Yeah. So, uh, what we actually allow you to do is build your own generators. Your prisma schema file can have multiple generator blocks. Um, and basically if you define your own generator, that fits with our, um, with. Uh, I guess the requirements of our generator system, it will automatically run through all of those and generate your code for you.
Um, it's not very documented right now. It's not super well documented. We have a couple of, uh, really, I guess, advanced users who've sort of picked apart how the system works and figured it out. Uh, we need to get it documented more. I think we're sort of just waiting on engineering to make sure that things are like, uh, you know, gonna be good and gonna stay the same.
But, um, yeah, it, it is definitely possible. Right now. There are resources to help you get started. It's just not in our official docs yet.
Justin: There's a, I'm, I'm surprised. It's like there's actually a lot of generators.
Sabin: Yeah, and we have, uh, if you go on prisma.io/ecosystem, uh, that might be where you're looking right now. [00:35:00] Um, there's a thing to submit your own generators and packages and extensions on the top. We, we have a lot of stuff in the pipeline there that we haven't even added yet cuz we're sort of going through and looking at 'em.
Um, the, the community's really like, Taken this feature and just took off with it, like places we didn't expect them to. And it's, it's really cool to see.
Andrew: Are there any specific examples that you were like, you saw those and you're like, wow, I can't believe someone did this.
Sabin: Yeah. Yeah. Well, there, there's a couple, actually. Uh, one of the ones that gets me the most excited is that someone built, uh, uh, a tool, an extension basically, that helps you generate the scaffold for your own generator. So someone basically a cli tool to start your own generator and it gives you docs on how to, how to do it.
So that, that's really nice. We didn't build that. A community member took it upon themselves and that was really cool. Um, aside from that though, for actual like tools with, with Prisma, um, we have, uh, somebody, I forget what it's called now. I'm trying to look for it, but I'll find the link some other time.[00:36:00]
Um, somebody built a visual scheme of builder where you can basically drag it and drop elements onto the screen.
Um, and it. Builds a, a schema. It's really cool. Um, these people are doing awesome stuff. Um, some other person built a, uh, entity, what's it called? The, I can't remember what it's called. Oh, an entity diagrams, uh, where you can, basically, when you generate Prism a client, it also generates an entity diagram based on your schema.
And that that's really cool. Cause then you could just, uh, pass that off, host it somewhere and people can see what your, what your schema looks like.
Justin: Yeah. That's awesome.
Andrew: It's so cool to see what people will do when you give them plug plugins to play around with. The creativity is wild. You, you'd never think, oh, I want my database, or to have plugins.
Sabin: yeah. Yeah. it's it's funny because there's also like other tools out there like keysly who you, who allow you to query databases and stuff. And because of the nature of how they're [00:37:00] built and what they're focused on, they can do like slightly more performing queries. People have actually built prisma schema generators that generate out your keysly definitions and types.
So you can use Prisma and keysly together now to get that nice performance while still using Prisma. Um, and I, I think that's cool. People are just hooking us up to a whole bunch of different things and it's, it's nice to see.
[00:37:21] Full Text Search
Andrew: Yeah. Looking at a few other features that you have coming out in preview, there's also full text search, so like, uh, what problem does this solve?
Sabin: Yes. Yeah. So, um, this solves the problem of if you imagine, um, you're performing a query, um, and you can search for substrings within a larger string, or that's just an example, but that's, that's, uh, the most common one, I guess. Um, currently with Prisma client, you can't really do that. You can do a contains, um, or you could check if a string contains a certain string, but this fuzzy, uh, like full text search will allow you to search across different fields with, with, uh, just individual keywords, I guess.
Justin: [00:38:00] That's interesting cuz that's a feature you have to normalize, right?
Sabin: Yeah, yeah, exactly. That, that's the reason it's taken so long is because we're getting feedback from different people on different databases to make sure it's working consistently across all of them. Uh, so far it's looking good. It's, it's getting close to, to the point where we can release it, I think.
But, um, it, it, it has been taking a while to make sure that everything's working right.
Andrew: Yeah, getting the everything working across all the databases that you support must be like the biggest challenge of Prisma.
Sabin: Yeah. Well, if you look at other ORMs out there in the, in the, uh, I guess in the ecosystem, they'll all tell you like, Hey, don't support no sequel and sequel. Just do one or the other. Like, everyone thinks it's a dumb idea. Uh, I, I agree. We do it, but I totally agree. It's dumb because it adds so much to your, to your development life cycle. Um, is it worth it in the end? Yes, but it, it just adds to how long features have to stay in preview For sure.
Andrew: Has it ever like stopped you guys from shipping a future? You're like, oh, we can support this [00:39:00] on Postgres, but like, there is no path to support on MyQ L.
Sabin: Yeah, there, there are a couple of those actually. Um, and I think most of them are actually documented in the doc somewhere. I'd have to find it. Um, but when you try to do something that's supported in one database and not another one, um, Prisma schema will actually tell you, Hey, this isn't supported in your database provider.
You have to use MySQL to do this or something.
Justin: Yeah, that makes sense. I mean, it's a trade off that you have to do. Uh, I mean it, I think it's honestly fascinating that you can support so many databases anyway. Like that's a non, non-trivial thing to do.
Sabin: Oh yeah. Yeah. Our engineering team is, is fantastic. It's awesome to see them working together and working through these issues. Um, it's also been really cool to see. The collaboration that's been opened up with other bigger companies like Mongo, cockroach db, things like those, if we find stuff that we need to support that isn't supported yet, these companies have been very open to us coming in and saying, suggesting stuff, and they'll just [00:40:00] basically jump on it right away for us.
So it's been really cool.
[00:40:03] Future Features
Andrew: What's next for Prisma? What are you guys planning? How are you gonna change the industry?
Sabin: Yeah, so we, uh, there've been a couple things that we've teased on Twitter. Uh, you may have seen some very cryptic posts on, on the Twitter channel where it's like a gif or something where we're talking about, um, stuff coming up. Uh, we're, we're having a new product launched and it should be, um, Available sometime in May.
We're thinking around the middle or end of May, but, um, the date's a little fuzzy, but it's, it's coming really close. Um, and we've seen a lot of people guessing as to what it's about, and they're getting pretty close. It has to do with, um, uh, basically, uh, data like, uh, change detection on your database. Um, so if you think about like how, uh, a firebase or a super base works where you get these ni nice updates when your data changes, um, we're headed in that direction.
We, we have our own spin to it and it's gonna be really, really cool. Um, but yeah, that, like this all leads [00:41:00] into sort of the idea of distributed serverless systems where we're, where Prisma is focusing. Um, so this is just one example of a product that we have in the works, um, to help democratize your data in a serverless sort of distributed system.
Justin: That's awesome.
Andrew: Is that like email notifications or Like in my app, I'm getting notified, like the UI updates, whatever you can say.
Sabin: Yeah. Um, so it it not email notification, so it's gonna be in your apps. This is related to querying and accessing your data. Um,
so think along the lines of like web sockets, how you can like basically stream sets of data and listen and subscribe to, uh, to things to get data changes. Um, it's, it's along those lines.
I'm being very cryptic. I apologize, but, uh, you, you'll see soon enough it's gonna be very, very cool.
Justin: Awesome.
Andrew: Hey, I got my journalist [00:42:00] hat on. I'm digging.
Sabin: Yeah. Yeah.
Andrew: Okay. With that, let's, uh, transition to tooltip.
That's it for the free portion of the interview. If you want to hear a full conversation with Saban, you'll have to become a paid subscriber. Thanks for listening. Okay. Um, that wraps it up for this week's tooltip. Uh, thanks for coming on Sabine. It was a nice learning all about Prisma and all the new things that you guys got planned
Sabin: Yeah. Yeah. Thanks for having me. It was a lot of fun.
Justin: Yeah. Great. Thanks for joining.