Nexus and Code-First Schemas with Jason Kuhrt

Episode Description

Jason Kuhrt discusses Nexus, its journey to 1.0, how it enables type-safe GraphQL schema building, and Prisma's evolving open-source strategy.

Episode Summary

Jason Kuhrt from Prisma joins the podcast to discuss Nexus, a library for building type-safe GraphQL schemas in TypeScript, and its recent milestone release of version 1.0. He traces his own path into the Prisma ecosystem, starting as an open-source contributor working on GraphQL Gen before shifting focus to Nexus after Prisma adopted it as their recommended approach to type-safe GraphQL APIs. The conversation explores the technical distinctions between SDL-first and code-first schema building, with Jason explaining how Nexus provides enhanced type safety and developer productivity through autocomplete and compile-time checks. He walks through GraphQL's abstract types—unions and interfaces—and how Nexus makes them safer to implement. The hosts compare Nexus with frameworks like Redwood, clarifying that Nexus is a focused library rather than a full-stack framework, fitting modularly into existing backend stacks. Jason details the key 1.0 changes, including improved abstract type strategies and cleaner nullability and list helpers, while noting that Prisma is increasingly framework-agnostic, supporting SDL, Nexus, and TypeGraphQL equally. The discussion closes with reflections on open-source sustainability, the open-core business model, upcoming Prisma features like Migrate and potential MongoDB support, and the broader challenges of database workflows.

Chapters

00:00:00 - Introducing Jason Kuhrt and the Road to Nexus

Jason Kuhrt shares his background and how he became involved with the Prisma ecosystem. Starting at a company in Montreal where he was prototyping GraphQL APIs, he gravitated toward type-safe tooling and discovered Prisma's database layer alongside a tool called GraphQL Gen, maintained by Prisma's Johannes and Flavien.

His open-source contributions on GraphQL Gen led to deeper collaboration with the Prisma team. When Prisma pivoted to endorsing Nexus—originally created by Tim Grieser—as the recommended way to build type-safe GraphQL schemas, Jason followed suit. He eventually joined Prisma full-time, where his initial mandate was to help develop Nexus and its plugin ecosystem alongside Flavien.

00:02:48 - Nexus Origins and the Prisma 1 to Prisma 2 Transition

The hosts and Jason clarify common misconceptions about Nexus's relationship to Prisma. Nexus was never part of the Prisma 1 stack; rather, it emerged as a bridge for Prisma 1 users transitioning to Prisma 2, which decoupled itself from GraphQL entirely. The Nexus Prisma plugin allowed developers to map database models into GraphQL APIs with type safety and optional CRUD generation.

Christopher shares his experience using Prisma 1 with Nexus and notes the significant improvement Prisma 2 brought. Jason explains that while Prisma 1 was tightly coupled to GraphQL as its own endpoint, Prisma 2 became database-focused and agnostic, with Nexus serving as an optional, modular layer for those who still wanted a GraphQL story on top of Prisma's ORM.

00:06:39 - SDL-First vs. Code-First and Comparing Nexus with Redwood

The conversation turns to the different approaches for building GraphQL schemas, comparing Nexus's code-first methodology with SDL-first approaches used by frameworks like Redwood. Jason distinguishes Nexus as a library rather than a framework, noting it slots in at roughly the same level as GraphQL JS but with a more ergonomic and type-safe API.

Anthony notes that Redwood evaluated Nexus but chose SDL for its readability, while other projects like Bison adopted Nexus. Jason acknowledges both approaches have merit, and the discussion highlights how Nexus's code-first style may feel more complex initially but offers finer-grained control and better tooling integration for TypeScript-heavy workflows.

00:09:13 - Understanding GraphQL Types: Unions, Interfaces, and Type Safety

Jason provides a technical walkthrough of GraphQL's abstract types—unions and interfaces—and how they enable polymorphism in schemas. He uses practical examples like a media search returning images, videos, or songs to illustrate unions, and vehicles with shared properties like wheels and windows to explain interfaces.

The discussion extends into why type safety matters for developer productivity. Jason explains that Nexus's typed resolvers provide autocomplete and null-checking in VS Code, eliminating the need to look up field definitions or remember whether arguments are optional. Christopher offers an analogy with toll booths to make the union and interface concepts more accessible for listeners.

00:13:43 - How Nexus Types, GraphQL Types, and TypeScript Types Interrelate

Anthony asks Jason to untangle the three layers of types at play: TypeScript types, GraphQL schema types, and Nexus type definitions. Jason explains that Nexus exports functional type-definition builders that map to GraphQL's type system—objects, input objects, unions, interfaces, and enums—which get passed into a makeSchema function that produces a standard GraphQL JS schema.

