Supper Club × ORMs with Nikolas Burk from Prisma

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syndax. This is the podcast with the tastiest web development treats out there Today, we've got a really good episode. We've got Nicholas Burke, who's from Prisma, here to talk all about, both what Prisma is, but I'm I'm also curious about, like, what role does an ORM play when you're building an application? And I've got some questions around TypeScript and and generating types and if that's a good idea and all kinds of really interesting stuff. So, buckle up For that one, we're sponsored by 3 awesome companies today.

First one is Hasura. They give you an instant GraphQL API On your data source to help you build modern apps faster, Storyblock,

the headless CMS that'll revolutionize your digital Storytelling and fire hydrant, which helps innovative engineering teams prepare for, respond to, and learn from their incidents.

Awesome. So welcome, Nicholas. Thanks so much for coming on. Hey, Wes. Hey, Scott. It's really nice to be on the show and talk to you both in person after hearing you in my ears only, through your podcast the entire time.

Yeah. Yeah. That that's awesome. I don't know if I've Have we ever had a call before? I used to We haven't. You spoke to,

Johannes back in the day when he was still at Prisma, I think a couple of times, When you were working on your React advanced course but that was back in the Prisma one days. Right? And probably 3, 4 years ago, so quite a while. A lot has happened since then. And I'm really looking forward to kind of dive into the details there

and explore how Prisma and the developer ecosystem also has changed since then. Yeah. Actually, so I've I've used Prisma, like, sort of all all along the way. So back when I was first building my Advanced React course, I built it in Graphcool, which was the very first iteration of that.

And then Johannes was like, you probably wanna move this over to Prisma because it's like, he didn't say GraphQL was going away, but he kinda said GraphQL was going away.

So, I moved it over to Prisma 1.

And then when I rerecorded it about a year and a half ago, I You went with Keystone, which Keystone uses Prisma as an ORM. So we're not directly using Prisma there, but it's it's running under the hood. So, it's kinda interesting. So do you wanna give us, like, a a rundown of what is Prisma and and and what does it oh, before we do that, we should get into, Oh, what Nicholas's role is Yeah. History is a little bit about our guest wife. Good idea. How do we how do we do The show. Skip the introduction. Yes. Yeah. Okay. Who are you?

Alright. Yeah. My name is Nicholas, and I lead the developer advocacy team here at Prisma. And it's actually already funny that you mentioned Graphcool West because I have been around since the Graphcool times. Oh. So I'm coming up to my 6th anniversary, at Prisma, beginning of next year. And at this time, I think I've also like, I like, I probably am the employee that has been around the the longest along with our founder and CEO, Soren.

And yeah.

I've been wearing many headset Prisma for a long time. In the beginning, I, worked on our front end as well. I've been responsible for a whole lot of the content that we've been putting out, for a long time. Also, the docs were entirely my responsibility, events, building example projects, all these kinds of things.

And, since last year, my role has Kind of crystallized a little bit more. And, since then, I've been leading and building the developer advocacy team over here at Prisma, Which has been a really fun ride so far because I basically, because I basically get to hire people who I can now share the experience with that I've acquired over the last couple of years, and, hopefully, these people will be able to do the job a lot better than than I have, was able, was ever able to do it.

Awesome.

Okay. Well okay. So now maybe we should get into the the the evolution of Prisma, I think, I myself personally have largely bend it into the section of my brain, which says says GraphQL related.

But, as we have learned, Prisma is now just, an ORM. And I say justice, and it's no longer tightly, bound to a GraphQL ecosystem or or in in regards there. So do you wanna give us, like, a rundown of from F Cool to Prisma one to Prisma today, and and how it's changed and evolved, and maybe, we can get into some of the reasons why.

Oh, yes. I would be very happy to do that and finally clarify a lot of these things because I know that you're also not the only people that perceive Prisma Still in this way and it being tightly associated with GraphQL.

