Brian: PodRocket is sponsored by LogRocket, a front-end monitoring and product analytics solution, which is to say, it's not really sponsored by anyone. It's sponsored by us LogRocket, and we're giving it away for free. The podcast is free. The product is not free. There's a free trial. We could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested and you want us to know that you came from the podcast, please go to logrocket.com/podrocket. If you don't care, logrocket.com works just fine, thanks. Brian: Hi, and welcome to PodRocket. Today ben and Kate PodRocket's producers sit down with Nikolas Burk. Nikolas is Prisma's Head of Developer Success. They talk about how Prisma helps developers build better web apps, how it works with TypeScript, the Prisma roadmap and of course, building an open source community. Let's get started. Ben: Hey Nikolas, how's it going? Nikolas Burk: Hey Ben. I'm doing great. Thank you so much for inviting me to your podcast. Ben: Yeah, thank you for being here. I'm really excited to chat and learn more about Prisma. So I'd like to jump right in and maybe we could just start by you telling us a bit about what is Prisma and how does it help developers build better web applications. Nikolas Burk: Prisma is an object-relational mapper or ORM. That's a kind of tool that helps developers to work with databases. And that's particularly relevant when you're building server-side applications, which are typically REST APIs or GraphQL APIs, where you need to talk to a database server to fetch the data that's currently inside the database and return it to a frontend client such as a browser or a mobile application. Ben: Got it. So to dig in there a bit more for folks who maybe haven't worked with an ORM, how is using an ORM different than let's say just doing a SQL query or a query of whatever database you're using. Nikolas Burk: So I think that talking about this space of working with databases on the backend, there are a couple of different ways how developers typically do that and how they interact with databases on the backend side. If we talk about different levels of abstractions that people use here, the lowest level of obstraction is typically to just use a database driver. So if we're talking about the JavaScript ecosystem, the Node.js And TypeScript ecosystem on the back-end, you typically find these libraries, these database drivers that are specific to a certain database. So for example, you'll have a library that's called node-postgres or MySQL. And these are the libraries that allow you to create a connection to a Postgres or MySQL database server, and then submit database queries as SQL queries basically. So you would write just plain SQL queries inside of your application, that you then submit to the database via these drivers. Nikolas Burk: So that's the lowest level of abstraction that people can operate. But when you operate at a very low level of abstraction, it typically means that you have to do a lot of manual work for a lot of things that you actually don't really want to do when building applications, because it just decreases your productivity. Like a couple of these things, for example, our connection handling. So instantiating a connection to the database manually is a lot of work. And these are the kinds of tasks that you typically want to have abstracted away when you are working with a database. That's when you typically want to use higher level abstractions. Nikolas Burk: And the next high-level abstraction that you can have on the backend are SQL query builders, which are programmatic APIs that allow you to compose a SQL query. So instead of just writing out a plain string that says, select star from user to get all the user records from a user table and database, it would allow you to call a function that's called select maybe, and in there pass the table as a parameter and under the hood that function constructs a SQL query for you and submits it to the database. Nikolas Burk: So that's the medium level of abstraction. And then on the highest level of obstruction, we have these object-relational mappers that typically act as ways for you to talk to your database in an object-oriented way. And that can be really handy because the data model of relational databases, of SQL databases is very different compared to what JavaScript and TypeScript developers might be used to where they're following an object-oriented data model and these object-relational mappers, they're doing exactly that. They are mapping between the relational format that you have in the database and the object-oriented format that you have in your programming language. Ben: Got it. That makes sense. So, you mentioned one of the advantages of using a ORM is that it handles things like connection handling and what are some of the other advantages? I mean, when I think back to having worked with ORMs, like with Rails or Django, there's a lot of nice things a ORM does for you, without you having to think about them or at the very least gives you nice abstractions. So things like defining your schema or doing migrations or creating database tables. And of course, querying. So maybe we could talk through a few of those and talk about Prisma's as approach and what it actually looks like to do something like a migration or a database query with Prisma. Nikolas Burk: So a couple of things that folks, I think, typically expect from an object-relational mapper, two typical workflows actually. And one, like you already mentioned, running database migrations meaning changing your database schema. That's a task that is typically performed by an ORM as well and how traditional ORMs typically do that, is that they let you define the tables that you want to have in your relational database. They let you define these as classes in your object-oriented programming language. So what these tools typically allow you to do is to generate migration files that are based on the class definitions of your tables. These migration files, they typically contain plain SQL so that you can execute these migrations against the database and in that manner change the database schema. So this would allow you, for example, if you create a new class that is supposed to represent a new table in the database, you would go ahead and generate migration file for that, that has the create table statement for you in SQL. And then you can use the ORM also typically to run that migration against the database to actually create that table. Nikolas Burk: Then the second kind of workflow besides migrations is of course querying data. And that's what we already talked a little bit about before that these object-relational mappers, they allow you to talk to your database in a programmatic way and in an object-oriented way. And the main benefit of that is that as a developer, you don't have to leave your mental model of what data looks like. You can stay in that object-oriented paradigm of working with data and reading and writing data in the database still using that same mental model. And to maybe elaborate a little bit what the differences are between the relational data model that's used in relational databases and object-oriented programming languages, I think the key difference is that in relational databases, the data is organized in tables and these tables are flat and they reference each other via foreign keys. Nikolas Burk: That's called database normalization. That's when you have a lot of tables that cross-reference each other via foreign keys. If on the other hand, we think about object-oriented programming languages and the objects that we are familiar with as developers, these objects, they typically can be deeply nested structure. So imagine that you, for example, have a user object in your JavaScript application and that user object might have a couple of fields. It might have an ID field, a name field, and email field, but if it would carry more data, for example, if it's about a blogging application and each user has a couple of posts, then we would expect that user object to also have a key that's called posts, which again might include an array of individual post objects. And these individual post objects, they each could have a common field, for example, that again carries an array of comment objects. And that's how we create these nested structures inside of our programming language. Nikolas Burk: And if we compare that to the relational model, the same example, we would have three different tables. And on the post table, we would have an author ID column for example, that references an ID in the user table to indicate which user is the author of that particular post and the same for the comment. The comment would probably have a post ID foreign key that points to a particular post record. So the data is organized in different structures and the object-relational mapper that we can use allows us to not even care what the data looks like in the underlying database, because how we can think about the data in the first place is just in terms of these nested structures that are provided by the object-oriented programming language. Ben: That makes sense. So basically, as a programmer, you don't need to think nearly as much about the underlying database schema, and you can just access your data in a more idiomatic way for writing JavaScript code or TypeScript code. Nikolas Burk: Exactly. I think that's one of the main points. That it should feel a lot more natural and more idiomatic to a developer to talk to a database in that way, rather than always having to perform that kind of mapping from these flat tables in the database to the object-oriented structure and that kind of mapping, if you have to do it as a developer, it incurs a cognitive cost and a practical cost just in terms of writing the code to actually do it right. So with an object-relational mapper, you can really get rid of that extra cost and be a lot more productive when working with a database. Ben: So switching gears a bit, I want to learn more about how you can use TypeScript with Prisma. And part of what I understand is, it's really interesting about that is you can carry through your types from your database schema to TypeScript types. So can you maybe speak a bit about how TypeScript works with Prisma and some of the advantages it brings to you as a programmer? Nikolas Burk: Absolutely. I'm a big, big fan of TypeScript and of types in general. I think they have so many benefits and I couldn't even imagine building bigger applications nowadays without that extra layer of type safety that not only increases the confidence that I can have in my code, but also just the productivity that I can have as a developer due to a lot of different factors. But let's not talk about the general benefits of TypeScript just here. We might mention a couple of them along the way, but back to your question, how Prisma and TypeScript fit together. So Prisma in general just can be used with plain JavaScript and with TypeScript to make that very clear, even if you're a JavaScript developer, your back-end application is currently built in plain JavaScript, you can still use Prisma, but TypeScript really is a first class citizen in Prisma. Nikolas Burk: And we actually went a long, long way to make sure that all the database queries that you're sending through Prisma through the Prisma ORM are entirely type safe. And this is actually a big differentiator also compared to other object-relational mappers in the Node.js And TypeScript space. So if you look at TypeORM for example, which is one of the first TypeScript ORMs out there, they did the pioneering work for object-relational mappers in TypeScript, but they lack a lot of type safety guarantees that could be provided by an ORM. And that we actually implemented. The way Prisma works is that unlike with traditional ORMs, you don't go and define your database tables as classes. So Prisma does not follow that approach but instead, the way how you model data with Prisma is by using a custom modeling language that is really simple and straightforward to pick up and that you use to describe your database schema. Nikolas Burk: And with this modeling language, you write it in a file that's called your Prisma schema. And that Prisma schema is your main configuration file for your entire Prisma setup. And most importantly, it contains your application models and each of these models map to a table in the underlying database. And the advantage of using that custom modeling language is that we were able to design a language that's purposely built for application developers to model data. And from that data model, we now generate a TypeScript API including a lot of TypeScript types that map to your Prisma models and these TypeScript types and the Data Access API that we generate for you, they provide the level of type safety that you don't get with any other ORM out there. So what's especially nice about the type safety guarantees that Prisma can provide is that they also apply for partial queries and for relation queries. Nikolas Burk: So what I mean with that is, assuming you have a user table in your database. So you would have a user model in your Prisma schema that maps to that table. And you're not want to send a query from your application to fetch a user record, but maybe you don't need all the fields of that user. Assuming the user table has like 20 columns in the database, but you actually only need three of these fields in your application. So you don't want to retrieve all of these fields to save some overhead in loading the data. And when you specify this with Prisma, that you only want to select these three fields for the user record that you're loading from the database, the user object that you then work with in your application will actually be statically typed to have exactly these three fields that you specified in your query. Nikolas Burk: So you're not able to accidentally access a field that you didn't retrieve from the database and therefore just avoiding an entire class of errors that can occur with any other ORM. And in fact, if people want to read up about this, we have extensive documentation. For example, the type safety comparison from Prisma with TypeORM, where we talk about exactly these kinds of scenarios that showcase where type safety guarantees of traditional ORMs might fall short and how Prisma resolves these issues to really give you a level of type safety that you don't get anywhere else. Ben: Cool. Yeah, no, we'll definitely put a link in the podcast description to that article. So you mentioned this idea of specifying fields in a query, and that reminded me of another technology we know and love GraphQL. And one of the things that I really like about GraphQL is that you have types in your schema definition. So I'm curious if you use GraphQL with Prisma and or TypeScript, what are some of the advantages there? Can you carry through your types to your GraphQL schema all from the Prisma schema definition file, or how does that all work? Nikolas Burk: That's a really good question. And first of all, I'm excited that we are 100% aligned on the things that we love about GraphQL. One of my favorite parts about GraphQL is indeed this strongly tied schema that describes your API. And at the same time also just provides this contract that's really reliable. And any client who is accessing a GraphQL API can be sure that whatever is described in the schema will be served somehow by the GraphQL implementation. And the idea that you're referring to is what we also call end-to-end type safety. Nikolas Burk: So basically that idea that your entire application from your front-end, the front-end application that's running inside the browser to your back-end is coherently typed so that the types are flowing through your application. And at each layer of the stack, they turn into another type or flow into another type. But the big benefit of having this end-to-end type safe setup is that it allows you to do refactorings in a really, really easy way. For example, if you want to rename a field in the database, then if you have this end-to-end type safe setup, it would mean that you rename it once and that your TypeScript compiler then tells you all the other parts in your code where you have to update this particular field name. Nikolas Burk: So that's, I think one of the big benefits of this end-to-end type safe setup, which is basically just the benefits that you get with type safety anyways, but scaling across your entire stack. So let's talk a little bit about what that actually looks like indeed with GraphQL and Prisma together. So when you're building a GraphQL application and you're implementing that GraphQL API, you're typically faced with a decision, how you want to construct your GraphQL schema on the back-end. And there are two very prominent approaches for building your schema. One is called the SDL-First or a Schema-First approach, where you write out your schema definition of the GraphQL API as a string, and then you independently of that implement a resolver map. And then you combine the two and that ends up being your GraphQL schema instance that is serving the data when GraphQL queries and mutations are coming in. Nikolas Burk: And the second one next to this SDL-First approach is the Code-F,irst approach where you're implementing the entire GraphQL schema, including the schema definition entirely in code. And these are typically the ones that are also favored by TypeScript users because that Code-First approach, it just goes really well with TypeScript, but that doesn't mean that you cannot use SDL- First approaches with TypeScript. So that's equally possible. And in the same way, it's also possible to use code-first approaches with just plain JavaScript. Nikolas Burk: It's just that I think, or at least from what I've seen in the GraphQL ecosystem, TypeScript developers typically tend to prefer these Code-First approaches. And with these Code-First approaches, it's really nice that you can have these extra plugins that connect to your Prisma layer and leverage the information that you defined in your Prisma schema to expose your Prisma models via GraphQL. And for example, if we look at two of these code-first GraphQL schema libraries called TypeGraphQL and Nexus. Both of them have specific plugins or extra additional libraries that you can add to this schema layer that connect to Prisma. And that allows you to expose your Prisma models to your GraphQL API so that you save the overhead of redefining your database types on the GraphQL layer. But I think that oftentimes you still want to have some flexibility, and oftentimes it's not actually the case that you want your Prisma models which represent your database tables. Nikolas Burk: You don't want them to, one-to-one project to GraphQL types but typically there is a little bit of a transformation that's happening from the database to the API layer. For example, a user table that maybe stores a password in the database, but that password is not something that you want to expose on the API layer, because you don't want everybody to be just able to query the password of a user. So for these kinds of situations, it's still helpful to diverge from the Prisma model and these approaches with Nexus and TypeGraphQL, they allow you to do that as well. So it's just a super flexible way how you can basically add a GraphQL layer on top of your existing database layer fairly quickly. Ben: Got it. Yeah. And the ease of refactoring alone is a huge boon for developer productivity. So, I guess it seems like Prisma is pretty feature complete overall, but I'd be curious to learn a bit about the roadmap. What can we expect to see being added over the next year or so, and maybe what are a few things you think are missing today that you're excited will will come in the future? Nikolas Burk: Yeah, of course. I mean, one way how Prisma differs also from traditional ORMs is that it actually does a lot more than just the typical workflows that you expect from an ORM, but we also sometimes refer to it rather as a database toolkit, just because it does a lot more than just allowing you to create data and the database. And the way to think of Prisma is as this database toolkit that consists of three main tools. And the three tools are called Prisma Client Prisma Migrate and Prisma Studio. Nikolas Burk: Prisma Client is the component that you use inside of your application to send queries to your database. So that's kind of the workflow that we already discussed. It works pretty much just like any other npm module. You npm install @prisma/client, the npm package, and then you have that inside of your application and you can start using Prisma Client to actually send queries to your database. So, that's the first component. Nikolas Burk: The second component is Prisma Migrate, which is the migration system that Prisma provides. And similar to the migration flows that we already talked about, this is basically a way for developers to make changes to their database schema. So create new tables, delete tables, add new columns to tables and all of these workflows that you will have to do throughout the life cycle of your application. And the way how that works with Prisma Migrate is that every time you want to make a change to your database schema, you would go into your Prisma schema file. That's the main configuration file for your Prisma set up that I mentioned before, that contains your data model. You make changes to the data model. For example, you add a new model. And then with that new model in place, you can go ahead and generate the SQL migration file that will be stored on your file system to keep track of the changes that have been made to your database over time. Then of course, it also allows you to execute the migration against the database itself. So, that's Prisma migrate. Nikolas Burk: And then the third component is Prisma Studio. And Prisma Studio is definitely something that you don't see with any other ORM because that's sort of like a database IDE. It allows you to perform certain database workflows but in a very visual manner. At the moment, its main feature is a data browser that just allows you to very quickly view and edit the data in your database. So it compares to a lot of other database clients, such as PopSQL or a TablePlus, but these also still operate at a different level of abstraction. And to me, these kinds of database queries, they often feels like tools from the '90s. Whenever I'm using one of these, it just feels like a very heavyweight thing reminding me of the phpMyAdmin days. And Prisma studio really is the modern version of that. So like these are the three components that we are currently building. Nikolas Burk: And speaking off the roadmap and things that are planned, at the moment our biggest focus is on making Prisma Migrate production ready because at the moment Prisma Migrate is running in preview. We released the first preview release for it back in December and are on pretty good track to have the production ready version of Prisma Migrate most likely by the end of Q1. Please don't nail me down on that, I don't want to commit too much here but at the moment it seems like we are well on track for that. But then of course we have a couple of more things that are exciting. Nikolas Burk: And I think the biggest one is to broaden the range of databases that Prisma supports. At the moment Prisma only works with SQL databases. And specifically the ones that we currently support are PostgreSQL, MySQL, SQLite, SQL server, but we are planning to broaden the support to NoSQL databases as well. So a couple of databases that are really high on our priority list to support, of course are MongoDB. And another is, I think, DynamoDB and a couple of more databases that we want to support in the future. And quickly putting out a call to action for anybody who's interested in seeing support for more databases, we collect your thumbs up on GitHub issues for database support. So if you want to see a specific database, then go to the Prisma repo, find the issue with the database that you'd like to see supported and leave your thumbs up. And ideally a comment in that GitHub issue. And in case the database is not even there as a GitHub issue yet you're of course more than welcome to create that issue yourself. Ben: And I just want to dig in for a minute on the Prisma Studio side. I've used PopSQL quite a bit in the past, and I maybe agree with you that the UI isn't super modern, but it does certainly perform its function pretty well. So I'm just curious to dig in a bit and learn what specifically are the goals of Prisma Studio and how it will improve on some of those prior tools like PopSQL. Nikolas Burk: So I think one big difference with Prisma Studio also compared to these other tools is again, the level of abstraction. Because the level of abstraction that Prisma studio gives you is not SQL, but it's the Prisma layer basically. So what Prisma Studio shows you are the Prisma models that abstract away from the underlying SQL. Nikolas Burk: One very concrete example of what this actually means is for example, speaking of many-to-many relations. Many-to-many relations in relational databases are a little bit tricky to model because you need an extra table, this called join table or relation table. Some people call it intermediate table. I think there are just a couple of different terms to describe that table that stores the references for your many-to-many relations and in a database client like PopSQL you will see that extra table with its individual entries. But as a developer, if you care about the many-to-many relation, you would much rather want to see an entry in a row of say, we make it concrete, like say we have again the scenario of a blogging application and we have two tables that are a post and a category. So we have many-to-many relation because one post can be in many categories and one category can be on many posts. Nikolas Burk: In this case as a developer, I want to see, okay, which are the categories that a certain post is associated with. If we are operating on the SQL level of abstraction, then we have no way to quickly identify that because all we see is a relation table with a set of IDs that we first have to go and look up manually in the respect of posts or category table to map them to the individual posts or category entry. With Prisma Studio, you don't see this extra table. You just see a row with a post record that has a column entry for categories, and then you can click on these categories and you immediately see which categories it's associated with. So, that's the different level of abstraction again, that Prisma shows you. Nikolas Burk: And at the moment, Prisma Studio is limited to that functionality of just viewing and editing the data. But we have a lot of ideas for what the future for Prisma Studio could look like. And I think one thing that's pretty high also on our internal priority list is the schema modeling workflow. So when you think about how you want to exactly model your data, how you want to create your schema, of course, one way is to just type out all the models in the Prisma schema file. And a lot of people prefer that raw approach to defining models. But I think there are also a lot of people that prefer a more visual approach to data modeling. And this is certainly something that we want to enable sooner or later through Prisma Studio as well. Nikolas Burk: And on that note again, I also want to say that we care a lot about the ideas and the thoughts of our users. So again, a call to action for anybody who's listening to this and who has ideas for how Prisma Studio could improve or what kind of workflows they would like to see, head over to the Prisma Studio repo on GitHub and create GitHub issues with your ideas, with your feedback. We're always super eager to learn about these kinds of ideas that are coming directly from our community. So, please go ahead and share your feedback there. Kate: Yeah. Great. And we can link that in the notes here. That's a really good segue. It seems like there's a really healthy community around this open source repo and you have over 100 contributors, is that correct? Nikolas Burk: Yes. We have quite a few contributors. Although I think that for a lot of the core tooling that we build, I don't think that we get too many in-depth contributions. It's like mostly bug fixes, people implementing bigger features is fairly rare. And that's just because they're typically also is quite a bit of design work that goes into it that is done by our product team. And it's kind of impossible for anybody who's not involved in these kinds of internal discussions to figure out what a feature actually should look like. But we do get a bunch of contributions for smaller things like bug fixes. And also of course, things like documentation and all that. We get contributors there as well. Kate: Yeah. So I guess going along that line, what is it like to build your community? And then also, because it is also a business. We just talked to Zoltan Olah who's at Chromatic. So Chromatic is the company and then they actually maintain Storybook. How do you keep that level of trust with contributors as a business? Nikolas Burk: The first point about building community and how we do that at Prisma, we really deeply care about community. And that was the case from the very start of the company. So I've joined Prisma four years ago as one of the first employees actually. And like back in the day, we still were called Graphcool. And we're just very involved in the GraphQL community. And at that point already, we cared a lot about community and always being in touch with our users. So one thing that we had from the start of the company was a public Slack where people can just join and get in touch with us. And up until this day, this public Slack is running. And now it's more than I think, 40K members. And we are still super active in that Slack. We are responding to questions there. We actually hired somebody full time who'll just go and pick up questions on Slack and help our users there. So we really care a lot about the people that are coming into our community and making sure that they can be successful with the tools that we're building. Nikolas Burk: And the second part of that is also a feature that I'm really excited about actually, a GitHub feature that's called GitHub discussions. That's a new thing that you can enable on a repository that's sort of like a forum or like a question and answer board where people can ask questions. The reason why we introduced this is because our entire engineering process is happening on GitHub. And we really rely on people creating GitHub issues with bug reports and feature requests. These are regularly triaged by our product and engineering teams so that our entire engineering work is basically happening in public. And these GitHub discussions on the other hand, they are really for question and answers that are not going into the engineering process in any way, but just high-level questions and discussions about Prisma itself. And that also has been a big, big part of where our community is coming together and just asking questions and helping each other when they have any questions about how Prisma works. Nikolas Burk: So I think these two channels are super important, but we also do a lot in terms of events and social media. So we started back in the Graphcool days, we started the GraphQL Europe conference, which in its first year in 2017, I think we had 300 attendees. And then the second year we had 500 attendees of the conference. And then the third year we rebranded it to GraphQL Conf and it had around 800 attendees. Next to that we were also running a lot of different meetups. So we're running a TypeScript meetup in Berlin, we're running the GraphQL meetup in Berlin. We really care a lot about being directly in touch with our users as much as possible, and having always that direct communication line with our community. Kate: Great. And we will link to all those communities as well. Ben: Finally Nikolas, what are you most excited about in the future of front-end maybe specifically outside of the scope of Prisma? Nikolas Burk: One thing that I find really exciting in the frontend world at the moment, and it actually ties a little bit into the back-end world, it's React Server Components. So this new feature of React that allows you to render a component on the server side. And that way you can increase the performance, I think, of your application quite a bit in several ways. I think two main benefits of server components are that on the one hand, server components, they don't get bundled and sent to the browser. So if you're using huge npm modules in a React component and you can make this React component a server component. The code for that big npm module will not travel to the client. And you therefore save a lot of bandwidth, which is really nice. And the second benefit also again, relating to performance is that you can access all the things that you can access on a server directly from a server component as well. Nikolas Burk: And mostly these two things will be filed and your database. And of course, when talking about accessing a database from a server component, you again have the different choices that we talked about in the very beginning, how to talk to the database either with plain SQL or using these high level abstractions. So they are like Prisma also comes in pretty nicely again, to also help developers that want to talk to the database from a React server component to do that with Prisma and just send the database queries directly from a React component, which is something that's super new and super exciting, I think as well. Ben: Well, thank you so much for joining us. I really enjoyed this conversation and super interesting to learn about Prisma. We're going to put a bunch of links to some of these things we talked about in the podcast description and on the podcast homepage. Kate: Thanks for coming on Nikolas. Really appreciate it. Is there anything that you'd like our listeners to know? Nikolas Burk: Yeah. So I have recently come across a tool that I found super interesting. It's called Amplication. And this is a tool that is somewhat similar to a Backend-as-a-Service. so similar to Firebase or Supabase, these tools that provide you a back-end out of the box, but it's a lot more than that actually, because they also generate frontend components for you. So it's not really just the Backend-as-a-Service. So it's more like a Fullstack as a Service tool. And then what I think is particularly exciting about them is they allow you to bootstrap these projects initially, just like you're used to. You configure things in a web browser, you configure your data model, but then if you want to customize your application, you can actually go ahead and download the source code of the application and customize it to your needs. Nikolas Burk: So it's a really, really neat way to get started super quickly on a project and just use this web UI this approach as much as possible and as much as you're not hitting any major limitations for your requirements, but as soon as you have to customize it, it's super easy to just drop down and take the actual code and implement whatever feature you want. So I'm a big, big fan of what they're doing and everybody go ahead and check them out on amplication.com. Kate: Cool. Thank you, Nikolas. It was great to have you and I'll see around. Nikolas Burk: Thank you so much, Kate and Ben. Brian: Hey, it's Brian again. So it turns out that running a podcast is maybe harder than we thought. And so I want to hear from you. I'm genuinely interested in your feedback. We have to think about new topics, new guests, we have to find them. And don't get me wrong, we can do it, but it's a lot easier if everyone else who's listening helps. So if you'd like to suggest the topic or volunteer to be on PodRocket, we'd like to hear from you. So you can do that by going to podrocket.logrocket.com/contact-us, the hyphen is next to the delete key if you're curious. If all of that is too long, you can just email me directly, brian@logrocket.com. That'd be great. Also if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.