He emphasizes that Nexus is a very thin runtime layer over GraphQL JS, making it highly interoperable with existing GraphQL JS types and scalars. At build time, Nexus types effectively dissolve, leaving a vanilla GraphQL schema. The TypeScript types generated by Nexus serve the developer experience in the editor, while the GraphQL types serve API consumers at runtime. A brief tangent touches on AWS AppSync and the fast-moving GraphQL ecosystem.

00:17:24 - Nexus 1.0: Key Features and Breaking Changes

Jason discusses the long-awaited Nexus 1.0 release, explaining that the library's core had been stable in production for quite some time. The team used the pre-1.0 period to land final breaking changes, including significantly improved abstract type implementation strategies that leverage Nexus's runtime TypeScript type generation to guide developers through union and interface setup.

The other major improvement was to list and nullability expression, which previously had an awkward API. New chainable helpers—nullable, non-null, and list—make it much easier to express GraphQL type modifiers. Jason notes that for users already on recent pre-1.0 versions, the upgrade feels incremental rather than disruptive, which was intentional to avoid leaving the community behind.

00:21:16 - Documentation, Prisma's Evolving Relationship with Nexus, and Framework Neutrality

Anthony praises the improved Nexus documentation, recalling the confusion of two separate doc sites during earlier iterations. Jason acknowledges the low bar they started from and highlights new tutorials, guides, and runnable CodeSandbox examples. The conversation shifts to Nexus's evolving position within Prisma's ecosystem, with Jason explaining that Prisma no longer privileges Nexus over other approaches.

Prisma's GraphQL landing page now gives equal footing to SDL, Nexus, and TypeGraphQL. Christopher and Jason discuss the importance of this neutrality, with Christopher emphasizing that developers should evaluate tools objectively rather than following trends. Jason adds that the rapid pace of open-source development means past judgments about tools may need periodic reassessment.

00:25:36 - Life After 1.0, New Teams, and Upcoming Prisma Features

With Nexus 1.0 shipped, Jason shares that his focus is shifting to new projects at Prisma. He's moving to a Developer Productivity Team exploring Prisma's commercial offerings around collaboration and workflow tooling. Meanwhile, Tim Grieser continues contributing asynchronously, and the community may drive future features like schema directives for Apollo Federation support.

The discussion touches on MongoDB and NoSQL support for Prisma 2, with Jason suggesting 2021 could be the year. Anthony notes that Prisma aims to build a generalized document database layer rather than a Mongo-specific driver. Jason also highlights the recent Prisma Migrate release as a major milestone, while noting that database workflow challenges like schema branching and preview databases remain largely unsolved across the industry.

00:29:36 - Open Source Sustainability and the Open-Core Business Model

Christopher raises the tension between open-source demand and business sustainability, asking whether Prisma's success stems from its open-source nature. Jason argues that building an ORM behind a paywall would have been nearly impossible given the market's lack of precedent for paid ORMs, making open core a practical necessity for gaining adoption and building trust with early adopters.

The group reflects on the broader state of open-source economics, noting that developers routinely build on vast amounts of unpaid-for code. Jason expresses hope that mechanisms like GitHub Sponsors and open-core models can make sustainable development possible, with larger companies effectively subsidizing access for smaller teams and individuals. The episode wraps with Jason pointing listeners to Nexus and Prisma's Twitter accounts and his personal GitHub for other TypeScript projects.

Transcript

00:00:00 - Christopher Burns

I actually like hearing my own voice when I speak, because I'm just a narcissist that likes my own voice.

00:00:17 - Anthony Campolo

Hello, Jason. Thanks for joining us here on the podcast. You work at Prisma, and you've had a hand in creating Nexus. We've talked about it a little bit on the show, but we'd really like to dive more into it. Why don't you tell us a little about yourself and how you got involved in all this?

00:00:34 - Jason Kuhrt

Awesome. Thanks for having me. I've been at Prisma for just over a year now, about a year and three months. When I first got involved with Prisma, it was actually through trying to build GraphQL APIs at a company, my former company in Montreal. We were getting prototyping stage work done and looking at how to do things in a type-safe way.

So we went through, I think like a lot of people in the Node ecosystem, the Apollo Server world and the SDL-first approach of building schemas in GraphQL. But as a TypeScript fan, I noticed I wasn't getting the type safety that I wanted. I was also using Prisma on those API prototypes and was really liking the work Prisma was doing on the database layer side.

Johannes, who at the time was the CEO of Prisma, and Flavien, who is a colleague of mine at Prisma, had a tool called GraphQL Gen, which generated TypeScript types based on the GraphQL SDL.

[00:01:29] So this was working in the Apollo Server workflow. I got involved in that project early on, in October 2019. That got me in touch with Flavien and Johannes, and I started collaborating as an open source contributor in the Prisma ecosystem.

Around the same time, Johannes got in touch with Tim Grieser, who's the original creator of Nexus, and was really interested in what Tim was doing. Prisma started to pivot toward that tool as the recommended way to build type-safe GraphQL APIs, and they let their homegrown tool, GraphQL Gen, go. I was left looking for what to do next and said, okay, I'll try this Nexus thing, since that seems to be what they're betting on.

