The Changelog: Software Development, Open Source - Prisma and the GraphQL data layer (Interview)

Episode Date: May 16, 2018

Johannes Schickling, co-founder and CEO of Prisma, joined the show to catch us up on all things GraphQL — the tech, the possibilities, the community, how Prisma turns your database into a GraphQL API, their new business direction, Prisma Cloud, open source vs enterprise, and the upcoming GraphQL Europe in Berlin on June 15th.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at rollbar.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Rollbar. Move fast and fix things.

Resolve errors in minutes and deploy with confidence. Head to rollbar.com slash changelog. Request a demo. Get started today. It's loved by developers, trusted by enterprises, and most of all, we use it here at Changelog. Move fast and fix things with Rollbar. Once again, rollbar.com slash changelog. Welcome back, everyone.

This is the ChangeLog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of ChangeLog. On today's show, Jared and I are talking to Johannes Schickling, co-founder and CEO of Prisma. We catch up on all things GraphQL, the tech, the possibilities, the community direction, how Prisma turned your database into a GraphQL API, their new business direction, Prisma Cloud, open source versus enterprise, and the upcoming GraphQL Europe conference in Berlin on June 15th. So Johannes, we last spoke with you about a year ago, all about GraphQL, why it's so cool,

and why everybody's getting excited about it, yourself especially, super stoked about GraphQL. And that was a great intro to the technology and to its possibilities and so if listeners want a full deep dive into GraphQL go back and listen to episode 255 which is in the show notes but for those who didn't hear that episode why don't you give us the high level explanation again of what GraphQL is why it's taking the industry storm, and then we'll move into Prisma after that. Awesome. That sounds good. Yeah, it's great to be back on the show. Fantastic shows over the last couple of weeks, so super excited to be back.

So yeah, a quick, quick recap of what GraphQL is, since even though we're living in our GraphQL bubble and it's growing, the majority of the people still don't know what GraphQL is. Definitely. Typically front-end developers get excited about GraphQL first because it really solves one big problem for them, which is basically how they get data into their client applications from an API. So still the status quo today is that you'd be using REST APIs.

And with REST APIs, you sort of have like this fixed structure of the kind of data you can get back. So you have like these, like typically like REST endpoint where you have like a get endpoint where you have a get endpoint where you say, hey, give me all of these posts or give me all of these comments for this post. And you just get back a fixed structure and you have to know about all of these endpoints.

GraphQL turns the entire thing a bit around where the front end can basically tell the back end exactly what sort of data it needs. So think about it like a SQL query, like within an application, you can tell the database what sort of data you need back with a SQL query. Think about the same concept sort of for your frontend application, that your frontend application can say, hey, I'm interested in this sort of data. And the backend gives you exactly that kind of data back that you need. And that solves all sorts of problems that,

like you just, for example, do just one HTTP request to your back-end, and you get all the data that you need. And also, you don't need to do n plus one queries on the front-end that you say, give me all the posts, and then you iterate on the front end over the posts, and you get then back all the comments. So all of that just happens in one. That's sort of the biggest win

that you typically get from GraphQL. But the thing that I'm actually most excited about is the tooling that GraphQL enables. So whether that's being a GraphQL playground or that GraphQL maps to type programming languages, there are so much awesome tooling that gets enabled through GraphQL, which is, I think, overall,

what gets people more and more drawn into GraphQL. Yes, and I think GraphQL, like you said, it makes immediate sense and it excites front-end developers quite a bit because it really puts the power back into their hands to craft the exact data that they need when they need it and not have to deal with, I guess, somebody else's idea of what server responses should look like. Exactly.

And the point that you just mentioned of like, that it puts back the power into the hands of front-end developers, that's actually one of the biggest reasons why not just like one developer decides, I want to use GraphQL. It's like the newest technology, but it's also why you would decide on a company level, why an executive team would decide we're using GraphQL

because it just makes your development team so much faster by giving that power into the hands of front-end developers. And the front-end developers are more decoupled from the requirements of a backend development team. And that's just, on a company level, that's the biggest win that you could get. What does it take to get GraphQL in place? Is it an API? Is it a server?

Funders typically don't have access to the infrastructure, so how do they get access to this tooling? I give you two answers to that. One is a more classical setup would look like this, that you have your GraphQL client in your React application or whatever you have in your client

could also be a native application. And then you have a GraphQL server. So you have these two parts basically. So the point of a GraphQL client is that you have sort of this, that you have a more native GraphQL integration into whatever client-side framework you're using. So for React, that's really nice because you can basically map the data requirements of React components directly to a part of a GraphQL query. And the GraphQL client then, for example, Apollo client or Relay, then takes care of merging all of your data requirements of your current view together in one big GraphQL query

and sends that back to the server. And the server, that is typically implemented with a concept that's called resolvers. So think about it like a collection of functions, and each function maps to a certain field or piece of your data structure that you expose. So for example, you have a user entity, and the user entity has a field called friends. Then you get a function that is called friends where you need to, that gets automatically called whenever the client is requesting the friends. So on the backend, your job is to implement these resolver functions and make your GraphQL server work. So that's the most traditional setup.

What we've actually found is, like you mentioned, it's quite a big of an investment for a company to establish new infrastructure, especially for front-end developers. They typically don't have maybe the abilities or they don't have the permissions to spin up new infrastructure. So what we've seen, like a little trick to get GraphQL adopted in your company, is basically that front-end developers would implement this GraphQL server not as its own infrastructure component

