Alex:
In a nutshell, Prisma is an ORM. It provides a high-level abstraction over your database with a really nice and typesafe API that allows you to interact with your database. So for example, you can use Prisma to model your database using on the Prisma schema using a natural and familiar language that's really human-readable. And then after that, it allows you to generate your migrations.

Paul:
Hi there, and welcome to Pod Rocket. I'm your host, Paul, and today we're joined with Alex. Alex is a developer advocate over at Prisma. We've gone over Prisma at some older episodes, and today we're going to be diving into what's new and upcoming and some of the interesting niche work that Alex has been posting about online. You might have seen Alex pop up in his posts about using database on the edge of CloudFlare workers or database workflows, and we're going to be getting into what even is a database workflow. Really excited. Welcome to the podcast, Alex.

Alex:
Thank you, Paul. Thank you for having me on the podcast as well.

Paul:
So Alex, how long have you been with Prisma?

Alex:
At this point, it's about two years and two months. I accidentally got into developer advocacy while I was still in Compass, where I used to spend my free time teaching other students the tech that is actually used in the industry because our curriculum was kind of outdated. And then fast-forward, I joined Microsoft Learn Student Ambassadors program, which now provided a bigger platform to even help students within my Compass. Fast-forward a few months later, there was a job opening for Prisma for a working student as a developer advocate, and I applied and luckily got in. And since then, I've been talking about databases, working with Prisma, and it's been a really fun journey for me.

Paul:
You said databases. You've been working with databases. Prisma is a database thing. So we had this podcast when you started with Prisma two years and change ago here on Pod Rocket. For folks who probably missed that, what is Prisma in a sentence or two?

Alex:
In a nutshell, Prisma is an ORM and it provides a high-level abstraction over your database with a really nice and typesafe API that allows you to interact with your database. So for example, you can use Prisma to model your database using on the Prisma schema using a natural and familiar language that's really human-readable. And then after that, it allows you to generate your migrations. And migrations are the SQL that describe what the structure of the database should look like, and then after which it generates for you a typesafe client that you can use to query your application from the server side.
The fun part about Prisma, when I started, I started using Prisma about three months before I joined the company, and I would identify as a front-end developer. And back then, I had little to no knowledge about databases, and my dad had tasked me with just building a tiny inventory application. And then I saw Prisma online, and then I decided to try it out. And it felt like I was kind of cheating because I was doing the database stuff, which I'm not familiar with, but it felt so easy for me.

Paul:
I have to say I share the same experience of you step into databases. Maybe it's something new to you in Prisma. It puts up those guardrails for you, if you're into bowling or something like this. It makes it so you less likely to mess up and it almost feels like cheating.

Alex:
Yeah. And for example, if you're a front-end developer and with all the recent JavaScript frameworks that are out there like Next.js and Remix, they've really blurred the lines between the front end and the back end with tools like getServerSideProps Next.js and API routes, which allow you to do server-side stuff. And this is where you can inject Prisma to query your data.

Paul:
So Prisma can plug into Postgres, to my understanding. You can plug into MySQL. I've only ever used it for Postgres. Being somebody like yourself who self-proclaimed, "I'm a front-end developer," you must have your face in databases. Which one has sung to you the loudest and the sweetest? Which one do you usually find yourself working with?

Alex:
That's a tough one. Personally, I like any relational database, and I would say Postgres for now. But PlanetScale, which is a flavor of MySQL, is pretty cool. So the reason I like relational databases even though we support MongoDB, which is not relational in nature, is because you are given a schema, and this schema always serves as your source of truth of the structure of your database, which sometimes MongoDB doesn't offer. I'm not trying to say MongoDB is not great, but it's also a great database. But if I were to choose, I'd go with Postgres.

Paul:
You say, "I'm a front-end developer by trade." Is that how you entered into the coding world, making little applications? I think that's a very common method to get into things because it's visual. You can see it right away and you're like, "Wow. That's nice."