Fast forward some months later, I got in touch with Johannes again in the summer of 2019, flew down to Berlin, and he was looking to get some more engineering help on the open source stuff that Prisma was working on.

[00:02:23] Prisma was an early backer of Nexus. Flavien did a lot of the early work with Tim Grieser, and he did the first plugin for Nexus for Prisma. He was working alone, and Johannes was involved, but obviously had to run the whole company, so wasn't involved day to day the way Flavien was.

My initial mandate at Prisma was to start helping out Flavien and all this open source stuff, primarily the Nexus aspects. So that's the backstory there.

00:02:48 - Anthony Campolo

Very cool. Nexus is a project that is really interesting because, as you said, it's gone through a couple iterations here, and other people were going for similar things. I had thought that Nexus was kind of the GraphQL part of Prisma, one that got abstracted out, but it sounds more like someone created something that did it better. So they're like, oh, let's drop our GraphQL thing and start doing this.

00:03:13 - Jason Kuhrt

Yeah, I've heard that one too. There's been a lot of product iteration at Prisma, so it's a storied history that can be difficult to tease apart. This is a very decoupled aspect here, where Nexus never really was part of the Prisma 1 stack. The part that was in common was just the GraphQL aspect, right? Prisma 1 was tightly coupled to GraphQL. Prisma 2 has nothing really to do with GraphQL.

Prisma 1 was basically exposing GraphQL APIs over the database. As Prisma 1 transitioned to Prisma 2, Nexus looked like an interesting way to ask, how does Prisma 2 relate to GraphQL in new ways? That made it so there was a bridge forward for Prisma 1 users. Prisma 1 users were also GraphQL users. Implicitly, Prisma 2 became more agnostic, but we still wanted a positive story there because that is still an important part of the community for Prisma even today. Nexus was a nice fit there.

[00:04:04] That had the modularity that we were looking for.

00:04:06 - Christopher Burns

I have actually used Nexus and Prisma 1. My experience was a bit jaded.

00:04:14 - Jason Kuhrt

Sure.

00:04:15 - Christopher Burns

It just didn't quite give me what I wanted. I can happily say that Prisma 2 knocks it out of the park.

00:04:21 - Jason Kuhrt

Cool.

00:04:22 - Christopher Burns

That's good. I had Nexus 0.11.7 and Nexus Prisma. That was 0.3.7. I can't quite remember when support ended. Or has it ended for Prisma 1?

00:04:39 - Jason Kuhrt

There was a Prisma plugin for Nexus for Prisma 1, which went up to version 0.3.7 of the Nexus Prisma plugin.

00:04:49 - Christopher Burns

I was on the last version.

00:04:50 - Jason Kuhrt

Yeah, you were right at the cusp there. I think we refocused towards Prisma 2 in October 2019 or so. I was not a heavy Prisma 1 user, so I don't have that experience as much under my belt.

But the Nexus Prisma plugin provided a bridge to bring back some of the workflows around exposing very quick access, like CRUD access, to models in your database through the API. That isn't always a best practice, but it can be a nice way to get started quickly. And for some types of projects, it's totally fine.

There is nothing about this built into Nexus itself, which is very generic GraphQL schema building without any strong opinions built in. But the Nexus Prisma plugin creates awareness around the Prisma schema and then starts allowing you to, in a type-safe way, map the models in your Prisma schema into your GraphQL API. And of course, as I mentioned, the CRUD aspect.

[00:05:45] So being able to create, say if you have a user model, then create a user, update a user, delete a user, stuff like that. Putting Prisma 2 together with Nexus and the Nexus Prisma plugin, it starts to approximate, very roughly, what you might have gotten out of Prisma 1.

00:05:59 - Christopher Burns

How it used to work. Prisma 1 was its own GraphQL endpoint.

00:06:05 - Jason Kuhrt

Yep.

00:06:06 - Christopher Burns

Nexus was the resolver part of the GraphQL structure. So your client is going to speak to Nexus. And then Nexus Prisma would connect and talk to your Prisma 1 endpoint, right?

00:06:23 - Jason Kuhrt

Not exactly.

00:06:24 - Christopher Burns

Not exactly, but close.

00:06:26 - Jason Kuhrt

Yeah, I guess you could have a Prisma 1 endpoint that you have your own service in front of and proxy requests through.

00:06:33 - Christopher Burns

Yes.

00:06:34 - Jason Kuhrt

I have never actually done that or talked to people who have done that, but I guess that's something people were doing. And so they could totally do that.

00:06:39 - Christopher Burns

Yeah, I liked Prisma 1, but ever since Prisma 2 came out and I've used Prisma 2, I've just kind of forced my memory to forget. I think one of the main points with GraphQL Nexus is it's not the only way to do GraphQL CRUD applications.