In fact, with a lot of people that I talk to in our community who are new, they still expect Prisma to give them a GraphQL server. And the first thing that I tell these people is, okay, forget everything you know about about Prisma and that it's associated with GraphQL at all, just think about databases.

But let's take the step back and start at GraphQL that We published the one point o version back in 2017, and that was really a GraphQL back end as a service.

It was kind of comparable to a service like Firebase maybe or Paras back in the day, where you would go online, you would open your web browser, you would go to graph.cool was actually the domain. You would log in with your account and then you could define a data model.

So you could create a user model, maybe a post model, all of that in the web UI, and then you would hit deploy.

And what would happen then was that it would give you a database And a GraphQL API. So as a front end developer, you didn't have to bother doing anything on the best, on back end side besides configuring the data model up until that point. Of course, it also came with some additional features and services such as authentication, a mechanism to define permissions on the data, integrations with services like Stripe.

So these things that developers typically need when they build applications, but it was very much geared towards only front end developers who didn't want to bother writing any lines of code on their back end at all. Can we can we take a second to admit that graph.cool

was an incredible Domain name. That's a really, really great domain name.

It was really nice. And in fact, the the tool itself, it also was really popular. I mean, I think it speaks for itself that, like, somebody like Wes wanted to build, like, a, an entire course on top of it. Yeah. It was a a really popular tool actually. And people loved it because it made it really easy, it made it really easy for them To quickly work with GraphQL, it was also a really new technology at the time, GraphQL itself. It had had just been released by Facebook, So there weren't many resources how to even build a GraphQL server. So having something that was just would just stand up this GraphQL API for you was just a big game changer for a lot of people.

But what we also saw was that a lot of developers started out using GraphQL, Prototype their GraphQL API but then as soon as they wanted to build something real and deploy it to production, that's when they actually went Moved off of GraphQL and built their own GraphQL servers from scratch.

And, of course, for us as a company, that was Quite a big problem because people were just moving off of our tools once it became serious for them. And we started to think about, okay, how How do we want to evolve our tools to actually fit the needs of the developers when they also need to evolve and scale their applications? Yeah. So right when Their products are starting to make money,

and they're they're ditching your service, which, obviously, isn't great for business. Right? Yeah. And you guys were pretty early in, like, serverless

as well. I remember writing. I was like, How do you do custom logic? And they're like, well, that's a I don't know what you call it, a function or something like that. Serverless. Right? Yeah. That was That might have been, like, the 1st serverless function I ever wrote was in GraphQL way back in the day.

Yeah. Indeed. We had This integration with serverless functions that if you needed some custom functionality in your GraphQL schema, that you could just define what The query or mutation in the GraphQL schema should be called. And then in our, GraphQL web editor, you were able to write JavaScript, and we would deploy that for you as an AWS Lambda, and under the hood executed for you whenever you needed that Particular, function, like, on the front end.

So, yeah, that was also one part, but it also illustrates, the the problem, again, we had with GraphQL. And that was that, like very rarely applications Actually can be satisfied on the long term with this generated CRUD API that we gave you there.

We just learned that a lot of developers needed a lot more flexibility to how they exactly they wanted to structure their API, Which parts they wanted to expose, that they didn't want to expose, for a lot of them, it was a big problem that the data model and the database would map 1 to 1 to the GraphQL schema and the types in there, that was a a big problem for a lot of our users as well. And, Like, frankly, like, this idea of integrating serverless functions to execute custom business logic, it sounds great, But in terms of developer experience, it really wasn't.

And, up until this day, I think it's it's not the best approach to just Kind of, like, have, an auto generated API and then add this the these extra serverless functions for for kind of business logic. It's still cumbersome. It works maybe when you have an app that really only needs crowd functionality. But as soon as you build something serious, I think a lot of developers will want to really have full control over Their schema and their business logic. Yeah. I can totally see that.

So moving on to Prisma one then.

Yes. What was that?