Alex:
Yes. However, my opinion has changed of what my identity is because I currently identify with wherever the wind blows. And if that's full stack, I'll go with full stack, whether it's with Node.js or Go, I'll still learn it. And if I'm expected to work on the front end, that's where I will be, and I will put in my best effort to just get things running. Yeah.

Paul:
You brought up a very interesting thing that's happening in the space today, which is we're blurring the lines between the front end and the back end. Yeah. We got Remix, the whole Islands architecture that's coming out with Astro. We have a few podcasts on what's happening in the space right now. As somebody who maybe came from the front end, you have a very interesting talk that you put out about using databases on the edge because the edge is becoming a very common thing. If you're not on the edge, you're being left behind because your website's always going to be slower than the people who do have it out there. And we're going to get into that talk in a moment. But before we do, I want to quickly circle around the video you put out about database workflows. What is a database workflow? When I think of a workflow, I'm thinking of Temporal.io. I'm thinking about a sequence of steps. So how does this relate to specifically the niche of the Prisma framework in your head?

Alex:
It's different from Temporal, that's for sure. And last year, while I was working with databases and also helping out some of our users in the community, it seems there was a lot of confusion as to how to work with database migrations. And folks who are unfamiliar, a migration is I guess like an artifact that describes what the state of the database should look like at a particular point in time, if that makes sense. And Prisma Migrate is the tool that allows you to evolve your database schema. So for example, if you are building an application for the next 10 years, I'm sure the database structure will change from time to time. So migrations allow you to define the change that you're going to make to your database. And you can think of it like kind of Prisma Migrate as a tool that provides state management, but for the database.
And Prisma Migrate uses different tools to track the state of the database. So for example, there's the Prisma schema, which serves as the source of truth for your database structure, which you would say define the different models and the relations and the different fields. And then you would generate a migration, which now describes the change that you want to make. And then it would apply it to the database, and then the database serves as another point of reference where this structure is actually applied. So the whole point of the workshop that I created was to help developers who are unfamiliar with databases, how to use such tools to track the state of your schema. So this could be using, again, this Prisma Migrate. There's the dev command that allows you to generate this SQL migration. And then there's the DB push that doesn't require any migration to be generated, but I won't get into the weeds because that's a whole rabbit hole that I can just lose myself whenever I nerd about it. Yeah.

Paul:
In general though, when you say database workflow, you're talking about the hygiene we'll practice as developers in moving forward with our database as it evolves and grows using the Prisma tools.

Alex:
Yes. Exactly. So the typical workflow would be you first start with defining the structure of your database schema in the Prisma schema, and then once you're happy with the state that it's in, you now run a particular command which would generate a specific SQL that describes the change that you want to make. And then after that, it would be applied to your database to highlight structure should be.

Paul:
As somebody who works with beginners or people trying to get into Prisma and databases, what's one of the number one areas you think people coming into the space might miss the mark on when they're developing their own personal workflows or things you see people do that you're like, "Maybe we should rethink how that's done."?

Alex:
That's a good question and a tough one. So Prisma provides the Prisma Client, which is usually fairly intuitive to use with the API. I mean, from the first time I used it, I didn't have to refer to the documentation because the type safety just helped me, I'm going to say something cringey, but just autocomplete my way to success. So that was fairly easy. But I think where people might miss the mark on is understanding what migrations are, for example, and how to work with the schema management tools, especially if you're unfamiliar with databases because for probably back end developers or developers who've worked with databases before, they definitely have the experience, and therefore, picking up such a tool would be fairly easy for them.

Paul:
Could I say a migration is similar to a diff between Git branches, it's sort of just like some record of what has changed? Or is there more going on in the migration that is just, this would be a bastardization to call it a git diff?

Alex:
It is. It actually is a diff between your Prisma schema and your database schema. I would say that is an accurate description. However, it's slightly more complicated than that because say you're trying to rename a field, you have to be specific because if a column has data, you wouldn't want to lose that data. So you have to be very strategic about it. But in a nutshell, that's an accurate description. Yeah.