00:06:54 - Jason Kuhrt

For sure.

00:06:55 - Christopher Burns

Things like Redwood choose to use their own solution of SDLs. Bison uses GraphQL Nexus. I don't know how much you know about the Redwood solution for mapping resolvers. What would really be the pros and cons to using an SDL-first way?

00:07:16 - Jason Kuhrt

I'm not an expert on Redwood by any stretch, but at a high level, one of the big differences is the scope of the project. Redwood is a framework and Nexus is a library. Some listeners may remember there was this thing called Nexus Framework, but we're totally ignoring that right now.

So Nexus is a library, and it just fits into your stack in a much more modular way, almost at the same level as how you would just use GraphQL JS. It's a little bit higher level in terms of the API. It's a bit nicer to use, it's very type-safe by comparison. The scope is really just the schema building part. You can't really fit Redwood in all the places you might fit Nexus. Redwood is, of course, a full stack framework, not just a back end framework.

I think the use cases don't overlap too much if you're just a back end team. It might not make sense to use Redwood. But if you're a back end team and you just want to build a server and you're expecting something like Express or NestJS, a classical backend API, then Nexus is probably going to feel pretty natural.

00:08:22 - Anthony Campolo

Yeah. The Redwood team evaluated Nexus as a piece that they would have incorporated. I think the reason Tom had said he just liked the readability of the SDL. I kind of see both sides here because I do really like an SDL where you just see, like, post ID, title, body. It's really simple. It's pretty easy to parse.

When you look at something like Nexus, there is a lot more going on. But at the same time, if you want more detail and you want more fine-grained control, then that's really nice.

When I first heard about Nexus, it didn't make any sense to me at all. The reason why is because I wasn't super familiar with types. I like the concept of typing in general. That's really what a lot of this is based around. Stuff like union types, query types, backing types. We talked about some of this terminology for people who might not be as type fluent.

00:09:13 - Jason Kuhrt

There's a lot of types going on, and it doesn't help that you're building types in the schema with type-safe APIs. In TypeScript, there's a meta thing there, right? So when you're building a GraphQL schema, you're essentially dealing with a small set of different types.

Unions and interfaces are abstract types, which allow you to express polymorphic aspects of the GraphQL schema. A really simple example is in a GraphQL schema, you might have a query for search, and the result of the search field might be multiple types of things that can be found. So maybe some kind of media search and you can get back images, videos, or songs. These are three distinct models or objects, as they would be called in GraphQL in the schema, and they don't share the same fields. That union can be a way to express that the search field can return any of these things, but you're not sure what you're going to get at runtime.

[00:10:07] The other abstract type is interface types, and they're fairly similar to union types in that they are abstract. But the difference is that they do share something. You could have an apple and an orange and a pear, and there's nothing in common there. Whereas with an interface type, there is the concept that you're returning an interface, but the actual concrete types you get back will implement that interface. So what that means is all the members of this interface type are sharing a subset of fields.

The consequence of this is that as a GraphQL client, when you query a field which has an interface type, you'll be able to select the fields that are common to all members of the interface type, which is essentially what the interface defines. So the interface might say all members of the interface type are going to have A, B, and C, and A is a string and B is a boolean. And union types are a bit looser in the sense that there's just no guarantee there will be any overlap.

[00:11:02] So the clients cannot query common fields in the same way as interface types. You get those two flavors.

00:11:08 - Christopher Burns

You could say that you're at a toll road. You have one car, one bus, and one lorry. You split. So you say each one goes to each one, or you would have one toll booth that handles all three. All three of them would be your union type, saying it can either be a bus, a van, or a car.

00:11:30 - Jason Kuhrt

The interface type would maybe say that they all have wheels and they all have windows. And if you're only interested in asking about the wheels, how big is the wheel or how tinted is the glass, then you don't need to actually know what you're working with. You'll be able to get that information back for any of them.

So an interface type can be useful when you know the members of the interface type do share some common aspects. Union types are the sort of free-for-all. You don't need to care if there's anything related or not.

00:11:56 - Christopher Burns

Redwood writes them like an SDL, a string that defines them, but Nexus does it more object-oriented. And with object-oriented, like a function, you get type safety. How important is that?

00:12:13 - Jason Kuhrt

I think it's pretty important, but I'm biased. I think type safety provides two advantages. One is the safety, of course. The other is productivity, which tends to be counterintuitive because we think of type-safe, compiled languages as somehow being less fast or less productive than a fast scripting language. But it seems that this is changing these days.

The autocomplete experience you get out of VS Code, thanks to the typings, just makes things feel a little swifter. You're going to get a resolver and you're going to know what the source type is coming through. Like what you were saying before, the backing types, we call these source types now. We standardized the terminology recently. It aligns, for example, with how GraphQL JS calls them in their own implementation. Source types are the first parameter to resolvers. Then you have the args, and then you have the context.