but sort of like as a little thing that also lives in the client so they basically implement these resolvers in the client and in the client you would then map to like another REST API or wherever you get your data from and this way you basically in the client, you have these two layers. One, you have this virtual GraphQL server, and then you can basically use GraphQL as it would be implemented as an actual server, and you get all of the benefits in the client. So what we've seen from companies is that they maybe don't get direct permission to say we do graph kill the front end developers want it so bad anyway that they just um jumps through this extra hoop then go to management team and say like hey we told you like we could get rid of like uh like all of our redux boilerplate uh we're so much faster uh please tell the backend team that we finally want this.

Because if you make its own infrastructure component you get still a lot of performance benefits since obviously your API server should be as close to the database as possible, etc. But you could still prove your points through this. And this is a pattern that we see in a lot of big companies. Two thoughts on that. The first one is, some people must be desperate for getting some GraphQL, right? Because that is a lot of extra effort, I think, to implement basically like a GraphQL proxy inside the browser, so that you can, you know, speak to that and then convince your boss. And

secondly, when you finally convince management or your your server side team or whoever it is to implement it on the server that has to be like the most epic code deletion day of all time right like when you just throw a party like we get to rip all this code out of our client now because it's all just because it's server side yep for sure but the the exciting thing about that is since like um graphql the most of its of the early graphql adoption uh happened in javascript even though graphql is now widely spread in any language community but it's still like when these frontal developers um want graphql so badly that they built their own graphql. They used the JavaScript implementation of GraphQL. And very often, you would then also build this actual GraphQL server later on, also

in JavaScript. So it's actually not that much of a rebuild. But yeah, like you say, you can just take the server, move it into a different folder or repository, wrap a little HTTP server around that, and you're good. That would feel even better, because on one side you're deleting a bunch of code, and on the other side you're getting a bunch of free code because you already wrote it,

and it just needs to be tweaked for that. It's certainly a forced hand, because you're doing it in the prior, and then you succeed by getting people to realize that you do need this. And you just get to move it into its proper place. It's a true hacker way, for sure. Exactly. And that already gets you in this right mindset that you can basically build your backend in such a layered way.

You can think about, okay, this GraphQL layer, I can put it wherever I want and wherever it makes sense in terms of responsibilities and ownership inside of a company. Should that be owned by the front-end team? Should that be owned by the backend team? Also with the dimension of performance in mind. It's, for example, also with things like Cloudflare,

what is called Cloudflare functions, or Lambda at Edge, et cetera. It will be possible to run basically API servers at the Edge. So there are a lot of exciting opportunities where you would put actually your GraphQL server. This is such in the spirit of open source. Don't ask for permission, right? You get your job done and you bring these tools in.

This is how open source has spread into corporations for years. It's not top-down, some management person saying, we're going to use this open source technology. It's some engineer using the best tool to solve their problem. And then later on, you know, then later on the team finds out, oh, yeah. Oh, you've been using Perl to, you know, write all these automation routines for all these years, or whatever it happens to be. I mean, that's, that's awesome that people are, are wanting it so bad that they just go out and show its value. So Johannes,

as you said earlier, you're kind of inside the GraphQL bubble. Adam and I are staying outside the bubble. We poke it every once in a while. But you're our access to that community. So tell us, since last year when we first talked, what's new in GraphQL? What's the ecosystem look like? What has changed?

And I also like to know, what are some public play boxes or sandboxes people can use aside from GitHub, which is the big one that I also like to know, what are some public play boxes or sandboxes people can use, aside from GitHub, which is the big one that I think everybody knows about, where they can go and use a GraphQL API? Sure. So I hope that the next time we're speaking, you're part of the bubble,

and the bubble is no longer perceived as a bubble. We hope so as well. We're trying to get into the bubble. We're trying to get into the bubble. We're trying to get in. So I guess you're mostly in the Elixir spheres, which actually has quite good GraphQL support. But regardless of which language you're using, there is pretty decent GraphQL support for that right now on the server and on the client.

So that shouldn't be a problem. is pretty decent GraphQL support for that right now on the server and on the client. So that shouldn't be a problem. So what has happened in the GraphQL ecosystem? So what gets me super excited is that the community has just exploded and pretty much any company that we're talking to, we don't need to ask them anymore whether they have heard about GraphQL. We're rather directly asking them how far they are with their GraphQL adoption.

It's rather now a rare case that we learn about, that we talk to a company and they don't start adopting GraphQL yet so you've you've seen it like with with recent announcement announcements of of medium for example to to moving over to GraphQL uh you mentioned GitHub uh GitHub's actually uh investing a lot into into GraphQL right. So they want to help more people to learn about GraphQL. They really invest a lot

into evolving their GraphQL API to build tooling around that. So all of that, all of the ecosystem and the adoption has been just awesome. Another indicator for that is, for example, the GraphQL Europe

and the GraphQL Summit europe and the graph kill summit conference like the the graph graph kill conferences they've like doubled in in size over the last year we see like tons and tons of meetups all around the world um like helping people to to get into graph kill and yeah what we really see is like that this is just like the natural companion for React. So whoever like builds a new React app, for them, it's almost like natural to build a GraphQL server for that. So that's super exciting. On a more like technical level, I think the last time we spoke, GraphQL subscriptions was fairly new. On a technical level, there are a couple of exciting new things in GraphQL since then.

For example, the concept of live queries, which is another real-time way of accessing data, is seeing more and more traction in GraphQL. And also a pretty big topic is the idea of schema stitching. And schema stitching is such a broadly applicable topic around GraphQL that really fulfills one promise of how APIs can talk to each other. So the idea behind schema stitching is basically that you can one, split up your backends into multiple parts and then join them together. Since like every GraphQL server, for those of you who don't know GraphQL, what's special about the GraphQL API is that it has a schema and therefore it's tight.