Paul:
Awesome. Thank you for that because I've always been wondering if I can think of them mentally model the same.

Alex:
It is.

Paul:
So I got the Alex thumbs-up of approval here. So we're good. I'd love to switch gears and talk a little bit about the edge, Alex, because everybody's talking about the edge these days. And not to keep replugging here, but we had a podcast with a great individual, Matt Robenalt, and he has done some compelling research on using HTTP as the underlying transport protocol for database connections. Some of the results that were coming out of that were just mind-boggling, actually speed gains if not on par using HTTP. And so here you are with a totally different approach. It's like, "Okay. We'll use the edge. We'll use data proxies." I'm really interested to pick your brain about why did you want to put data-based connections on the edge? What was the personal project or thing that you woke up one day where you're like, "Oh. Shoot. I need this and it's hard. So let's look into it." What was that project?

Alex:
I feel like I'm going to disappoint you, but there was no project. I think it was just a cool technology that comes up. And sadly, as a developer advocate, you're always chasing the new shiny thing because it's new and you have the freedom to try it out. And I was just curious as to how we can make basically traditional databases such as Postgres, MySQL, and SQL Server work on the edge. And again, for folks who are unfamiliar with the edge, the edge is a form of serverless compute that is now taken closer to the user, if that makes sense.
So one of the challenges when working with databases on the edge is that the edge uses a different protocol from what traditional databases would offer. So it seems like only greenfield projects would only be the ones that take advantage of this because as I said, the edge uses HTTP and the databases use TCP/IP. So there was that mismatch where you can't really use a traditional database on the edge. We built the Prisma data proxy, which is like a connection-pulling tool. It's like an additional, tiny, additional piece of infrastructure that we post for you and uses the HTTP protocol that allows you to communicate with your database as well. So that was pretty nice because the problem of working with HTTP on the edge... I mean, working with databases on the edge is kind of solved.

Paul:
Just for my own mental model to wrap this up real quick in a bundle, so you said anybody right now can go connect to their database. And it could be a variety of databases because Prisma is the glue between here. It could be like Cockroach, MySQL Server, or whatever. You could have an edge function, you connect to any of these databases, and that's a new thing because we couldn't go under the HTTP layer on the edge.

Alex:
Exactly.

Paul:
Okay. So you guys at Prisma is providing this proxy that lets you say, "All right. No, you guys can use HTTP. You don't need crazy magic. You don't need crazy research that's going on in the field right now. We have the service. You can use it, you'll connect, and you can use any of the databases that Prisma can connect to."

Alex:
Exactly. However, the one caveat that I give at the end of the talk is that it's a fairly new technology, and connecting to your central database from the edge makes your database the bottleneck of your application because if for example, you deploy an API to the edge and your database is located in, say New York, a user who's in say New Zealand or Australia would experience more latency than the user who is in the US. And that was the big issue that I gave that people shouldn't dive headfirst into it.
However, we kind of solved this problem with a new product that we launched into early access a few weeks ago called Accelerate, where we allow you to cache now your data on the edge, and this is another piece of infrastructure that is in front of your database that allows you to cache the data. You can specify, for example, a time to live or stale while revalidate, I guess.

Paul:
Accelerator is just like database caching on the edge-

Alex:
Exactly.

Paul:
... at some boiled-down layer, whatever that might be. It's a bleeding-edge. It's coming out right now. But it tackles the bottlenecking problem. Do you find that a lot of people miss the mark on like, "Oh. I have the edge, but missing the... It still needs to call home to the database. It still needs to go somewhere. It still is that central place." I feel like that's a trap I would fall into, getting really excited about the edge.

Alex:
It is.

Paul:
Because it's easy to click deploy to every country.