[00:13:02] So resolvers all have this common signature. Having that all typed safely both makes it easier to have reliable software and, when it comes time to implementing, you're not going to need to go looking around or remember what the inputs to a particular field were. They're just there in the args to autocomplete any nuances.

You're like, was the field optional or not? The type safety will have your back there because you'll have a null type in there that you have to deal with. TypeScript is just going to yell at you if you don't deal with the null properly in your resolver. These kinds of things can make it safer ultimately, but also save you time by not having to go look up whether something was optional. It's just there in your face.

00:13:43 - Anthony Campolo

So what I'm curious about is you were talking about how there's a couple different types of type definitions going on here. We have TypeScript, we have GraphQL types, and then is there Nexus type definitions? Is that another separate thing? So what are all these different types and how do they relate to each other?

00:13:59 - Jason Kuhrt

The Nexus package exports a number of type definition builders, essentially. And it's all functional. There's not a lot of instantiation of classes or anything. It has these pure functions that return values, and these type builders map to what GraphQL has in the type system: objects, input objects, unions, interfaces, enums. That's basically it.

From there you have fields on these things, of course, and whatnot. You basically just import these type definition builders and then they return constructed types that you pass into makeSchema. Nexus has a makeSchema, which returns a GraphQL schema that you can put into any server or whatever you want. You define types, pass them to makeSchema, get a schema, and pass that into your server.

The Nexus types are distinct from the GraphQL JS package types. They are not the same classes.

[00:14:53] But in almost all cases, the Nexus types are just very thin layers on top of GraphQL JS types, providing some of the type safety and adjusting the way that inputs might work, like nullability by default and stuff like that. But there's really not much going on at runtime over the GraphQL JS package. You can have a type reference, a GraphQL JS type. It's quite interoperable because ultimately all Nexus does is say, oh great, you gave me a GraphQL JS type. I'll just pass that through to the schema.

So this makes it easy to plug in GraphQL JS scalars. Or if you have a hybrid application and you're maybe migrating from one state to another, you have some of the codebase written in an older GraphQL JS way. These things are fairly interoperable.

If you're dealing with a normal application from scratch, you're just going to have the Nexus type definitions. This will be creating your GraphQL schema.

[00:15:44] And then that has the GraphQL types in there at runtime, which is what your API clients, your applications that are calling your API, will see. The TypeScript types are what you see as an API developer in your VS Code experience. But from a runtime perspective, even the Nexus types are basically getting stripped away at build time.

Well, at build time, at boot time, basically, Nexus runs, and what it's ultimately returning is just a vanilla GraphQL schema, which is built of GraphQL JS types. So it's a very thin layer.

00:16:13 - Anthony Campolo

Yeah, it's really interesting. It's like TypeScript for GraphQL almost. Yeah, like conceptually. Have you ever checked out AWS AppSync? They're a managed GraphQL service.

00:16:25 - Jason Kuhrt

It's been a while. I remember looking at it maybe almost two years ago, around the time it was announced. I think it's changed a lot, so I'm pretty out of date now with what it's capable of. I've heard it's got everything and the kitchen sink going on over there. It's a powerful suite.

00:16:43 - Anthony Campolo

It's become really heavily integrated with the whole Amplify thing. So if you use Amplify, you can connect a lot of AWS services together. And AppSync is essentially replacing what API Gateway did.

00:16:57 - Jason Kuhrt

Okay.

00:16:57 - Anthony Campolo

But in a GraphQL way instead of an HTTP way. So it's like the glue layer that's connecting a lot of pieces. And you can do the same thing. You can take schemas and you can generate all sorts of stuff with it.

00:17:08 - Jason Kuhrt

Nice.

00:17:08 - Anthony Campolo

This whole space has a lot of stuff happening.

00:17:11 - Jason Kuhrt

Yeah, totally. It's hard to keep track. I feel it's not quite as fast-paced as front end, but it still feels like the kind of thing that if I don't look for a couple months, I need to go figure out what's going on and I feel left behind.

00:17:24 - Anthony Campolo

It's so heavily integrated with front end now that you're kind of getting pulled along. Everyone's getting pulled along with this whole front end train.

You guys recently got Nexus to 1.0, which I thought was pretty cool. So what is the impetus for the major version change?

00:17:39 - Jason Kuhrt

That's a long time coming. I remember even talking about 1.0 with Tim like a year ago, because it's been used in production now at quite a few places for some time. Tim Grieser works at Cypress.io, and he's a technical director there and has had Nexus going for a really long time.

The Nexus library has not undergone fundamental change for quite a while. Incrementally, at the end of 2019, one of the biggest things that shipped were plugins. And now it's been a year that we've had plugins. This year, nothing major changed. There were quite a few tweaks, but it was clear that there was a core there that we felt had been tested with time and was ready to go out into the world under 1.0.

So what we've done over the past few months is get some of the last breaking changes that we really wanted to do before 1.0. We raced to try to do as many of those as we could.