So similar to maybe, as you know, Swagger or OpenAPI, and you have like a JSON schema that you can define, GraphQL provides something like that. A lot simpler and a lot more intuitive in my opinion and with that you basically all each of your GraphQL APIs is is typed and that means similar as like how you have in a program language and you have a library and that library has type definitions and you can like join things together you can now do the same thing for your APIs. So let's say you have a microservice set up and you've split up your backend into different microservices, maybe a microservice for users and messages and posts.

You can basically now have like a gateway layer in front of that that joins all of that together in one GraphQL API. So you have a GraphQL API for your users and your posts. And the gateway basically just says like, okay, every user has posts and just joins it together, like just joins the schemas together. And you can compose GraphQL APIs and like they snap together like Lego bricks. And that's like such a powerful concept that GraphQL provides and like they snap together like, like Lego bricks. And that's like such a powerful concept that, that GraphQL provides you there since it allows you to split up things and allows you to reuse APIs. You can, for example,

take the GitHub GraphQL API and simply like put that into your own GraphQL server and just delegate to delegate to that other part. And it really allows you to reuse APIs at a level that was not possible before. And it also sets the foundation for service-to-service communication. I was just going to ask that. That seems like the next move then, since so many of these services speak over HTTP and REST,

it makes sense that if you're exposing these GraphQL APIs and you're maybe even stitching them together, that all of a sudden maybe this is even a better way to have our microservices or our services, depending on the size of the service, have them talk to each other. Exactly. And this is where the ideas of GraphQL bindings come into place, where it now gets like with schema stitching and GraphQL being such an approachable language, and the best example really for why it's so approachable is that even front-end developers start building GraphQL servers. Now something like that service-to-service communication where you typically think about expert developers

who know how to deal with protobuf, you can now basically do the same thing with GraphQL with the same type safety, with the same efficiency since you can actually under the hood map from GraphQL to a more efficient format, not just HTTP and JSON, but you can map that to Protobuf or to MessagePack, but you can still apply the same simple and fantastic tooling from GraphQL for any sort of communication. For the people who are particularly interested in GraphQL or who want to push a certain part of GraphQL forward.

Since about half a year ago, there is this thing called GraphQL Working Group, where basically people from Facebook, from us, from Apollo, from different companies who are driving GraphQL forward and also who are just GraphQL adopters. So you have people from Atlassian and Twitter and like tons of different companies coming together

in bimonthly meetings where we just discuss certain in-depth questions around GraphQL, around its type system, which features to add, etc. So this is something that really has driven GraphQL significantly forward and making sure that it stays a healthy language and can be adopted from every different angle. So if some of the listeners are interested in in getting deep like getting more deeply involved there uh that that's certainly a great place to to to get involved This episode is brought to you by DigitalOcean.

DigitalOcean is a cloud computing platform built with simplicity at the forefront. So managing infrastructure is easy. Whether you're a business running one single virtual machine or 10,000, DigitalOcean gets out of your way. So teams can build, deploy and scale cloud apps faster and more efficiently during the ranks of Docker,

GitLab, Slack, HashiCorp. We work fastly and more enjoy a simple, predictable pricing, sign up, deploy your app in seconds, head to do.co slash change log.

And our listeners get a free $100 credit to spend in your first 60 days. Try it free. Once again, head to do.co slash changelog. so let's talk about prisma now which is very much on the server side or the implementation the provider side of the graphql conversation providing tooling around that uh johannes you describe it as a performant open source GraphQL ORM layer doing the heavy lifting in your GraphQL server. This is your baby, Prisma, open source. Tell us all about it. All right. So just a couple of minutes ago, we heard about like how, like on a high level,

how it works to build a GraphQL server and it's basically all about implementing these resolver functions and what you do in these resolver functions is basically mapping from some sort of data source to the abstraction that your GraphQL API gives you and if you think about like what a typical what implementing an API typically is, it's exactly that. Like typically mapping from a database to your API, like mapping the data from the shape of how it's stored in your database, typically like in a normalized way,

or if you're using Mongo, like mapping from some sort of document representation to what you want to return with your API and doing that mapping. And this is what we've seen, like what takes up like 80% of the code of a typical GraphQL server implementation. And also that's typically the part as you evolve your application, that's the most error prone to evolve and to change. So what we've basically done is with Prisma, we wanted to simplify that part of like how

you map from a database to your own GraphQL server. And the way how we do that with Prisma is actually leveraging the idea of schema stitching. The way how we do that is we actually turn your database, any kind of database, into a GraphQL API. And now you can use the idea of schema stitching to basically reuse these parts that abstract away your database to implement your own GraphQL server. So think about you get like little GraphQL building blocks for your database that you can now use to implement

your own GraphQL server. Or in other terms, like Prisma is sort of like this glue between your GraphQL server and your database. So that's the high-level idea of Prisma. And Prisma, therefore, is really like, you could call it like a GraphQL database gateway or proxy or like this data access layer. So how we actually, like how we've seen that or like how we thought about that is that like whenever you're looking at any sort of bigger project um you either have um like an orm layer or if that's not um typically an orm layer is um limited in some capacity so either like works fairly well as you as you get started with

development but then as you um as you roll it out into production and you hit a certain scale um the it just the performance just sucks because an orm is typically yeah just gives you an api to express your data requirements and that turns then into a typically unoptimized SQL query, which works well throughout development, but then breaks down in production. The second problem is that typically these ORMs are like a leaky abstraction, so they don't really provide you all of the the capabilities of a of a database and you have to drop back to raw sql and so if you don't use a an orm what you typically do at these at in bigger projects and bigger companies is that you create this notion of like a data access layer or data access object where in this abstraction you start implementing your your database access and you like implement little functions that return to you like here give me