Alex:
It is. I agree. And I think we are in a niche category of developers where we are JavaScript developers and we are always chasing that new, shiny tool or deployment platform. But I actually think that most developers are more conservative with the technologies that they adopt for their projects. They're probably even late adopters. So they usually take time for technology to mature before they can actually pick it up and use it in perhaps their own personal project or even at work.

Paul:
When you say people usually are slow to pick up technology, that resonates with me and it makes sense because you want to be proficient in your work. You want to be good in your work. You want to do something your experienced with.

Alex:
Exactly.

Paul:
As somebody who's in DevRel world, what do you think is the bird's-eye view of scoop-up time for a community to start using a technology that you put out? If you put out the Accelerate software and it's like, "Okay. I can start building applications with some sort of level of replication on the edge," how long would you peg that to an everyday thing that people... When can I go and find Web Dev Simplified talking about it on YouTube? When can I go find Fireship.io talking about it on YouTube? That's how we know we've reached the mass market.

Alex:
That's a tough one. They're usually different kinds of developers in on the craft. There's usually the early adopters and the folks who are usually very excited, and they're the ones who are always on the bleeding-edge, and usually just like you and I, would chase the next new technology. And then there are folks who usually wait for this hype to die, and this, I'm estimating somewhere around six months, and then they start getting into the idea of thinking about actually trying it out. And then there are people who are more conservative, and they actually do the deep dive research and check out if they actually meet the needs of their project. And for example, take a look as to whether the project is sustainable or whether it wouldn't be deprecated or shut down after a couple of months because it would be a bummer after spending six months refactoring your application, and now you have to look for another tool that you can use on your project.

Paul:
I just think it's wild that you mentioned six months because I feel like the field changes so fast.

Alex:
It does.

Paul:
And there's so many things coming out and it's like, well, no, the fast people, the early adopters, they're the six-monthers.

Alex:
Yes.

Paul:
It really puts it in a perspective about how slow it takes for groups to adopt these technologies as they come out.

Alex:
It does. And with the whole JavaScript ecosystem, sorry for going on a tangent, but it feels like we are going back to how things used to be and how the PHP developers did things. And they're also borrowing things from us as well to create this new and [inaudible 00:17:49] just great tooling, I guess. So it feels like we are going backwards in JavaScript in some ways, but still in the right direction. I feel like I might actually have hurt a couple of developers' feelings with just that comment, so please don't come after me.

Paul:
No. Totally. I think it's a very common point you bring up. And I think another common thing that's funny that you mentioned, Alex, is in general, as a developer body, when we're talking about what's the new and upcoming... And we're going to quickly talk about what's new and upcoming in Prisma 4 because I really want to know. I know there's some big drops coming. But yeah, really quick. We're talking about, "Oh. We're going back. We're going back to the old days." And who are we going back towards? It's these godly PHP guys. They're the ones like, "Who were these people?" But they set up some standards and ways of doing things that the whole developer community looks back on and we're just like, "Wow." They reached some level of nirvana that we don't understand.
But yeah. Let's get into Prisma 4. As we're running up on time here, I'd love to know what's coming. Right now, I'm a very basic user of Prism. I don't use a lot of bells and whistles. And I know there's bells and whistles coming out, Alex. So what's one of the one or two that you might want to turn the audience's attention to?

Alex:
So since the first time we launched Prisma version 2, we've been constantly improving the set of features that we offer developers. And as I was highlighted before about having late adopters, one way to capture this audience is by actually closing the gap on a number of features that we currently don't offer that we are now slowly starting to offer and solving problems that currently exist with the product.
So for example, some of the features that we've been shipping in the last couple of months is decreasing the size of Prisma itself as the engines that are usually used under the hood for serializing and dematerializing or communicating with your database. So we reduce the size of that significantly. This is in line with one of our goals, which is to help developers who are working on the edge or deploying the applications to serverless and edge platforms to get a significantly better development experience. We introduced the support for multiple schemas, and I will probably lose people if I dive into the specifics of multi-schema, but multi-schema-

