(gentle electronic music) - Now to the next speaker,
which is Daniel Norman. And he's gonna show us how
to use Prisma with MongoDB. It's something new, and I think there are many, many changes. Are they? - Hi, Aris. First of all, thank you
for the warm welcome. And yes, there are some changes as we're continuously evolving
the MongoDB connector, but I'll definitely get into that. - Thank you. I'm looking forward to hear your talk and find out more about those changes. - Let's do it. Okay. Let me just share my screen. And it looks like we have some video lag. Let's see if we can get that. Okay. That should work. So hi, all. Let me just get going here. Make sure it's all running. Great. So the internet connection is fine. Hi, welcome to Making MongoDB
Type Safe with Prisma. I think that Peter's talk
did a really, really nice job of showing a lot of the ideas of Prisma in the context of a full stack app. And in this talk, I hope to sort of take a step back and give the sort of broader
picture of what it means to use Prisma, what is type safety and how does that fit in with MongoDB. And I also invite all
of you who are watching to send your questions. You can just drop them as a comment in the live chat on YouTube, and I'd be happy to get to
those at the end of the talk. So I'd like to begin this
talk with a question, and that is what tools and practices make you productive as
an application developer? And I will share a bit
of a personal anecdote that I think might
inform a lot of the ideas that I want to present in this talk. So about 11 years ago, I started a job as a software developer for a company that was doing web crawling. And the main application
that I was working on had been written in PHP and
used Postgres as the database, and this application had
evolved over the years. It was a lot of spaghetti code in it, but it worked and we were using SVN. This is prior to us
adopting Git at the time. And there were no tests. The backend logic was
heavily, heavily coupled with templating and front end logic. We didn't actually have a
migration system for the database. So all schema changes
were carried out directly on the database and there was no real way to correlate schema changes
with the application code. None the less, I felt very productive. I'd write SQL queries, I'd write business
logic and just pump data to the front end. And the main problem there
was that I had no guard rails and often mysterious bugs
would pop up after deployment. And so counting on sort
of the amount of time that I spent debugging, I was
probably not as productive as I thought. Debugging was slow
because I would log data as it flowed through my
local development environment until I found the root cause. And in hindsight, this is no surprise. Data was flowing across
three different runtimes from the database to the PHP runtime, and then to the browser, and each runtime had its own
representation for the data. And there were no real
tools to sort of prevent from mishandling of data. And this was 11 years ago
and a lot has changed since in the software development world with new tools and practices that really focus on
preventing such errors. And so in today's talk, we will look at these
challenges when working with MongoDB's flexible schema, some of the existing solutions, and finally at Prisma's
approach to these challenges. In the first part, we'll explore these practices
that increase productivity and introduce some concepts,
such as the feedback loop. In the second part, we'll delve deeper into
the different approaches to schemas in MongoDB. And third, in the final part, we will look at how Prisma
makes MongoDB access type safe and increases productivity. So upon reflection on my
adventures and misadventures in the last 10 years of building these data intensive applications, a couple of noteworthy
practices came to mind when it comes to productivity. The first is testing, which really allows you to
verify the correct behavior of the software that you're building. And that includes, you know, unit tests, end-to-end tests, load tests. The second is automation, which reduces toil by automating
the repetitive aspects of the development life cycle. And so that, you know, for
example, that might include build processes, tests, releases, and deployments that are often automated by your CI/CD pipeline. And finally type safety, which is a broad term used, in the context of
statically typed languages like TypeScript and Go. But the idea with type safety is that by defining types in
your application code, you can detect these type errors
and type mismatches earlier by essentially running the compiler and of course, with TypeScript, you have built-in integration in VS Code. The same goes, I think, for Go since I used it a couple of years ago. And so you get this sort
of shorter feedback loop, which is I think the common thread to a lot of these practices
that I mentioned here. And so shorter feedback
loops are not a new idea. It's in fact one of the
cornerstones of agile development, and it really applies to many stages of the software development life cycle. And let's start with a definition of what a feedback loop is. So a feedback loop could be
defined as the process in which an action's effect
circles back to the action that triggered it, and
then used as feedback. For example, you push a Git commit into continuous integration
pipeline stance, and that either passes or not, and when it doesn't pass, it contains useful
feedback about what failed. And feedback loops are everywhere
in software development, because essentially as
a developer, as a team, or even as a company you're engaging in this iterative process of creation through experimentation and
feedback is so essential because that's how you
verify the assumptions, whether those are product assumptions or technical assumptions about, you know, the domain logic that you're implementing in your application. And so feedback loops vary in
terms of the amount of time from the action to the feedback. And for example, unit tests
are usually very quick to run, whereas end-to-end tests take longer. So the feedback loop is not
quite as tight as the one that you get with
something like unit tests. So let's see how this
idea of feedback loops maps to type safety by
comparing JavaScript and TypeScript. And so a type error... and we'll start with what
is a type error, actually. So a type error occurs when
a value in an operation is of a different type
from what the code expects. And so JavaScript is loosely typed and doesn't really support type safety. So for example, when you
define the following function, this get full name function, there are a couple of ways
in which you can encounter a type error. For example, if you just call it without passing anything in, you'll get an uncaught type error. And the main problem here
is that you will only detect this type error by
actually running the code, meaning that you'll only
detect this at the runtime of the code. Now, if you pass an
object that doesn't have one of the fields
expected by the function, JavaScript won't even throw an error. Instead, it will convert
this undefined to a string. And this is a feature known
as implicit type coercion in JavaScript. And again, the problem with this is that you only detect
these problems at runtime. And in this case you might even miss it because there's no error being thrown due to the implicit type coercion. In other words, you either
rely on your intuition or tests that actually
run the code to verify these kind of errors. And so in late 2012 TypeScript came along and suddenly offered developers
the following proposition. You add types to your Java script and we'll make life easier for you by catching errors for you. And so with TypeScript you'll
have to carry an umbrella, but when it rains, TypeScript
will catch these type errors and keep you dry. And so you eliminate this
whole class of errors. And TypeScript essentially works by adding type annotations or by
defining these types. And by adding these type
annotations, for example, here to the function parameters, you can statically verify
calls with invalid parameters and many other type errors. And so here you essentially
get a type error and you get that immediately
while you're writing the code, assuming that you're using
an IDE that has integration. So with VS Code, you
get the squiggly lines. And this brings us back to
the idea of the feedback loops because you get a very,
very tight feedback loop, because with VS Code, type errors show up as you type the code, thereby
reducing and tightening that feedback loop even further. And of course you can also
run the TypeScript compiler in your terminal and
then get the same errors and even integrate that
into your CI pipeline. This begs the question, how can we take this idea of type safety and then apply it to the
popular three tier architecture? The boundaries of web
applications across three tiers where you have the presentation layer that usually means the web client, or it can even mean just a native app, an iOS or an Android app. There's the application tier, which is where sort of your
back end business logic lives. And it's responsible for
sort of the coordination between user requests and the database. And of course the data tier, which is the source of truth
and where your data lives. Now, of course, this is assuming that you're building an application that handles
data and needs to store data. If you need to store data like
most applications today do, there's a very, very good chance that you're gonna be using a database. And so, okay. That was the
three tier architecture. But since most of the database
interactions are encapsulated in the server, in the application tier, what would it look like to
introduce type safety there? Let's go back to the code
sample that we looked at before and see how this might work
if we were to add type safety. And so let's say we wanted
to take this function, this function that finds
a single users document and then returns the first
name and the last name. Assuming that we wanted
to make this type safe, how could we do this? The get user function first
takes an object ID string, and then returns a document or an object. This is a challenge because
of MongoDB's flexible schema. And this is actually by design. So MongoDB's collections, by default, do not require their documents
to have the same schema. This means that documents
in a single collection do not have to have the same set of fields and the data type for a field can differ across documents within a collection. So just imagine the example
that we had Peter show us before where you had this blog post collection and that collection had say name, say it had first name, and then later you decided "I
wanna introduce last name." There's no way for you to guarantee that once you introduce that, that all of the old documents
will have the last name. And sort of, this becomes a real challenge with this flexible schema. There's no consensus
about what the data model should look like, and every
document in your collection contains slightly different fields. You end up managing a
lot of that complexity in your application layer. So what if we introduce a schema to ensure more consistency across
documents in a collection? Which leads us to the
second part of this talk, MongoDB and schemas. So there are a number of
solutions that have addressed the challenges of a flexible schema. And of course this is by no
means an exhaustive list, but these are the very common ones. The first is MongoDB's schema validation, which makes it possible for you to enforce a schema per collection. The schema is defined using JSON schema and it's enforced during
updates and insertions. And this approach, of course, the moment that you
introduce a schema validation in MongoDB, it only
applies to future writes, which means it doesn't
impact existing records in your collection. I believe this was also introduced in MongoDB version 3 at some point, and I believe that's sort of a testimony or sort of a reinforcement to the idea that introducing schemas to MongoDB is an idea worth pursuing. The second approach is Mongoose. Mongoose is a Node.js object
data modeling library. It's kind of like an ORM, but
mostly targeted at MongoDB. And it allows you to
essentially define and enforce a schema on the application layer. And finally we have Prisma. Prisma is a next-generation
ORM for Node.js and TypeScript. And central to Prisma
is this Prisma schema, which is a human readable data model. And it is of course also declarative, as we saw in Peter's example. And with Prisma you essentially
define the Prisma schema and the type safe client
is generated for you. And recently we introduced, earlier this year we introduced
the early access version of the MongoDB connector. And in July, we also
made a lot of progress and promoted that to preview, which is the state that it's currently in, which is the last stage before it reaches general availability, meaning
that it is production ready. So, okay, I spoke about
these three approaches to introducing a schema to MongoDB. How do these three compare? Well, MongoDB's schema
validation is enforced on the database layer. Whereas Mongoose and
Prisma enforce the schema on the application layer. Now, if we compare Prisma and Mongoose, Prisma is unique in that it
not only enforces a schema, but it provides type safe access, which makes you more
productive by shortening that feedback loop. So with Mongoose you get this validation, the schema validation, but
that happens at runtime. With schema, as you're actually... Sorry, with Prisma, as you're actually writing
your application code, you get those type safety verifications happening for you immediately, because it's relying on
the TypeScript compiler. And so you get sort of,
that's why the feedback loop is also shorter. And speaking of Schemas, it's worth noting that
conceptually speaking, schemas have a lot in common with types. And on the left here, we
have a TypeScript type, and on the right, we have an
equivalent JSON schema type. And it's interesting because
we treat these two things as being different, but
actually as our host today, and Peter might attest to, the word schema actually comes from
the Greek word "schima" which means shape. And so when we speak
about schemas and types, really we're speaking about shapes and those shapes are used
to describe shapes of data. Of course, this doesn't
mean that they are the same. They typically operate
on different levels. Types are validated during
compilation and have no impact on the runtime, while JSON schema is a runtime validation that you do. And this important is difference because you can validate a lot more about the shape of data during runtime, because assuming you
have input coming from say an API request, that's not something that you can necessarily
verify using your type system, because the type system
doesn't, of TypeScript say, doesn't run actually when
your code is running. So Prisma, I spoke and I
mentioned Prisma a bunch of times, and it's worth sort of
like giving an overview of what Prisma is. So Prisma, as I mentioned,
is a next-generation ORM for TypeScript and Node.js,
and it consists of three tools. The first one is Prisma Client, which is an auto-generated
and type safe database client. This is sort of generated for you based on the Prisma schema. You import that into your application, and then you can sort of start interacting with your database, writing,
reading, manipulating and deleting data. The second one is Prisma Migrate. Prisma Migrate is a
declarative data modeling and customizable migrations tool. And finally Prisma Studio, which is a modern GUI to
view and edit your data. Okay, so let's look at data
modeling with Prisma schema. The Prisma schema enables easy and intuitive data modeling,
I think I mentioned that, and it serves as a single source of truth for your application models. With MongoDB each model
maps to a collection. So each Prisma model maps
to a MongoDB collection. And in this model, this
example model that we have, we have this ID field, which
maps to the underscore ID, the default ID field in MongoDB. And we also have this
@db.ObjectId to denote the type. This then allows us to verify
that we're actually passing an object ID in Prisma Client. Then we have this first name
of type string, last name, which is an optional string. And finally email, which is of type string and has this unique
constraint added to it, a unique attribute. Now that was one model,
but what happens when you want to start introducing relationships? So here I extend that model, and then I add an additional one. I add the Post model, and what I'm defining is I'm defining a one-to-many relationship
between user and posts. So that means that a single
user can have multiple posts. And it should be noted that
Prisma will use references to model this relationship. Now take a moment to look at this schema because the examples that will
follow will be based on this. Okay. So what are the benefits? Well, working with databases
is still one of the most challenging areas of
application development. If you consider data
modeling, schema migrations, writing database queries, these are common tasks
that you have to deal with on a day to day basis as a developer. And as tools become more specialized, application developers
should be able to focus on implementing value-adding features to their organizations
instead of spending time plumbing together these
layers of application by writing a lot of glue code. And so the core benefits of Prisma are productivity through
shorter feedback loops with rich auto-completion
and less boilerplate, and second, confidence,
type safe database queries that can be validated at compile time. And these two pillars are embedded into Prisma's workflows and API. So let's take a look at what
Prisma Client looks like. So here I am showing a Prisma Client query that creates a document
in the user collection. And I spoke about these
two benefits before, productivity and confidence, but how does actually Prisma achieve this? Well, first thing is
auto-completion in code editors instead of needing to
look up documentation. You see that as I do the control space to show the allowed fields, I really can know what data I can actually pass into this query. And as you can see here, I'm
also passing an invalid field that isn't in the Prisma Schema, and I immediately get this type error. Prisma also focuses on
queries rather than classes to avoid these complex model objects that are very common
in active record ORMs. Prisma Client simply exposes methods that return plain old objects. Prisma schema is the
single source of truth for both your database schema
and your application models. You get this type safety and of course, less boilerplate so that
you can really focus on the important part of your application. And so working with relationships
is also quite a tricky part and the nested API in
Prisma Client makes it easy for you to reason about
storing related data. And so in this example, we create one document
in the user collection and two documents in the posts collection with a reference to that user we created. And we can see that, because
on the right hand side, you may notice that the
author ID is pointing to the same ID in the
root object of the user. And so let's take a look
at what that looks like in the database. And so that same query, if you look at it through MongoDB Compass, the sort of the MongoDB database GUI, which is more or less equivalent to what Prisma Studio does, you can also use Prisma Studio. You can already see how these are created. And here too, when you
are working with an object that you created in the database, you still get the same
degree of type safety when you're trying to access
the data that was returned, the object that was returned
from the Prisma Client query to MongoDB, and you have this again, this full auto completion. And this is done by
really leveraging a lot of the functionality that the
TypeScript type system provides. And so that was that. And I think it was pretty cool. I mean, I've been working
with Prisma for a while now, and so I'm kind of used to
this developer experience, but it is pretty amazing
to see this in action. And it is worth sort of asking how does this all work and
how does Prisma achieve this? And really it all starts
with the Prisma schema, the single source of
truth, as I mentioned, and it is used to generate Prisma Client, which you then import into
your application code. And since Prisma introduces a schema, and obviously we're talking
about how to stay productive while still introducing change, most of us developers are
actually constantly changing, whatever we're building, new
assumptions, new features, bug fixes, and so on. And many times those involve changes to also your database
schema or your data model and the information that you
want to store in your database. For example, imagine from
Peter's example before that you wanted to add a
view count for each post. You know, that would involve
actually adding this new field to new documents that you're creating. And so how do you evolve
this schema that you have when you're using Prisma? This is really where
Prisma Migrate comes in, the declarative database migrations tool. And our vision at Prisma is
to really enable developers to easily evolve their schema
and manage data migrations. We've already seen the great success of many developers using Prisma
with relational databases. And we wanna take a lot of those insights and apply them into MongoDB too, of course, given all of the differences when working with MongoDB. And so introducing a schema
to MongoDB poses a challenge, because as I touched on
in the previous slide, how do you maintain that
consistency across documents when you change the schema? For example, how do you
add a new required field to a collection with existing data? This typically requires you
to migrate existing documents so that they can adhere
to the updated schema with this new required field. And there are several approaches to this. The first one is doing an
all at once data migration, where essentially once you
introduce the new feature, or even prior to that,
you go to your database, you look at all of the
existing documents and say, you migrate them and add this
new views field set to zero. There's also the on demand approach, where you add a new field
to your Prisma schema and then gradually update
existing documents. And this is the approach
also that Mongoose takes, and it's also possible with Prisma. So coming back again to the
view count on posts example, assuming that you already have
some posts in your collection in MongoDB, and you want to
introduce this new field, then you might want to sort
of go and do a batch update to all of those setting that to zero. That would be the all at once and then doing it on demand would be every time you fetch it, you
can either set a default, which means that default will kick in and you will get zero if it's
not defined in the document. And then when you write it, it will get persisted in the
next write to your database. Then you have the non
breaking change policy, where you essentially
just introduce a policy in your continuous integration
or whichever tooling you use, to check basically to
only allow adding fields and never allowing changing
or removing fields. And then finally you
have the final approach, the background integrity checks, which is an approach where
you essentially run checks for consistency in the background. And then when an inconsistency is found, you either alert the
developer to update the data, or you, based on the structure of the data in that code, you decide, "Okay, how do I wanna migrate this?" So you might just do a routine
check to see which documents don't have the view count
field and the ones who don't, you set it to zero. Now in the last two years, a number of new frameworks
have chosen Prisma as their default ORM. You have RedwoodJS, which was created by the GitHub co-founder,
Tom Preston Werner, and it is a full stack framework based on React and GraphQL. You have Blitz, which is
a full stack framework based on React, that also
does away with the API layer, essentially giving you a
way to make calls directly from your front end to back end without having to think
about the whole API layer. You have KeystoneJS, a headless CMS that also uses Prisma under the hood, Amplication, which is a tool set for building full stack
apps based on React and SJS, and finally Wasp, which is a DSL for developing full stack
web apps with React. And so Prisma really is
the result of the learnings that we've gathered from
being an early innovator in the GraphQL ecosystem, and the insights we've
gained into the data layers of many different companies
from small to midsize to even major enterprises. And as I reach the end of this talk, I'd like to share a bit more information about the current state
of the MongoDB connector, and also what you can
expect in the near future. So since July, 2021, a
couple of months ago, I believe it was actually
just a month ago, MongoDB support is now in preview, which means it's still
not production ready, but it is already sort
of started to stabilize. And there are a bunch of
limitations that I thought are worth pointing out, if you're planning to use Prisma with MongoDB. The first is that there's still no support for embedded documents that are typed. You can use embedded documents right now using just the JSON type
in your Prisma schema. But we really want to
enable developers to choose which data modeling
approach they want to take. If you want to use references, or if you want to do embedding. These are the sort of
the two main approaches to data modeling in MongoDB. And so right now you can sort
of use embedded documents using the JSON type, but
in the very near future, and we already have a
proposal that was published as part of the previous Prisma release about how you would be able
to use the Prisma schema to type your embedded documents. There's also the second
topic, which is indices. So currently you have to define an index directly in the database. And of course our plan is to
allow, as you define those, like if you add an @unique
in your Prisma schema, that Prisma will automatically
create those indices for you in the database. And then finally adding
Prisma to an existing project that uses MongoDB. And so as a big topic of the talk was how do you introduce a schema and how do you ensure
consistency across documents? And when you want to introduce Prisma into an existing project, our current thinking is
that you should be able to sort of have Prisma
introspect your database and create, of course,
populate the Prisma schema, but also create a feedback loop to inform you about all
sorts of inconsistencies across documents in
your MongoDB collection. And so we plan on moving really forward with all of these things. And this is also where you come in. So if you are interested in this, I would highly recommend you to check out the Prisma MongoDB connector,
and provide us feedback. And so that way we can
address these quickly and bring the MongoDB connector to GA. And so just to sort of
summarize today's talk, we looked at some of the practices that increase productivity as a developer, by looking at type safety
and feedback loops, we then looked at some of the parallels between types and schemas and explored the different solutions to having a schema in MongoDB. And finally, we looked at
the confluence of these ideas in Prisma, and how it
enables you essentially to be more productive with
your MongoDB database. And so on that note, I'm excited to invite you to try it out. You can do that at pris.ly/mongo. That will forward you, redirect you to our getting started guide. And with that, I'd like to
thank you for listening, and I'd be happy to take any
questions if you may have. We also have, I should point out, we also have some of these
MongoDB Prisma stickers, and I'll find the link. If you're interested, we can
send them to you for free. So that was that from me.
And thank you once again. - Thank you very much for this
talk. I really enjoyed it. I wanted to say a bit more about... and I like the last slide where you have the journey for Prisma and how it has evolved. I've been using it from version 1 where you had to have a GraphQL client, And then I was quite
excited when I found out that you can just use the client directly with your code. You don't have to have another
layer of the GraphQL layer. You don't need to actually learn GraphQL. You just straight like JavaScript, or TypeScript would be more type safe. And that's the coolest
thing about type safety. We can also bring Peter
as well in the panel. So we can have like a small discussion between the three of us. - Certainly. Yeah. So thank you, both
of you for this nice talk. I have one question before
we start this conversation that came up. There are a lot of people that currently use different databases with Prisma. You can use SQLite, you
can use other databases. How difficult will it be to
migrate from another database to MongoDB with your new connector? - Yeah, that's a good question. I guess it really
depends on which database you want to migrate from. In all of my experiences
I've rarely encountered a situation in which a
company just decides, "Oh yeah, we're gonna switch
from a Postgres to MongoDB. No problem," you know? Because the tooling is
just not being there to really allow for these kinds of things. And especially if you're dealing with companies and applications
that really require a lot of, like require high availability and that they're constantly
accepting traffic. This can be a real challenge. But if you're already in a situation where you have the privilege of say
shutting the application down, putting it in maintenance
mode for a couple of hours, theoretically, you could
do a migration like that from one database to another. But on that note, I think
it's also worth pointing out that usually, you know, you pick a database very
early when you start a project and it's rare that you change it. And you usually pick that
database for whatever reasons you had when you chose it. And so while it is possible to
do these kinds of migrations and really Prisma gives you a unified API where you essentially
interact with one database and another more or less
the same way, of course, there's nuanced differences
between how each of these work, then it should be possible. But the general sort of
MongoDB really encourages a lot of de-normalization. Whereas relational databases
take the opposite approach where they encourage you
to normalize your data. And so while it is possible, I'm not sure how many
people are actually facing this problem. - Yeah, yeah, no, that makes sense. Yeah, because the sort of big key thing about Prisma is that you can connect
to any database you want. You can do Postgres, you can
do MongoDB, you can do SQLite. It's very easy to host your application in Heroku or Netlify, or Vercel, I suppose. So, yeah, it's an environment friendly to any kind of environment, yeah. Peter, do you have anything that you would like to discuss or ask? - Yep. Certainly. First of all, thank you, Daniel,
for the great presentation. It was something that I
really was looking forward to. Something that I'd really
like to add is that also the inspiration that came from what you showcased
about the different layers that an application involves, for example, the presentation layer,
the application layer and the database layer. Actually, I was really surprised. I was pleasantly surprised in the way that the typings that are generated
from the Prisma Client, basically, if also you
can see the showcase of our example application, the only types that exists
across server, client, and also any code that has
to do with data access layer, they are the types generated from Prisma. So for all the engineers out there, trying to architect an application and wants to have these, let's say this type safety and the capability to minimize
errors as much as possible. I consider that a superpower. Having types, setting them
between the application layer and the database layer, which Prisma has, let's say the full control
of the optics and the end, these are flown from
one side to the other. And even on the view layer side of things, for example, in my application, I used exactly the same types
and everything was great. So I consider the modern
stack with TypeScript, typed interfaces and also the
great work that you have done on the MongoDB connector. It gives you super powers, so yeah. Congrats on that. - Thank you, Peter. Thank you also for
sharing your perspective and giving the talk, really showing how this would be used in practice. - Yep. And actually this could have been just a showcase, but to be honest, in
most of the, let's say the companies that I've worked and the projects that
I've undertaken from, from enterprise down to
startup level, et cetera, the correct modeling and reliance on these simple structures,
which flow across all the, let's say the specific layers, and let's say the APIs,
the client interfaces, of an application, this is what makes a product,
let's say less error prone, much more routine, testable, which is something that we
haven't touched in this talk, but it's something of much
importance, great importance. And yeah, certainly this all starts with the main types of the
entities that you have. So yeah, I'm really looking
forward to what other stuff will be built with all these modern and next-generation ORM that
you're introducing there. - Yeah, Likewise. I also think we had a comment from someone who wrote "tricky part, not connecting, but most likely migrating all the data from one
database to the other." And I totally agree with that comment. - Yeah. the cool thing about Clerk and Prisma is the, you know, the speed. Because when most of us where we have to create stuff quite quickly, the expectations for
developers is it has increased. There are too many projects to do, but there are not many developers. And that's what most of
the clients find right now. So as a front end developer myself, the difficulties that, you know, I don't know a lot about
Node, I don't have to do all this kind of stuff
that Prisma does for me. So just the only thing
then to do is to create all these end points and start
using them straight away. And then with migration, on I think one of your slides that you, you said with us is when you change the, when something that changes in the data, you are able to see that, right? Could you tell us a bit more about that and then explain how that
will be quite beneficial for the front end developers themselves? How much time they will save? - Absolutely. Yeah. I think it's maybe worth starting with say, relational databases. Because that's where
these kinds of migrations are really something
that you plan in advance. The whole point, you know with MongoDB is that you have this loose schema. So assuming you're using
a relational database and you wanted to add a
new field or a new column, so to say. And I think I can give the example of say, you have a user model and
you have a post model. They have a one-to-many
relation between the two, and you want to now introduce a new field to the post model. And that is a view count. So how would you approach this
with a relational database and what does that mean for
you as a front end developer? The first thing is how would
you introduce this change? Well, the first question
you have to ask is, do you want this to be a required field? I generally lean on
making something optional only when it actually
is absolutely optional. The moment that you make
too many things optional, you create too many variants. So unless you absolutely
need it to be optional, I will usually introduce a new field as something that is required. And that obviously poses a challenge, because what do you do
with the existing records that you have that don't have this? And so the general approach
is you can use a default. And once you introduce
that to your Prisma schema, you run Prisma Migrate Dev. This is the part of the
part of Prisma Migrate, the command that generates
the SQL migration for you. And when you create that, you can actually edit the SQL and define how you want this new field to impact existing users, sorry, existing records or rows. And so you have the option of
either setting the default, which will automatically apply
to all of the existing ones that didn't have it. Or you can actually manually go ahead and edit the SQL and
modify existing documents based on whatever parameters
and whatever logic you decide. The moment that you
finish that Prisma Client is already generated for you, and you have access to that
field through the types. And you can sort of, if
you're building an API, you can also send that through the API. If you're using something like GraphQL, you might want to say, "Oh,
I want to introduce this to the post type in my GraphQL schema." And it will have say the type integer. And then the moment that
it's in your GraphQL schema, of course, this really
depends on how your front end interacts with the backend. But assuming that it's a GraphQL schema, then essentially you now have
the option to query that field through your GraphQL schema,
and then you can choose to use that in your front end. That is more or less
sort of like the approach that you would take when
introducing a new feature using Prisma and a GraphQL API. With REST, it's also
more or less the same. You can just add the field
to the API end point. And then it's up to the front end to decide how to use that field, that it now receives in the same API call. Does that make sense? - Yep. Yeah, yeah. Sounds really cool. Some of the features that
people maybe don't know and when, you know, it was
like, it saves a lot of time, like, you know, that's
the main kind of benefit. Yeah, definitely. So what is the next feature
that they're coming up with Prisma? That you are very excited about? Because I think there are many, but some of them that you
are very excited about? - Well, I should probably start with all of the preview features that hopefully will reach
general availability in the very near future. And so one of those is
obviously the MongoDB connector. There's also the SQL Server connector, which is gonna be released
to general availability. There's also some added
Prisma Client functionality, like the ability to order by relations. But one of the things I'm
really, really excited about is I think Prisma has
already gotten to the point where the Prisma Client
API is quite robust. And it really allows you
almost the same flexibility that you would get with
other ORMs, if not, I mean, the developer
experience in my opinion is obviously better. And we've really played a lot of catch up in really providing all
of this functionality that it now provides. I think what will become
really interesting is the Prisma Cloud product. So we're working on the Prisma data proxy. And the idea with the Prisma data proxy is that it will give you, it is part of the Prisma Cloud product that we're building right now. And the data proxy is gonna make it a lot easier for developers
who are using serverless to use Prisma with serverless. Because one of the main challenges today for using a relational
database with serverless, and irrespective of if you're using Prisma or any other tool, is
that a serverless function can only handle a single user connection. Unlike Node.js processes that can handle, their whole point is that they can handle multiple HTTP connections. So what actually happens, say if you deploy a Vercel app
that connects to a database is that each time someone calls the API, a function starts and the
function actually initiates a connection to the database
in order to send the query. And why is this a problem? Well, you basically end up
having as many connections to the database as you have user requests. This is with serverless. Whereas with the more
traditional Heroku kind of style where you deploy your app, and you have a single instance that handles multiple requests, you have a single server that
maintains an open connection to the database and can
handle and multiplex multiple user requests. And why is this a problem with serverless? Well, databases actually, it's quite expensive with
most relational databases to open up a new
connection to the database. The first thing you
have is TLS termination, which adds some overhead, but beyond that, actually,
the database itself has to allocate resources in order to open up a connection to it. And so every time this happens it really, applications that use a relational
database with serverless, they tend to suffer from a
lot of performance problems. And so the general sort of
approach to this problem has been to introduce something
like a connection pooler. But if you're using serverless, the whole point is that you want to avoid the operational overhead of
deploying stuff to the cloud. So the moment that you
have to suddenly introduce a connection pooler like PgBouncer, you actually eliminate sort of the benefit that you got from serverless, you know, making you not have to
worry about infrastructure. And so the idea with this,
the Prisma data proxy is really to make it easy for
any developer using Prisma with any of the supported databases really to get this free data proxy, which essentially solves
this problem for you. This is only one part
of the cloud product, and the vision is much broader. You can already today
use the cloud product. You can go to cloud.prisma.io. And what you can do is you
can create a new project. You can create a new Prisma project and also provision a database in Heroku, all of this is free and available. And you get sort of an
online data explorer and you can invite
collaborators that can also view the data. And so I really think that, sort of the future of Prisma really lies in sort of two facets. The first facet is
really improving Prisma, the actual open source stuff, so that you can really
have the full flexibility to do everything you want. And then the second thing is really adding some more functionality
to the cloud product to really improve the
workflows for mid-sized and even larger teams. But sort of the grand
vision is really that Prisma together with the cloud product can really help you stay productive from the stage of being, you know, a weekend indie hackers pirate all the way to becoming
a large scale company. So I hope that answers your question. - If you go that way, where's your, where's your data located? Is it in Prisma in the Prisma Cloud? Or is it in, you can host somewhere else? - I mean, you fully control your database. So you can connect it to
any supported database, or you can use the UI in
order to provision a database on Heroku, you currently can do that. And yeah, we don't own your database. We're just sort of sitting in the middle and just enabling a lot
of the workflows around it and the connection pooling
with the data proxy. - That's cool. Peter, do you have any
question you wanna ask? - Well actually the reason, let's say what Daniel has explained, sounds pretty exciting to have, let's say I've seen some
similar solutions in more, let's say, closed provider
spaces, for example, the Amazon RDS Proxy,
which does the thing, but it's internal to AWS. So I really consider, let's say, the case that you don't
need to own the data, but provide this thing for the client, that's a great benefit. And certainly it pertains a whole slew of excellent
technology there. And definitely the
concept of Prisma becoming more like a place that
you can, let's say start as Daniel said, your pilot
project up to, let's say, the enterprise requirements and providing this cloud interface certainly would, let's
say because at least in my perspective, the
Prisma developer experience is excellent. And I mean, the actual in
the trenches experience, not someone that the
product manager would say, but as an engineer,
working with this product. And definitely the capabilities become also something more, let's
say a collaborative tool in the cloud like Airtable is. And I believe this is close to, what's been teased here
for like one feature set of the Prisma cloud, if I'm not mistaken. Yeah, I think that that's
a great space to be in. Yeah, that's gonna be it. I'm pretty excited for the
features that are coming over. Really cool. Really cool, Daniel. - Thank you. Thank you very much. And I thought maybe if we
have a couple of moments, I can quickly share my screen and maybe give a quick
overview of the cloud platform, because, you know, you
sort of like talked about Airtable and how it might compare. And I thought that if you'd be interested, I'd be happy to sort of give
like a quick, quick demo. Do we have time for that, Aris? - We have like 5, 10 minutes max. - Yeah. I don't need that long even. So I'll just quickly share my screen here. So basically here I logged
into the Prisma Cloud platform. Again, either of you can just go ahead and try it out at cloud.prisma.io. And this is a project
that I've already sort of, I have it deployed. I think it's deployed to
Railway Cloud platform. And basically here I can view
my schema for this project. This is actually coming
from the GitHub project. So if I open up GitHub, really, this is just pulling it from here. And really the nice thing
that I can do here is first of all, I can invite, I can invite users and
give them different roles. So for example, I could give
Peter some viewer access, which means he would be
able to explore the data in the database without
the ability to change it. And then we have the data browser, which is essentially a hosted
version of Prisma Studio. And here really I'm directly interacting with my database. And so I can add records and there we go. And now it should reload in a moment. And there we go, we have it. And so, you know, you get
all of this functionality, I can explore the relations,
I can open them up. And really I have the full ability to access my data directly. So this is where it is right now. And the idea, then one of
the next features will be to give you the ability to use the data proxy so that you can connect it through here. And also there's gonna be a query console, which means that you'll be
able to actually try out Prisma Client from within the browser and sort of like get a feel
for the different queries. And you can do that against,
you know, your real database. So these are some of the things, and of course the onboarding
flow, you know, you can, if you're really new to Prisma, you can just go to create new project. You can... JS Monthly London, you can actually just
create a new project. I'm gonna provision a database. I hope that my Heroku
account can handle this because I think I've already created so many free databases on
Heroku that I'm not sure it'll allow me to do that. Okay. I have to log in. So I won't do that now, but the idea is that it will
provision a database for you. It will actually create
the database schema from a bunch of samples
that you can choose, and you can really like
already get a feel for Prisma. So that's basically where
the Prisma Cloud product is. And yeah, if anyone's interested, you can already check it out today. So that was it from my side. Thank you for the space
to do this and to show it. - Great. I'll definitely check it out. - Yeah, no, that was really good. I like that. Because when I first
tried the Prisma version 2 on a hackathon, I had to do
like a hack to upload the, to run the migrate function on Heroku. Where this is like pretty
straight forward to do it. It's yeah. (laughs) I'm laughing, but it's
laughing like from excitement. But yeah, it's amazing. - Good. - Okay. So yeah, I think
we can end it here. But it has been a really nice meet up. We did a bit more because
we had so many questions from the whole I think. The guys at Clerk, they
have in the roadmap also to do a Prisma integration. So it's quite exciting
that we have you both here for this meetup. And yeah we have another
meetup in 12 days. So we will have another
like Prisma talk there. And yeah, we'll see you
all in the conference. I hope you can watch the online, or if you happen to pass by London, you can say hi and be there. But thank you very much for everything. And your talks are gonna
be going online hopefully, and people can watch them later. Have a good day. - Thank you, Aris. And thank you, Peter,
- Thanks. - All the best and thank
you to the viewers at home. - Thank you.
- Bye, everyone. Bye bye. (gentle electronic music)