give me a post or give me like the entire object graph that that i typically need for a post and all of this logic we've basically taken away and made it its own infrastructure component as a data access layer and with the power of GraphQL schema stitching you can basically now like use that and split up your GraphQL server into layers and like access your database through GraphQL or through the ideas of GraphQL bindings which basically maps a GraphQL API directly into your programming language. Well, Prisma is very good timing, I believe, for us, because as you alluded to earlier, Johannes, we've been toying around with the idea of a public changelog GraphQL API around our news and around our podcasts. And we are running Postgres on our back end. My first step towards that was to try a tool called PostGraphQL,

which I believe has been renamed to PostGraphile, which is a very interesting project that will introspect your database schema and then basically immediately provide for you a GraphQL API based specifically on that current schema, which I got up and running very quickly. And that was very cool to just poke around at our own database via GraphQL. Where that project seemed to stop, and I could be wrong because maybe I didn't dig deep enough, is it was basically done. It seemed like if I wanted to change the responses and the schema structure of what I'm exposing,

I was supposed to change my database to reflect correctly. And I know there's some tooling around limiting certain aspects, but it sounds like Prisma is kind of that, where you're providing that layer, but then, like you said, it's the glue, so then you're writing also a data model or something where you're basically molding it to look the way you want. Am I following you? Is that right?

Right. So a couple of points here to unpack. So maybe to quickly also compare Postgrefile and the approach we're taking with Prisma. In general, these projects are fairly similar, but the ultimate goal is a bit different. So for Postgrefile, this is really just built around Postgres. And the idea is whatever you want to change, you have to do natively in Postgres. And the idea is whatever you want to change, you have to do natively in Postgres.

So if you want to change something, you have to use your current migrations that you would already do on Postgres. And that would then reflect back in your GraphQL API. With Prisma, we have a bit of a different perspective on all of that. So what we, for example, see is that today, you would no longer just have one database in bigger projects, but you would actually, like one of the last shows was about Elastic and we spoke about the differences

when you would use Postgres, when you would use Elastic. And there are so many specialized databases which really shine at one particular task. So for Elastic, that might be aggregation or full-text search. For MySQL, Postgres this is like the more relational model but you also have cassandra which is like really highly transactional and scales scales horizontally so they're like specialized databases for a certain for certain scenarios for certain types of tasks and what typically happens then is you would actually combine multiple databases in one

project. So you would store maybe the bulk of your information in Postgres, but also some information in Elastic and some information in Cassandra or in Redis. And so our goal with Prisma is really having like this universal GraphQL API in front of all of your, like all of the databases that you use for a project and you get one GraphQL API for that, that you basically get one, like your data model joins across your different data stores. And that's rather like how we see things a bit differently with Prisma. And also like there's a whole rabbit hole to go into just around that topic

since we put a lot of thought into surfacing the specifics of a certain database type into its GraphQL API. So we'll have basically multiple types or multiple categories of GraphQL APIs mapping to the different categories of databases you have. So for example, a relational database will have a different GraphQL API exposed compared to a graph database or compared to a key value store. So all of that is actually represented in its own open source specification called Open CRUD. So you could find that on opencrud.org.

And this is like an open source project that's just concerned about how you would expose a specific kind of database most efficiently in a GraphQL API. So that is one part of it. There are two more thoughts on this. So the other is, we don't just, with Prisma, we don't just expose your database through GraphQL, but we also use GraphQL for a second part,

which is GraphQL also gives you this beautiful language called GraphQL STL, schema definition language, which is a very concise way to express like a type system. So to express enums, type definition, interfaces, unions, and all of that. So, and that's like a super, super nice syntax, maybe comparable to like how you do type definitions and in TypeScript or Swift or Go. So you can basically now use that to describe your data model. And you can use then prisma to either map to an existing database like like in your case where you have an existing database or if you're

starting out from scratch you can use this graph this graph gl stl and you use prisma to that the prisma actually lets lets you to lets you migrate your database just given your data model representation. So Prisma actually does the heavy lifting of migrating your database and creating join tables and all of that. So it's really like that Prisma leverages GraphQL 1 to let you read and write your database through GraphQL,

but also it lets you use GraphQL STL to describe your data model and to help you with database migrations. Wow. So yeah, these are basically the ways how we think about Prisma. And coming back to your previous point about that you can basically mold your schema in such a way that you want. So again, there are two ways how you could use the GraphQL API that Prisma generates for you. So in simple cases, or as you might be just toying around and you build a prototype this is where you could actually just use the GraphQL API that Prisma gives you directly and directly

like start using it from from your front end but as you add more business logic to to your application this is what you would want to have in a separate layer. So this is where you would build your own GraphQL server, and you would use the GraphQL API that Prisma gives you as building blocks to build your own GraphQL server. So in your resolvers, you can basically get rid of your giant SQL queries or whatever you have in there and use a so-called GraphQL binding that allows you to delegate to the underlying Prisma layer. You may have lost me on that last point. Use a GraphQL binding to delegate to the underlying

Prisma layer. Can you unpack that? Oh, for sure. So imagine you have a, and all of that is fairly theoretical right now. The best way to really look at that is by looking at code. Then it gets immediately clear. But basically, let's get back to the point where you need to implement your resolver, right? So let's say you need to implement a resolver on the root level that returns you like the feed of your posts let's say you build like a like instagram and you need to return like a feed that returns you an array of posts um in that function you you would basically now need to return all like you need to query your

like without prisma you would now need to go to your database, get all of the data that you need there. And then also conditionally on what the client queries, you need to also say maybe they, for the feed for each post, they also want to have the comments and the author information. Now you need to implement basically resolver functions for all of these different possibilities. And if you're using a GraphQL binding and you use Prisma under the hood,