[00:18:36] If you were already on 0.19 or 0.18, the 1.0 jump just feels like a normal little release because, again, the core has been there for a long time.

00:18:46 - Anthony Campolo

And that's good because you don't want to do 1.0 and leave everyone behind.

00:18:51 - Jason Kuhrt

Yeah.

00:18:52 - Anthony Campolo

It sounds like what you did is going to be fairly similar to what Redwood 1.0 is going to be like. You reach a level of polish where you feel comfortable calling it 1.0.

00:19:01 - Jason Kuhrt

Oh yeah. The highlights of what we've shipped in the last few months: the two biggest changes were making abstract types safe to implement, which they were before, but a bit rough around the edges, especially for newcomers. They have to learn what abstract types are in GraphQL and how to implement them. It's intimidating.

Now Nexus has this concept of abstract type implementation strategies. We haven't discussed it, but basically one of the novel things of Nexus is that under the hood it's generating TypeScript types based on how you've actually written your GraphQL schema in code.

It does this generation step at runtime at the very beginning when you boot your app, and it does it at dev time. So you wouldn't do this generation in production, but at dev time it's fine. And so you have these TypeScript types being generated in the background. There are three strategies to choose from, and you can choose which one you want to be working with in your application. This is just how we do typegen. Then you get a polished, guided experience from a type perspective on what it is you need to do.

[00:19:57] So when you define a union type, what are the required methods that you're going to have to implement to make that work at runtime? This is completely type-safe now. Pretty happy with the result.

The other big change for 1.0, relatively speaking, is lists and nullability. They were a bit painful to express and unintuitive. If you wanted to express that you had a list type and the members of the list type were non-nullable, so guaranteed to be there, it just had an awkward way to express that. Now we have these little functional helpers that you can also chain: nullable, non-null, and list. This is a much easier way now to express what GraphQL calls type modifiers.

There were a lot of improvements to docs and things like that too, but those are the features that were noteworthy in the last few weeks.

00:20:44 - Anthony Campolo

The docs are definitely something I'm interested in because when I first started looking at Nexus, this was back in May. There were two doc websites. I think you were migrating from one to the other. The only difference was there was a period in one and not in the other. I imagine a lot of the content was similar, but they had different styles.

So I remember at the time going into this library that was already very confusing to me, and then not understanding the docs at all, just being like, oh my God. And I've been looking at your docs today, they look really good. You guys definitely put a lot of work into them.

00:21:16 - Jason Kuhrt

Thanks.

00:21:17 - Anthony Campolo

Very well organized. You guys have examples now, and it's really cool.

00:21:20 - Jason Kuhrt

It was a low bar in some ways to improve, but I think even by general standards, there's always things to improve. There are still some sections to do, but there are some good guides in there. Now there's a proper tutorial and there's not two websites. And we started picking up CodeSandbox to provide some examples that you can run. I think the coherence now is a lot better than it was a year ago.

00:21:41 - Christopher Burns

Nexus wasn't created by Prisma. Prisma is one of the maintainers. You think Prisma, you now think of Prisma 2. That's now Prisma 2, according to what the website says, and that's obviously debatable.

00:21:54 - Jason Kuhrt

Yeah.

00:21:54 - Christopher Burns

Would you say that Nexus would be the opinionated way Prisma would define itself if it was to include more front-facing services, like a whole API, for example?

00:22:11 - Jason Kuhrt

Interesting. I think as Prisma 2 matures, the answer would be no. Now it's becoming more and more open to interop with all the frameworks, the stacks, basically, to the extent that it can. I think where it can't coexist as well is going to be with other ORMs, where there's an inherent trade-off of like use this or this. Using both just doesn't make sense.

But otherwise, in most parts of the stack it's trying to become quite accommodating. There's a Prisma GraphQL landing page, for example, to bring in that audience. We've got three tabs: SDL, Nexus, and TypeGraphQL, which is a TypeORM-ish way of doing it with entities and use of TypeScript decorators on class fields and methods. So none of these are being seen anymore as necessarily privileged. And sometimes it comes up, like, why does Nexus have that pedestal at Prisma?

[00:23:06] It doesn't really fit anymore. And I think that's fair because it's not the intent anymore. I think we have inherited the maintainership, or part of it, of Nexus to this day, and we want to be good stewards there. But I don't think there's a vision where Nexus is seen as necessarily better all the time or has to be better.

It's a way where there's a natural alignment, and we're biased, of course. There's a natural alignment with the way that TypeScript is a first-class citizen and everything goes through the lens of, is this a type-safe, productive way of working with TypeScript? So that's like with Prisma Client. What you get is different because it's code generation, not just type generation, but the end result is that you get typings with Prisma Client, the ORM, that are completely customized to the way you've defined your database schema.