So once we realized that GraphQL isn't really the the sustainable kind of business on on which the next, Twitter or Airbnb would be built, we decided to, take the core of what was Graphcool back then. It was this we called it the engine, and like this engine was written in Scala and it was basically a proxy server, an HTTP server that you could put on top of a database And that literally turned your database into a GraphQL API.

So this proxy server was called the Prisma server.

That was the core of Prisma one.

The problem with that entire architecture was that The GraphQL API that was exposed by this Prisma server was never intended to be used by front end developers.

But rather, it was intended to be used by back end developers who were implementing their own GraphQL API using A server like Apollo Server, GraphQL Yoga, or even just Express GraphQL to implement their own GraphQL API but abstract the database in a way that they don't have to worry about making SQL calls to the database, about working with database connection. So we abstracted all of this nitty gritty that actually, revolves around the database. We abstracted all of that away in GraphQL, and exposed with GraphQL API, but it was intended to be used by back end developers. And, of course, that was incredibly confusing for a lot of people because When a front end developer, I think, hears the word GraphQL, they immediately think of this one endpoint. They immediately see the GraphQL playground, and they, think about all the flexibility they have, in in now kind of exploring the API and the queries and mutations that they can send.

So it was very confusing for people, the the way how we architected Prisma one. And, What we did then was we we kind of learned again from our users that the biggest problem that we were solving for them wasn't necessarily the ease of Standing up a GraphQL API, but rather that they didn't have to worry about database workflows anymore. Because instead of Writing SQL migrations, they could define their database schema using GraphQL SDL, which is very intuitive and makes it very easy to define You are models, your relationships.

And so we realized that this was 1 problem that we solved for people. And the 2nd problem that we solved for people was that they didn't have to write SQL queries anymore because they would now get GraphQL as an abstraction.

And in fact, we also provided these libraries, these extra libraries back then called Prisma binding and later Prisma client, Which already gave you a JavaScript abstraction or a JavaScript implementation to access the underlying GraphQL API so that As a developer working with Prisma one, you wouldn't even have to realize that you're talking to a GraphQL API because it was all provided And utility functions in JavaScript, basically, for you. Yeah. That's really interesting. I I was a user,

of of Prisma around this time, and I remember why I, like Wes, had used it with GraphQL. So when this transition first happened, I remember feeling like, wait. What is this now? This Feels like it's a a totally different thing, which it is. Yeah. So but so, we've now gone from Graphcool to Prisma one. Mhmm. Where is Prisma today, and how did it get there?

Right.

So Once we had this realization that we were actually solving database workflows for developers and not the quick provisioning of a GraphQL API, we realized, Okay. Actually, we are now competing with other ORMs or other ways, how people work with their databases.

So in the JavaScript ecosystem, there is SQLize, which is a really popular ORM. There is Type ORM for TypeScript.

And, if you want to work on a lower level, there are SQL query builders, like, knextjs, for example.

These were the the typical ways how developers were used to working with databases in a node back end.

And, These libraries, you just run npm install to include them inside of your application and then they provide you with a couple of workflows. But it's really that simple, as running npm install to use them. For Prisma, 1 on the other hand competing with all of these simple libraries, you had to stand up An extra proxy server using Docker.

You had to, like, figure out how to host this server.

You had to monitor it. You had to upgrade it.

So, a lot of liability that just came from hosting this extra Prisma server. But for a lot of people that said, okay, I just need an ORM. Why should I Go through all of this hassle, standing up this extra server, this doesn't make any sense. I'll just go with SQLize or Type ORM with these, more proven solutions here.

So we realized, okay, if we are competing with these RMs then Prisma can't stay the way it is. And we probably have to go for an entire rewrite.

And we started rewriting it from Scala into Rust.

And, we we turned it into a tool that really now also is just an ORM. So just like Pipe ORM or SQLize, You can install it into your project with npm installed Prisma that installs the Prisma CLI.