this is basically where you just provide the entry point to say like, hey, now let's return these posts here. And you then just delegate to this next GraphQL layer. And if the client happens to also query information about the author or information about the comments, the Prisma layer takes care of all of that resolving, and you just need to implement basically this entry point, this sort of delegation part that forwards the query to the database layer. What if I could just think about my server the way that I want it to work,

and then Prisma could just do the rest from there? Because it sounds like you're taking care of most of the work already. Why don't you just go the extra mile, and I can just tell you how I would like it to look. To a certain extent, that's exactly how it works. But basically, Prisma takes care of all of your um data resolving and

data mapping so the same way as an orm is supposed to um we can just through graph kill we can leverage more information about like we know what um a client would query we know exactly the the type the type of information so we can implement that very efficiently. But all the business logic that you want to implement, you would still handle that in your own GraphQL server, such as authentication, authorization, actual business logic, like sending an email or processing an order.

This is still what you take care of, but we make the data access extremely simple. You mentioned that some tools around these things can create suboptimal fetching or querying or whatever it happens to be. The generator has a generic abstraction, and so the specific scenario of this particular use case cannot be optimized so with prisma is it hands off so far as like can i tweak things when i know more

than prisma can know with regard to performance or how a certain data structure should be fetched or is it all too far away to touch? Sure. So there is a way to also drop back to the raw database access under the hood if you really want that. But in most cases this already gives you like the... There are two things to consider here. So one, is it like the kind of data that you want to get back? That it's one scenario and Prisma already gives you the abstraction that you want there. The second point is about implementing things more efficiently.

And this is exactly one of the core things that Prisma does for you that wouldn't be possible with a traditional ORM since a traditional ORM is like a stateless function that gives you a DSL to express your data requirements as you collect your data requirements at some point you say execute so it builds up a sql query it compiles your your data requirements from the dsl into constructing a unoptimized query sends that query to your database and the database now has to deal with your with your crazy query

whereas with prisma you you would basically construct all of your your data requirements um through your graphical resolver system and just forward them into the prisma layer and the prisma layer has then a query engine um that can most efficiently talk to your database or to different databases. And also, since it knows about how data is changing, actually has a caching layer built in. So it's a way more performant way to access your data. When you and I were discussing these possibilities earlier on, you said, well, if we supported Postgres, you could use Prisma.

Sounds like I've procrastinated myself into support now because you've listed MySQL, Postgres, and MongoDB currently supported, and then coming soon, Elasticsearch, Neo4j, Cassandra, and an icon that I'm not familiar with. Maybe that's Cassandra's icon. Is that the current state of affairs? And can I use this with my Postgres database today?

Exactly, so for the Postgres database we distinguish between an active connector and a passive connector so the active connector is where you would use GraphQL STL and allow Prisma to migrate your database, whereas a passive connector would be that you map to your existing database and you would still migrate your database on its own. So for MySQL and Postgres, we both support an active and passive connector. And for MongoDB, we've just rolled out a, or we're about to roll out a beta

version of, I guess, both an active and a passive connector. And over the coming months, depending on user feedback, we're planning to add support for any kind of database, really. So did I hear you correctly? Regardless if I use the active or the passive adapter, I'm still going to need to migrate my database to a new format? No. So for the active connector, there you would let Prisma

migrate your database. And for a passive connector, the way how you would set that up, so concretely in your case, you would basically connect Prisma to your database. Prisma would, for the first time, introspect your current database schema. From that, it would generate a data model

expressed in GraphQL STL that maps to your existing database schema. And from there on, you can either let Prisma take care of migrations in the future or still migrate yourself and you would then still adjust the data model expressed in GraphQL STL.

What about concerns with authentication and authorization? I think we often think about authentication, but authorization turns out to be a much hairier issue business logic wise. How are those things handled? So the way how we think about that is that authorization is very much, of course there are common cases, but very much that's very specific to your product that you're building, to your company. So the best abstraction to really express that is code,

especially if you have already built libraries around that. So that's just the best abstraction. We want to embrace that. So the way how we allow you to do that is that you would implement that GraphQL, that authorization system in your own GraphQL server. So you would still use Prisma to resolve your data, but you would check who's allowed to access

which kind of data in your own GraphQL resolver layer. The same goes for authentication. You would implement your authentication system using JWT or whatever you want to use in your own GraphQL server that sits in front of Prisma. And then Prisma doesn't need to know about authentication or authorization. Of course, Prisma on its own

has also a simple authentication system, but that's rather like meant for that a certain, like that the service cannot be accessed in an unauthenticated way. So more to secure the service-to-service communication. This episode is brought to you by our friends at GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. Check them out at GoCD.org or on GitHub at github.com slash GoCD. GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization.

With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end with no problem. They support Kubernetes and modern infrastructure with elastic on-demand agents and cloud deployments. To learn more about GoCD, visit gocd.org slash changelog. It's free to use, and they have professional support and enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog.

So, Johannes, we've been talking around, obviously, the tech behind this, Prisma, where it's going, but it seems like there's an enterprise being propped up behind this. You've got some news you're coming out with very soon and a company, it sounds like, going from just simply open source to a company behind this called Prisma as well. Is that fair to say? Yeah, I guess so. So, I mean, we have quite a bit of a history. And I think like adding up to like where we left off with the last episode, like we've been super fortunate to build a really big community around us. What we've been doing over the last two years, building up GraphQL as a GraphQL backend as a service. And that has really led us where we are today.

