Supper Club × ORMs with Nikolas Burk from Prisma

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.

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

which was the very first iteration of that.

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,

This is I sure hope you're hungry.

Oh, I'm starving.

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,

so buckle up and grab that old handle because this ride is going to get wild.

Storyblock,

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.

On your data source to help you build modern apps faster,

Advanced React course, I built it in Graphcool, And then when I rerecorded it about a year and a half ago, I You went with Keystone, which Keystone uses

all kinds of really interesting stuff. So, buckle up For that one, we're sponsored by 3 awesome companies today.

here to talk all about,

First one is Hasura. They give you an instant GraphQL API

the Syntax supper club.

So it was very confusing for people, the the way how we architected Prisma one. And, implementation

moving on to Prisma one then.

Yes. What was that?

that they can send.

As a developer working with Prisma one, you wouldn't even have to features and services such as authentication,

And in fact, we also provided these libraries,

we decided to,

they could define their database schema using GraphQL SDL, which is very intuitive and makes it very easy to define

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 and under the hood executed for you whenever you needed that Particular, So, yeah, that was also one part, and built their own GraphQL servers from scratch.

to access the underlying GraphQL API so that

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, So this proxy server was called the Prisma server.

That was the core of Prisma one.

or a JavaScript they immediately think of this one endpoint. They immediately see the GraphQL playground, and they, 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.

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

You are models, your relationships.

think about all the flexibility they have, in in now kind of exploring the API and the queries and mutations 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, 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.

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,

And that literally turned your database into a GraphQL API.

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

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

The problem with that entire architecture was that

So once we realized that GraphQL isn't really the the sustainable kind of business on on which the next, And, events, building example projects, all these kinds of things.

that We published the one point o version back in 2017, like, knextjs, for example.

where you would go online, you would open your web browser, you would go to graph.cool And what would happen then was that it would give you a database revolves around the database. We abstracted all of that away in GraphQL,

was an incredible

It was kind of comparable to a service like Firebase maybe or Paras back in the day, Writing SQL migrations, When a front end developer, I think, hears the word GraphQL, These were the the typical ways how developers were used to working with databases in a node back end.

a mechanism to define permissions on the data, You can install it into your project with npm installed Prisma that installs the Prisma CLI.

and that was really a GraphQL back end as a service.

was actually the domain. You would log in with your account and then you could define a data model.

In fact, with a lot of people that I talk to in our community who are new, 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, for a long time. Also, the docs were entirely my responsibility,

integrations with services like Stripe.

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 take the core of what was Graphcool back then. It was this we called it the engine, that you could just define what The query or mutation in the GraphQL schema should be called. And then in our, So these things that developers typically need when they build applications, but it was very much geared towards only front end developers But what we also saw was that

started out using GraphQL, And, since last year, my role has Kind of crystallized Twitter or Airbnb would be built, I've been wearing many headset Prisma for a long time. In the beginning, I, and then they provide you with a couple of workflows. But it's really that simple,

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, 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.

Prototype their GraphQL API 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 You had to monitor it. You had to upgrade it.

but then as soon as they wanted to build something real and deploy it to production,

Domain 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

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.

or other ways, these extra libraries back then called Prisma binding and later Prisma client, Which already gave you a JavaScript abstraction You had to, like, figure out how to host this server.

And, if you want to work on a lower level, there are SQL query builders, Moved off of GraphQL like very rarely applications the ease of Standing up a GraphQL API, but rather that they didn't have to worry about database workflows anymore. Because instead of GraphQL web editor, you were able to write JavaScript, and we would deploy that for you as an AWS Lambda, 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 function, that's when they actually went a lot of developers but it also illustrates,

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

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 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.

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,

Right.

we we turned it into a tool that really now also is just an ORM. So just like Pipe ORM or SQLize,

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

Okay. Actually, we are now competing with other ORMs

how people work with their databases.

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? ecosystem or or in in regards there. So do you wanna give us, like, a rundown

wait. What is this now? This Feels like it's a a totally different thing,

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,

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, 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,

So, I moved it over to Prisma 1.

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.

Still in this way and it being tightly associated with GraphQL.

of from F Cool to Prisma one to Prisma today,

Okay. Well okay. So now maybe we should get into

an ORM. And I say justice, and it's no longer tightly,

Awesome.

And yeah.

the the the evolution

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,

bound to a GraphQL

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,

worked on our front end as well. I've been responsible for a whole lot of the content that we've been putting out, 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

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 But let's take the step back and start at GraphQL These libraries, you just run npm install to include them inside of your application

and and how it's changed and evolved, and maybe, we can get into some of the reasons why.

Yeah. Indeed. We had This integration with serverless functions that if you needed some custom functionality in your GraphQL schema, And we started rewriting it from Scala into Rust.

that was a a big problem for a lot of our users as well. And,

Actually can be satisfied was able, was ever able to do it.

up until this day, I think it's it's not the best approach to just Kind of, like, have, And,

on the long term with this at Prisma, about working with database connection. So we abstracted all of this nitty gritty that actually, 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.

writing. I was like, How do you do custom logic? And they're like, well, that's a

the the problem, again, we had with GraphQL. And that was that,

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 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

generated CRUD API that we gave you there.

So

as well. I remember

like, on the front end.

way back in the day.

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, 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, So you could create a user model, maybe a post model, all of that in the web UI, and then you would hit deploy.

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.