And so that clearly has an analogy with how we're working with Nexus. Its typings are completely reflective of how you've defined your GraphQL schema, your API schema. I think people that love what Prisma is doing in terms of type safety will perhaps also appreciate what Nexus is doing. But again, I don't think there's really any technical coupling. And like I said, even on those landing pages now for bringing in those audiences, we're open to meeting developers where they are and really appreciate that.

00:24:27 - Christopher Burns

That's really important because when I worked with Prisma 1, it almost felt like Nexus was the sister, the thing you use to complete the system. Prisma 2 is more decoupled and now more optional. Redwood decided to go with the SDL approach. Bison has gone with Nexus.

Open source is hard, and when do you choose to give it up? When it's no longer what the company is focusing on. We all connect with different mental models differently. For me, SDLs work, but for someone like Anthony, code-first would work. And this is why I always go back to whenever you start a project, you can't just go with your biases or what you've heard is good. You need to look at it. Be objective. Find out what works best for you and then go from there.

00:25:18 - Jason Kuhrt

Absolutely. And I think also look at things that we've seen in the past, assuming they've iterated and evolved. Sometimes it requires new judgments as well. A lot of open source is moving so fast right now that every six months I'll re-review everything because the old judgments, probably half of them, won't apply anymore.

00:25:36 - Anthony Campolo

Definitely interesting time. Are there other things you work on at Prisma aside from Nexus?

00:25:42 - Jason Kuhrt

With 1.0, my colleague and I, who were the two main people at Prisma spending engineering time on Nexus, have some other projects to focus on. We'll see how things go. If 1.0 goes well, I don't think there will be any, but if there are any imminent bugs, those will be fixed and addressed. But I think from a feature perspective, we'll let things ride for a little bit and see.

Tim Grieser is working completely asynchronously here, so there's always things he might bring to the table at any time. From our point of view, we're probably going to let 1.0 sit for a little while as it matures and we see how the community reacts and builds up new motivations, like schema directives from within Nexus. And that would open up, for instance, Apollo Federation, which is still difficult to do, if not impossible, with Nexus.

That might continue to appear to be something the community really wants. But for all intents and purposes, for now we're going to be working on moving to the client team, doing stuff with Rust and the Prisma Client. And I've moved to a new team called the Developer Productivity Team.

Some of the things we're looking at are: what is Prisma's commercial offering going to actually be, and what are the tools there for collaboration and workflow that we might want to develop? So it's pretty exciting, pretty open, and undefined. Still, even if I wanted to, there's not much I can say because it's literally my first week.

00:27:02 - Anthony Campolo

So Brandon Bayer from Blitz, he recently took Prisma Studio and self-hosted it himself on PM2. So clearly there's people out there who want to be able to spin up a Prisma Studio thing in a really easy way and use it, you know?

00:27:19 - Jason Kuhrt

Totally. Yeah. I think database workflows are pretty painful today. Still, you think about how easy it is to spin up a branch and get some preview deployments for an API or site with, say, Next.js or pretty much anything. You can roll it yourself or use Netlify, whatever.

And the same is just not true for most database workflows where, hey, can I just branch the schema and do some iterative work and then merge it back and have four teams or four team members doing that at the same time with preview databases? All that stuff is still really rough. So I don't know if we're going to be doing anything about that specifically, but I hope things like that get better.

00:27:56 - Christopher Burns

One of my questions that I think would be hilarious to ask someone that works at Prisma, but it's probably not number one. When is Mongo support getting here on Prisma 2? And number two, when's NoSQL support getting here? In Prisma.

00:28:12 - Jason Kuhrt

Well, it sounds like we can get two for one with Mongo there. It comes up a lot. I think maybe 2021 will be the year it happens, so stay tuned.

00:28:21 - Anthony Campolo

I heard recently that the reason why it's taking so long is because you are going to figure out a general way to do document databases, not just Mongo. You could do just a driver for Mongo, but the point is you want to be able to model a more general type of database. DocumentDB is another one, so there'd be a lot more interop there.

00:28:43 - Jason Kuhrt

So I'm not on the team that works on that, but I think there's probably a lot of truth in that. Just looking at how the SQL has been rolled out, right? We have Postgres, MySQL, and Microsoft SQL coming soon. There's a reason that order happened because of the similarities between those databases. Not that they're the same and therefore didn't take engineering work each time, but there's a core there for sure.

I think in the same way that maybe Mongo, Dynamo, and others are not the same, obviously, there's probably some core work that will help there. So maybe the first one is going to be some of the most challenging work that will not need to be repeated every time in the future. But they're all complicated beasts. We'll see. It would be awesome if we could get some really great core in there for more rapid rollout in the future.

00:29:36 - Christopher Burns

The only reason I joke with those questions is open source is really hard, and the most ignorant thing you can do sometimes is, not in a bad way, but you can just spam a thread. When is Mongo support here? When is it here? It's not here yet. I really need it.