So to kind of give you the quick version of how all of these things have evolved, it's basically that we've built GraphQL to really make um make like um make the barrier to entry for developers especially front-end developers to get their own graph kill backend as low as possible and um over the last two years we've basically seen like a lot of big big companies and a lot of more experienced developers also adopt graphql and adopt graphql and push graphql really to to its limits um where we've seen okay we we added like more and more features we added more and more abstractions to to make it more powerful for for

people to build bigger applications with graphql and what we've seen is the experienced people are more and more looking for how could they bring their own code to implement the business logic that they wanted. On the other side, what we've also seen, the more serious a company was, the more of a problem it was for them to have data living anywhere but inside of their cloud or on their premises. So what we've seen is we got requests like,

hey, could we run GraphQL on our own? Or could we just use the database part of GraphQL for our project? And that has really been like the foundation for Prisma that we've seen, okay, actually GraphQL consists out of multiple pieces and consists out of like the core part of it is really like this data mapping unit that maps a database to a GraphQL API.

And that has really pushed us to say, okay, let's actually invest in that particular part of the GraphQL API. And that has really pushed us to say, okay, let's actually invest in that particular part of the GraphQL framework, which is Prisma as the core query engine. And that sort of like resulted in this shift of focus for us, even going so far that similar how like other companies have done in the past, like Tenzin, for example, changing to MongoDB with their core product being MongoDB, where we took this big step and rebranded the company and all of the community and everything around that from GraphQL to Prisma to really like show our commitment and show our focus, um, for, for Prisma. So, um, and there, there are like, uh, various angles to that, to, to explain it. Um, but yeah, that, that's sort of the, the, the quick version. Um, and like, like you, like you teasered, um, we, we actually have some, some, uh, quite

exciting news, uh, for, for us as a company, as we've been very fortunate to have raised a pretty substantial seed round. So we've just raised a $4.5 million seed round from some of the best investors out of the Silicon Valley, where we're just about to open a second office. And that just allows us to really grow the team, grow the backend development force behind that, and allows us to also grow the new San Francisco office. So if any of the listeners are looking for a job and are interested in GraphQL, definitely go to our jobs page.

So Prisma is an evolution of what you've learned and what the community has asked for around GraphQL and is also a company. So not only an open source, but also a company. You've got cloud coming, you've got enterprise coming, and you just mentioned you've got a seed round. So clearly you're heading in the right direction in terms of what I think is kind of interesting around open source and combining that with business, right, is that some will offer support or services. In your case, you're adding, it seems, cloud infrastructure and potentially software as a service as the for-profit business model on top of your open source.

Is that right? Right. So that's almost right. So for us, the focus on the monetization front is really where we see the biggest demand and where we also see that we can build a substantial business, which is more on the enterprise side. Since what we're building with Prisma as an infrastructure component

is very similar to patterns that are already present in enterprise software systems. So if you think about it, Prisma and what Prisma enables, it really enables GraphQL as a universal query language. That's very similar to what you had like a decade ago with ODBC. So that idea is like not new at all and fits in really well into an enterprise context

where additionally to the data mapping part, you also have additional requirements, mostly around security and audit logging, various features around that. There are also many opportunities to just implement more efficient data loading mechanisms, caching. So this is really what we're seeing a lot of demand for, where we're working with bigger companies on an enterprise version of Prisma. And that's really what we focus with Prisma Cloud is mostly empowering developers with better workflows around databases on the foundation that Prisma provides. So you can think about around Prisma Cloud kind of like as a database workflow platform. So this will, over time, will build various integrations with different cloud providers where you actually host your Prisma server,

where you host your database. So you could, for example, connect with Prisma Cloud, connect to your AWS account where you run your database, let's say an AWS Aurora, and you're running your Prisma Cloud connect to your AWS account where you run your database, let's say on AWS Aurora, and you're running your Prisma server on like ECS or on Fargate,

and you get all of the instrumentation insights via Prisma Cloud. But more importantly, you get a lot of workflows around that. So we, for example, have a feature that's called a data browser. So think about that. Maybe you've seen SQL Pro or Postico

or think back, PHP My Admin. So tools like that. Don't go that far. Sorry about that. Postico, let's stay there. Yeah, that's a good one.. Sorry about that. Posticle, stay there. That's a good one. So think about that for your data and across any kind of database.

So one for developers, but also for non-developers, for more business users. So we see a lot of companies using Prisma Cloud basically to roll out access to their entire customer support team, to their entire marketing team, to their entire sales team, that they get access to the actual application data without the development team needing

to build a lot of like admin backend interfaces or like these admin panels. So that's certainly a workflow that we see a lot, but also workflows around like typical development processes so um if like thinking about continuous deployment um we we actually uh will roll out an integration with github that you can simply like push uh like push your changes to your github repository and prisma cloud will um will deploy the database changes on your behalf so um if you're familiar with Netlify, for example, how you can simply push your changes to GitHub and Netlify automatically deploys your new website.

Think about the same thing, but actually for your database and your database migrations where like changes that are like non-destructive, they can be configured in such a way that it's just rolled out. And if there are database changes that might actually introduce some breaking changes that sort of batch up and you can manually decide

to roll it out into production. So various workflows around that. And this is what we're offering for free with Prisma Cloud, that people can just get better workflows. And if people want the same sort of workflows, but more in a company setting, where all of that lives in your own cloud,

or where all of that lives on-premises, this is where you can get the same features as part of the Enterprise Edition. So it's actually going to be an on-premise product for Enterprise. So there are these two different products. So there's Prisma Cloud and Prisma Enterprise. And both of them offer this Prisma platform. So this value-add, these additional workflows around Prisma.

So Prisma Cloud offers that in a hosted way that you can use as a free SaaS product right away that integrates with GitHub or with your AWS account. We're actually also