Paul:
Yeah. But it's there.

Alex:
Yes. Yeah. We are now offering it. We also launched something called the Prisma Client extensions, which allows you to extend Prisma Client. So Prisma Client allows you to compose your queries and you can now extend Prisma Client by, for example, creating computed fields or virtual fields. You can create your own queries if you'd like custom queries. So yeah.

Paul:
Oh, wow. That's nice. Could I think of making a library that I could then distribute to my team that has prefab requests? I'm like, "This table, you should never query this table with a select star. Please just never do that." Is that in line with what you're describing?

Alex:
Exactly. It is. So an interesting, fun fact is that that Accelerate takes advantage of Prisma Client extensions. So you can definitely use client extensions to do whatever you can think of, whether that's adding role-level security or even adding validation before you insert some data into the database. So whatever you can think of, Prisma Client extensions can probably do it. Yeah.

Paul:
And last but not least, you mentioned Accelerate a few times already, and that's available. Is it early access, invite only? What's the status of that?

Alex:
So at the moment, well, at the time of this recording, it's currently in early access, and it's available to a private beta. It's a private beta. So in a couple of weeks or months, we'll make it available to the public to try it out. We actually talked about it in the What's New in Prisma version 4.9.0, where one of our engineers actually walks through it and shows the performance gains that you can actually get from just caching data while still accessing it from the edge. And for example, there was a query that you could cache by adding a time to live for about 60 seconds, for example. And the query using Accelerate was significantly faster than the query just not using Accelerate. And I think it was about... I don't remember the exact numbers, but it was about 50 milliseconds time.

Paul:
Didn't even register on the same unit of measurement.

Alex:
Exactly.

Paul:
Yeah. Do you feel like almost a skill level for somebody to develop a edge-distributed application, all these great things are coming out, and the field's moving. Web development's moving in the direction of, we're going to have replicated database. We're going to have edge functions. Do you think there is a linearly-scaling equal skill requirement increase that's happening for developers, or are these technologies that are coming out, in your opinion, doing a good enough job to make it just as approachable for the everyday developer to take advantage of the modern?

Alex:
I believe so. For example, Next.js introduced a really simple way of deploying Next.js to Vercel's edge network. And you don't have to do much. You just have to specify the experimental variable. So as a developer, you probably don't need to know too much about the edge and how it runs, but you just need to know enough, such as its limitations of the stuff that you can and cannot do as well.

Paul:
So you feel like there's a good, equal development going on on the personal soft skill side and the technology side. So Alex, if people wanted to learn about Prisma 5, is that even a thing? Is that something people are talking about yet, Prisma 5?

Alex:
Not yet. That's for sure.

Paul:
Not yet. Okay.

Alex:
But we've been releasing a new version every three weeks. The releases sometimes are small, some are bigger than others, but they always have something new to add to the new version, I guess.

Paul:
Right. Yeah. Something material, something good.

Alex:
Definitely. Something improving the experience. Indeed. Yeah.

Paul:
If people wanted to keep tabs on Alex, keep tabs on you and when Prisma 5 is going to come out, do you tweet? Do you write? Where can people find you?

Alex:
I do all of those at twitter.com/ruheni_alex. I also write articles on the Prisma blog. We have a What's New in Prisma livestream every three weeks. We also have a public Slack where you can ask a question and someone from support or a developer advocate could respond to you. But I would say stay tuned. We are building more products that will definitely improve the experience in the edge and serverless. And just to give a teaser, we're actually working on something that allows you to subscribe to events on the database level so that you don't have to define, for example, sockets and stuff like that. Directly from Prisma Client.

Paul:
Alex, thank you for your time. Thank you for coming on the podcast. And just for viewers can know because they're listening, your Twitter is ruheni_alex, which is R-U-H-E-N-I underscore Alex.

Alex:
Yes. That's correct.

Paul:
Awesome. Thanks again, Alex.

Alex:
Thank you for having me, Paul.