That's really important because it shows want and demand, but you're a company and profitability is really important. Sometimes that can be swept under the rug with open source. Do you think the success of Prisma 2 is mainly because of the open source nature in the underlying technology?

00:30:17 - Jason Kuhrt

That's a really good question. I think it would be hard to have built, we call it an ORM, but we know it's a bit fuzzy, we're fudging the word there. It's more like a query builder, but we'll use ORM. I think it would have been hard to have an ORM and get the exposure it needs to get widespread adoption behind a paywall, effectively.

So I think the approach of having done that in the open and freely available is somewhat necessary when you think about a market that doesn't really have a precedent for paid ORMs. And I'm not saying that Prisma Client can become a paid ORM. It's more that open core will start to have some value add for larger companies and teams that need workflow specific to those scales.

I think we're not unique in that way. A lot of companies start with open core, then they are able to build specialized workflows around that. I think it's a smart model. It's definitely not easy. Every company talks about the struggles to actually make it work in practice, but I think in principle it's an effective way to get early adopters and influencers trying things out.

Then when they talk about it, someone says, oh, okay, I'm curious now, and the bar to try it becomes very low. People do different things in trials or paywalled features, but each of these has trade-offs. Just having no time limit with all the features lets people get down to a real app. Everyone starts something, then they don't pick it up for four more weeks and they get back into it a bit deeper.

So I think for people's usage patterns, this is still one of the most effective ways, like open core.

00:31:55 - Christopher Burns

If I were to say, how would I ever pay for a service like Prisma? It would be: how close could it be to a fully managed API database where I don't even need to pick the provider? It just says your data goes in, your data goes out. That would be perfect for me.

It's this thing that I do think is mind blowing. Prisma is used everywhere in a CRUD application if you choose to be, and you've not paid a penny for it yet.

00:32:25 - Jason Kuhrt

That's kind of my take on open source in general. The amount going on and the things I can pick up and then move quickly on some project, and 99.5% of the code underneath me I haven't really paid for. I paid the most for this Apple computer or something.

That's both what's fascinating about the medium and also a challenge for people that want to do this for a living because we've lost the standard expectation that we will have to pay for this stuff. And so indie development, for example, it's interesting to see that changing over the last few years with things like GitHub Sponsors, and just actually the way people talk about it and how openly people are talking about it on Twitter or whatever. It's a discussion that feels like it's getting traction and attention.

00:33:13 - Anthony Campolo

Yeah, I'm on GitHub Sponsors.

00:33:14 - Jason Kuhrt

Nice. It is mind blowing, and I just don't know if it's sustainable. But I hope companies like Prisma can find ways to make the open core sustainable, because I love that it also allows people who maybe just don't have the access to pay up front, or the use case to pay up front, to still benefit, while larger companies that definitely can basically subsidize for the rest of us.

I don't know if utopian is the right word, but it certainly feels like [unclear].

00:33:41 - Christopher Burns

Best of both worlds.

00:33:43 - Jason Kuhrt

Yeah.

00:33:44 - Anthony Campolo

The opposite of a tragedy of the commons.

00:33:46 - Jason Kuhrt

Yeah.

00:33:47 - Anthony Campolo

Closing it out here. Is there anything else that you would like to talk about that you're excited about coming forward with Prisma?

00:33:54 - Jason Kuhrt

Well, Migrate just came out, and I'm excited to see that thing come because there was a version already for a while now that was in preview.

00:34:03 - Anthony Campolo

Oh yeah, we know. That's the one that's been in Redwood this entire time.

00:34:07 - Jason Kuhrt

That's it. I'm really excited to have that big revision out the door now, which will continue to be incrementally improved. I think it's a huge step for the company and for everyone that's enjoying the Prisma Client side of things, and hopefully enjoying what Migrate could already do. But I think this will be exciting to bring the company and the whole toolkit forward after Migrate.

Then I think workflows and collaboration are going to be a big topic for Prisma, but I think it's still a little bit out.

00:34:40 - Christopher Burns

Will Migrate ever handle data migration as well? Not only just table migration?

00:34:47 - Jason Kuhrt

I don't know. I don't know.

00:34:49 - Christopher Burns

That's a big question. But yeah, thank you for your time. This has obviously been so useful. Where can our subscribers reach out to you if they want to?

00:34:58 - Jason Kuhrt

Yeah, absolutely. So there's Nexus GQL on Twitter, Prisma's on Twitter, and my name, Jason Kuhrt, on Twitter as well. On GitHub I have the same handle, and I work on a couple of open source projects on the side. Come check that out. Mostly TypeScript, of course.

00:35:15 - Christopher Burns

Thank you so much for your time.

00:35:17 - Jason Kuhrt

Thank you.

00:35:18 - Anthony Campolo

Yeah, thanks a lot, Jason.

00:35:19 - Jason Kuhrt

Cheers.

00:35:50 - Jason Kuhrt

I hope it was clear. It's hard to vocalize some of the concepts.