working with the guys at Site to also implement integration there. And if you want to use all of that on-premises so that you can enforce your data privacy rules, etc., this is where we can deploy the Prisma platform in your own cloud or on your on-premise servers. So first of all, congratulations.

We breezed over your 4.5 million round, but that's a lot of money and probably a lot of work. So congratulations on that. Feel free to name names. You said you've convinced some of the smartest people in the Valley. Well, name names by all means let us know who's who's who's getting behind you this round was um was led by by kleiner perkins um at kleiner perkins um by mamoon and bucky mamoon for example has been involved with slack intercom box like various like

very well-known companies um and we really feel that that we have a we have a great home there um like as part of like a new generation of development tools um that they that they really uh invest a lot into um and we've also worked with uh with various other um smaller investors and like also got a lot of great angels on board. Like, for example, Guilherme Rauch from Sight, actually, or one of the creators of GraphQL came in as an angel investor. We have the CEO of Cockroach. We have the ceo of um of kong like various uh experts in the in the industry who

really like uh can help us a lot with um uh like strategic advice and just like building a great partnership there uh we also have like the the founder of algolia um so various various people we're super grateful for for having them board there one of the questions I was going to ask is was the sales pitch tougher in terms of getting them to invest because of the open source nature but the names that you're

naming it sounds like these people understand open source businesses natively oh yeah for sure so it was actually funny that you mentioned that since like it was almost like that you mentioned that since like um it was almost like a a filter for us to see like who are we talking to who we're not talking to as part of this um like the the this fundraising process uh we really wanted to make sure that we work with people who understand open source um and like a lot of people even go as far as if you're building nowadays

if you're building software for developers also especially at an enterprise grade and it's not open source then that sort of doesn't make sense so open source is really like the entry ticket for you to even be considered in a new enterprise environment. Such a counter way of thinking than like years ago, right, Jared?

It's like, yeah, to hear that. I mean, it's that's how it's playing out. But to hear someone say it a lot is sort of like, oh, it's different. Yeah, for sure. The world is completely changing in that regard. But it makes sense. If you think back 10, 20 years ago, most of enterprise software has been so top-down

and CIOs have made the decision of, okay, we're going to adopt this software and then roll it out in the entire company and it's been adopted or become a shelfware. But nowadays, like we talked about at the beginning of the show, we have now front-end developers who really want to start adopting a technology and whether they're allowed or not, they start doing so. So bottom-up adoption is really like the new default.

And it's almost impossible to have bottom-up adoption is really like the new default. And it's almost impossible to have bottom-up adoption that's not based on open source. So that's pretty obvious for us. That's an interesting perspective, too. Not that developers are the bottom-up, but we're the doers, the implementers. So the bare metal up, but we're the, you know, we're the doers, the implementers. So it's, you know, the bare metal up, maybe, maybe bottom is sort of a negative connotation, but I'm feeling you. And I get to say that often to our sponsors is like, listen, like,

you know, we talk to the influencers out there. So like, this is a great platform for you to share your message. And hearing you say that just like is music to my ears because I, I see that so often. Oh yeah, for sure. I mean, this is how you sort of get a foothold in a company, also in a way that ties in very well with how we think about our adoption strategy, since Prisma on its own is completely open source and completely free to use.

And the developers who start using it, they don't even think yet about like these kind of enterprise features that they have. But once it reaches a certain level in the company, then the like more compliance features, security features, and so on kick in. And then it sort of turns around, right? So the entire open source angle, that allows for a bottom-up movement. But once it reaches such a level, then they're looking at it as a company.

But do they provide us an enterprise version of that? Does that come with premium grade support? What about SLAs? What about different certifications? And this is where an enterprise version comes in, which that on its own not necessarily has to be open source. More and more companies actually also have the enterprise version open source. I think you just spoke about exactly that

in regards to Elastic on one of the previous shows. But open source is really the key for this bottom-up movement. Well, on that note, maybe you can more clearly define the line between

open source Prism and Pr know prism enterprise it's on prisma i've said that in the break y'all i'm sorry i keep saying prism and that's my bad prisma uh prisma open source and prisma enterprise the thank you jerry for correcting me by the way it's so embarrassing um how do you define the difference you know how do you put features into open source and how do you define the difference? How do you put features into open source? And how do you define what doesn't go back into open source? For example, a pull request comes in for a contribution that collides with your vision for enterprise. How do you discern whether or not to enable that? That's some of the often questions asked out there in open source around businesses being built around open source.

Right. So the good news there is that it's typically fairly straightforward. And a lot of the features that we want to put into the enterprise version, like the bottom-up movement doesn't really ask for that so no um front-end react developer would ask about like this this sort of like compliance um or certain audit logging what they ask about like hey does this does this support um postgres does this support mongo or does it support this um this graphkl feature and our philosophy around that is very much like you should be able to run prisma completely into

in production without without any caveat um from from a functionality point of view um like we don't want to restrict you running Prisma in production. But then there's a fairly clear line towards enterprise-grade features, which is then available in the enterprise version. So again, things around security are part of that, like audit logging, but also certain compliance features, certain authentication mechanisms that you, for example,

for Prisma, for the Prisma platform, you get like a SAML single sign-on mechanism. You get various logging mechanisms. You get better ways to collaborate in certain workflows that you need in a bigger company. So this is sort of where we draw the line. And I guess the reason why I asked that question too is I saw two there. One accelerator, Quirx accelerator, and then performance metrics. So anytime you talk about speed or any advancements in, say, an enterprise or a pro-only version,

when you're talking about open core or whatever model you want to call this, how that may – I guess in that case, maybe general open source developers using it don't care. But maybe some might be like, hey, it's accelerated in the premium version for enterprises on premise but not for me and can i contribute that back or why exactly and a lot of these things are basically um things that we built for you so don't you don't have to build them yourself so um for example this performance monitoring uh like once you roll out a certain system you also think about like how can I monitor it? And these are things that you would build yourself or you get out of the box as part of a premium version, of an enterprise version. So that's a fairly common play.

Well, in the first part of the conversation, we talked quite a bit about how, you know, we haven't talked to you in basically a year. So we were catching up. And I believe in the last conversation we had, we talked about the GraphQL conference. And I think, Jared, if I remember correctly, I think we were talking to him right around the same time the conference was

taking place again. And this, this next one's happening in June. So maybe there's some. I think, I think that's right. It was June-ish when we published the last episode. Yeah, so it's been

basically a year and here comes the next conference. Tell us more about how the community's changed, what's going on with this conference. Yeah, that's funny. That's great timing. We have the GraphQL Europe conference 2018 just coming up in mid of June.

So that's actually the June 18th. Sorry, sorry about that. June 15th. June 15th. June 15th. Better get that day right. Back in Berlin. So this year we will have

twice as many attendees and just a couple of days ago we've been together with a couple of other people in the GraphQL ecosystem like Lee Byron, one of the creators of GraphQL who is always helping us to select the speakers. So we've just finalized the speaker schedule,

which we'll announce over the next couple of weeks. But we have some really, really top-notch speakers in there and it was crazy difficult for us to select all of these talks. So we got multiple hundreds of of really fantastic talk submissions so it was really tough for us to to to decide there um but i think we we got a really fantastic lineup of um of speakers of very diverse speakers and uh super interesting talks um so i'm super excited for that. And actually, as part of this show, we've prepared a discount code,

which gives you 15% off, which is called ChangeLog. Nice, I like that. So hopefully for some of your listeners who are looking for an excuse to come out to Berlin on June 15th, hopefully that makes it a bit easier for them. And one of your speakers, Peggy Reyes, engineer at Apollo, she's actually on an upcoming episode of the React podcast, which is also in our podcast network. So stay tuned to that. Great. I mean, that's interesting.

So you got the evolution of GraphQL to Prisma, and then you've got a company formed around it. You got a seed round, which is substantial, 4.5 million great investors, people who clearly understand the landscape of developer tooling, and not only that, but the importance of it being open source as it pertains to growth and enterprise and all the for-profit models you need to have to actually have developers working on some of these tooling. You've got your hands full. Then there's conference, and then GraphQL radio podcast.

I believe you've got lots of things happening. How do you manage your time? It's crazy. Well, that's a question that the answer for that constantly changes. Very little sleep? That's definitely one of the trade-offs that I have to take into account.

But the most important answer for that is really having a fantastic team that we're working with and that we're growing. And it's been so incredible to see our team just taking on more and more responsibilities and just driving that. And this is where I'm surprised sometimes myself with all of the amazing things we're doing. It's not just me behind all of these anymore. So yeah, that's super awesome. Curious, what size is your team these days? So as we speak today, we're still just nine people.

But we're expecting to almost double that towards the end of this year. So most around engineering, most around the engineering capacity. So both in the front end, but also more also in the front end around the product, but also around our open source projects. And also, as mentioned, we're opening a small office in San Francisco, mostly around just being closer with the local community there, starting a sales team over there, and just investing a bit more into marketing.

So if any of these things sound interesting to some of the listeners, please feel free to either get in touch with me personally via Twitter or email, or just go to our jobs page. That's prisma.io.com. But I guess we'll also put that into the show notes. 100%, we'll put that in the show notes for sure. That's Prisma.io slash shops. But I guess we'll also put that into the show notes. 100%. We'll put that in the show notes for sure.

That's awesome. I mean, definitely seen lots of change for you all in the right direction. San Francisco office, I didn't mention, but you just did. That's amazing. Building a marketing team, sales team. Seems, you know, totally time for that right now. But anything else you want to say in closing for the listeners before we tail off? No, but it's been fantastic to say in closing for the listeners before we tail off? No,

that, but it's been fantastic to, to, to have been on the show again. And like, let's, let's see what, what happens until,

until next year. We'll see you next June, right? Yeah, exactly. All right. I'll, I'll put it into the calendar.

We'll mark the date right now. Next June. Well, actually it's May right now. So it's, it's May. It's barely May, but I mean,

you know, it's basically, yeah, we're, we're a month early this year, so we'll see. Maybe it's, maybe it's 10 months now. It's May. It's barely May. We're a little excited. We're a month early this year, so we'll see. Maybe it's 10 months from now instead of 11, but whatever. Johannes, thank you so much for your time. Thanks for all you do in the open source community. You just do so much.

You've got a great team you're growing there, great business you're growing there. You do awesome stuff for open source. Thank you so much for taking your time to join us here on the show. Thank you. For sure. Thanks so much. All right, to join us here on the show. Thank you. For sure. Thanks so much. All right, that's it for this episode. If you enjoyed it, do us a favor.

Tell a friend. Go on Twitter and share the URL. That'll unfurl a player. Your friends can play it right there in their Twitter timeline. And, of course, thank you to our sponsors, Rollbar, DigitalOcean, and GoCD. Also, thanks to Fastly, our bandwidth partner partner head to fastly.com to learn more and we catch our errors before our users do because of roll bar check them out at rollbar.com and we're hosted on leno cloud servers head to leno.com slash changelog check them out and support this show this show is hosted by myself adams takoviak and

jared santo editing is done by tim smith musicachowiak, and Jared Santo. Editing is done by Tim Smith. Music is by Breakmaster Cylinder. And you can find more shows just like this at ChangeLog.com. Thanks for tuning in. We'll see you next week.