Applying React Principles to a Cloud Database

Hi, everyone. I'm Michael. I'm a software engineer at Convex. I've been building full-stack apps for over 15 years. And as you all probably know, React has revolutionized the way we build interactive front ends for our apps.

But when it comes to building full-stack apps for multiple users interacting with each other, the React principles that help us build great front ends kind of break down. So at Convex, we set out to build a back end and a database that carries these principles to the full-stack developer and user experience. And today I'll talk about five of these React principles, and each is solving a problem that I'm sure many of you have encountered.

So the first principle is reactivity. We're going to build a todo app in React, everyone's favorite demo. So what happens when I tap into todo and hit enter? I update my state, and React automatically renders the list of todos. Super easy. But what about if I want to store the list of todos in a database? I'm going to need a read endpoint and a write endpoint, and when I hit enter, I call my write endpoint, but nothing actually happens automatically. I'll have to instruct React or my framework to refetch the read endpoint, and this can get quite difficult and complex as apps grow in complexity, and it won't even work at all if another user is the one adding the todo into the list. So with Convex, you can build endpoints which are as reactive as your state. In this example, I just write the todo into the database, and the database figures out for me that the list of todos needs updating, pushes the updates to all clients, and those trigger React to re-render automatically. And that's all it takes.

The second principle is consistency. I don't know about you, but inconsistent UIs frustrate me. Have you ever been on Slack or Instagram and there's a red badge and you click on that icon and you open a list and there's nothing there? Well, the reason that happens is because that red badge and the list in the tray are powered by different backend endpoints and they're fetched separately. So client-side React itself doesn't have this problem. If you have some state and then you're rendering a tree of React components, the view you get is always consistent. But once we add a database and we separate the data fetches, you might get an inconsistent view from your database. So Convex, on the other hand, is always consistent. In this example, when the data changes, the database figures out that those two reads need updating and pushes the update together to the client, and then the client instructs React to render a consistent result in a single pass.

The third principle has to do with overlapping writes. The simplest example you can demonstrate this on is incrementing a counter. You need the current value and then you update the counter to the current value plus one. And in React, we can ensure that this always works correctly even if there are multiple places where the state can be updated, multiple state updates together by passing an updater function to the set function. React then runs all state updates serially so that two updates can't mess up each other's logic.

Hi, everyone. I'm Michael. I'm a software engineer at Convex. I've been building full-stack apps for over 15 years. And as you all probably know, React has revolutionized the way we build interactive front ends for our apps.

But when it comes to building full-stack apps for multiple users interacting with each other, the React principles that help us build great front ends kind of break down. So at Convex, we set out to build a back end and a database that carries these principles to the full-stack developer and user experience. And today I'll talk about five of these React principles, and each is solving a problem that I'm sure many of you have encountered.

So the first principle is reactivity. We're going to build a todo app in React, everyone's favorite demo. So what happens when I tap into todo and hit enter? I update my state, and React automatically renders the list of todos. Super easy. But what about if I want to store the list of todos in a database? I'm going to need a read endpoint and a write endpoint, and when I hit enter, I call my write endpoint, but nothing actually happens automatically. I'll have to instruct React or my framework to refetch the read endpoint, and this can get quite difficult and complex as apps grow in complexity, and it won't even work at all if another user is the one adding the todo into the list. So with Convex, you can build endpoints which are as reactive as you state. In this example, I just write the todo into the database, and the database figures out for me that the list of todos needs updating, pushes the updates to all clients, and those trigger React to re-render automatically. And that's all it takes.

Hi, everyone. I'm Michael. I'm a software engineer at Convex. I've been building full-stack apps for over 15 years. And as you all probably know, React has revolutionized the way we build interactive front ends for our apps.

But when it comes to building full-stack apps for multiple users interacting with each other, the React principles that help us build great front ends kind of break down. So at Convex, we set out to build a back end and a database that carries these principles to the full-stack developer and user experience. And today I'll talk about five of these React principles, and each is solving a problem that I'm sure many of you have encountered.

So the first principle is reactivity. We're going to build a todo app in React, everyone's favorite demo. So what happens when I tap into todo and hit enter? I update my state, and React automatically renders the list of todos. Super easy. But what about if I want to store the list of todos in a database? I'm going to need a read endpoint and a write endpoint, and when I hit enter, I call my write endpoint, but nothing actually happens automatically. I'll have to instruct React or my framework to refetch the read endpoint, and this can get quite difficult and complex as apps grow in complexity, and it won't even work at all if another user is the one adding the todo into the list. So with Convex, you can build endpoints which are as reactive as you state. In this example, I just write the todo into the database, and the database figures out for me that the list of todos needs updating, pushes the updates to all clients, and those trigger React to re-render automatically. And that's all it takes.

The second principle is consistency. I don't know about you, but inconsistent UIs frustrate me. Have you ever been on Slack or Instagram and there's a red badge and you click on that icon and you open a list and there's nothing there? Well, the reason that happens is because that red badge and the list in the tray are powered by different backend endpoints and they're fetched separately. So client-side React itself doesn't have this problem. If you have some state and then you're rendering a tree of React components, the view you get is always consistent. But once we add a database and we separate the data fetches, you might get an inconsistent view from your database. So convex, on the other hand, is always consistent. In this example, when the data changes, the database figures out that those two reads need updating and pushes the update together to the client and then the client instructs again React to render a consistent result in a single pass.

The third principle has to do with overlapping writes. The simplest example you can demonstrate this on is incrementing a counter. You need the current value and then you update the counter to the current value plus one. And in React, we can ensure that this always works correctly even if there are multiple places where the state can be updated, multiple state updates together by passing an updater function to the set function. React then runs all state updates serially so that two updates can't mess up each other's logic.

Hi, everyone. I'm Michael. I'm a software engineer at Convex. I've been building full-stack apps for over 15 years. And as you all probably know, React has revolutionized the way we build interactive front ends for our apps.

But when it comes to building full-stack apps for multiple users interacting with each other, the React principles that help us build great front ends kind of break down. So at Convex, we set out to build a back end and a database that carries these principles to the full-stack developer and user experience. And today I'll talk about five of these React principles, and each is solving a problem that I'm sure many of you have encountered.

So the first principle is reactivity. We're going to build a todo app in React, everyone's favorite demo. So what happens when I tap into todo and hit enter? I update my state, and React automatically renders the list of todos. Super easy. But what about if I want to store the list of todos in a database? I'm going to need a read endpoint and a write endpoint, and when I hit enter, I call my write endpoint, but nothing actually happens automatically. I'll have to instruct React or my framework to refetch the read endpoint, and this can get quite difficult and complex as apps grow in complexity, and it won't even work at all if another user is the one adding the todo into the list.

So with Convex, you can build endpoints which are as reactive as you state. In this example, I just write the todo into the database, and the database figures out for me that the list of todos needs updating, pushes the updates to all clients, and those trigger React to re-render automatically. And that's all it takes.

But in a database, which can have many tables, each with many rows, you can't just serially run every mutation. So that's where transactions come in, and they do solve this problem. The issue with current backends is that transactions are costly and therefore optional. It's super easy to write backend code like this, and for it to fail, not in tests, not during development, but only in production when you get sufficient write volume to get those concurrent writes to mess up each other's logic.

React is designed so that transactions are cheap. This allows it to require that every end point that writes to the database runs as a transaction automatically, ensuring that no concurrent write can mess up its logic. The fourth principle relates to caching. A React component is a pure function from props and state to the rendered UI. And this allows us to cache rendering of components easily with React memo. That leads to improved performance. Caching is even more important on the backend, where it's the server owner, sometimes us, paying the computation cost, not the user. But caching today on the backend is hard because cache invalidation is not automatic.

And the final principle I'll mention is that React is just JavaScript, right? And this principle gives React several great properties. It is highly composable, easy to build on top of, and comes with great optional type checking, thanks to TypeScript, as we've heard before. And JavaScript is getting ever more popular on the backend, which is great, but when it comes to databases, the most popular options seem to be Postgres and MySQL. And SQL is the opposite of JavaScript. It is hard to compose, hard to build on top of, and has no static type checking itself. And this lack of composability leads to complex queries which the database tries to optimize, which then leads to unpredictable performance. And this is why the API from the convex database is just JavaScript. It is simple, highly composable, easy to build on top of, and fully typed, allowing end-to-end type safety all the way to the client.

So taking these five React principles and applying them to the full stack radically simplifies the building of apps and enables a better UX. And of course, this backend needs to scale with your needs. So we are building such a backend at convex. It is fully open source, comes with a dashboard, and a bunch of features, text search, file storage, scheduling, more that I didn't get to talk about.

The second principle is consistency. I don't know about you, but inconsistent UIs frustrate me. Have you ever been on Slack or Instagram and there's a red badge and you click on that icon and you open a list and there's nothing there? Well, the reason that happens is because that red badge and the list in the tray are powered by different backend endpoints and they're fetched separately. So client-side React itself doesn't have this problem. If you have some state and then you're rendering a tree of React components, the view you get is always consistent.

But once we add a database and we separate the data fetches, you might get an inconsistent view from your database. So convex, on the other hand, is always consistent. In this example, when the data changes, the database figures out that those two reads need updating and pushes the update together to the client and then the client instructs again React to render a consistent result in a single pass.

The third principle has to do with overlapping writes. The simplest example you can demonstrate this on is incrementing a counter. You need the current value and then you update the counter to the current value plus one. And in React, we can ensure that this always works correctly even if there are multiple places where the state can be updated, multiple state updates together by passing an updater function to the set function. React then runs all state updates serially so that two updates can't mess up each other's logic. But in a database, which can have many tables, each with many rows, you can't just serially run every mutation. So that's where transactions come in, and they do solve this problem. The issue with current backends is that transactions are costly and therefore optional. It's super easy to write backend code like this, and for it to fail, not in tests, not during development, but only in production when you get sufficient write volume to get those concurrent writes to mess up each other's logic.

The fourth principle relates to caching. A React component is a pure function from props and state to the rendered UI. And this allows us to cache rendering of components easily with React memo. That leads to improved performance. Caching is even more important on the backend, where it's the server owner, sometimes us, paying the computation cost, not the user. But caching today on the backend is hard because cache invalidation is not automatic. Take the to-do list example. We want to cache the list of to-dos but when a new item is added, a traditional backend doesn't know it needs to invalidate the cache. Again, we need to instruct it manually. So convex's database tracks which writes impact which reads, and in convex, read end points are pure functions from database state to the result. Therefore, if no relevant writes happen, the read end point can be cached automatically and with perfect caching validation.

But in a database, which can have many tables, each with many rows, you can't just serially run every mutation. So that's where transactions come in, and they do solve this problem. The issue with current backends is that transactions are costly and therefore optional.

It's super easy to write backend code like this, and for it to fail, not in tests, not during development, but only in production when you get sufficient write volume to get those concurrent writes to mess up each other's logic. React is designed so that transactions are cheap. This allows it to require that every endpoint that writes to the database runs as a transaction automatically, ensuring that no concurrent write can mess up its logic.

The fourth principle relates to caching. A React component is a pure function from props and state to the rendered UI. And this allows us to cache rendering of components easily with React memo. That leads to improved performance. Caching is even more important on the backend, where it's the server owner, sometimes us, paying the computation cost, not the user. But caching today on the backend is hard because cache invalidation is not automatic. Take the to-do list example. We want to cache the list of to-dos but when a new item is added, a traditional backend doesn't know it needs to invalidate the cache. Again, we need to instruct it manually. So convex's database tracks which writes impact which reads, and in convex, read endpoints are pure functions from database state to the result. Therefore, if no relevant writes happen, the read endpoint can be cached automatically and with perfect caching validation.

The final principle I'll mention is that React is just JavaScript, right? And this principle gives React several great properties. It is highly composable, easy to build on top of, and comes with great optional type checking, thanks to TypeScript, as we've heard before. And JavaScript is getting ever more popular on the backend, which is great, but when it comes to databases, the most popular options seem to be Postgres and MySQL. And SQL is the opposite of JavaScript. It is hard to compose, hard to build on top of, and has no static type checking itself. And this lack of composability leads to complex queries which the database tries to optimize, which then leads to unpredictable performance. And this is why the API from the convex database is just JavaScript. It is simple, highly composable, easy to build on top of, and fully typed, allowing end-to-end type safety all the way to the client. And convex combines the best of SQL and NoSQL databases being relational and yet not requiring you to define a schema upfront.

So taking these five React principles and applying them to the full stack radically simplifies the building of apps and enables a better UX. And of course, this backend needs to scale with your needs. So we are building such a backend at convex. It is fully open source, comes with a dashboard, and a bunch of features, text search, file storage, scheduling, more that I didn't get to talk about.

The second principle is consistency. I don't know about you, but inconsistent UIs frustrate me. Have you ever been on Slack or Instagram and there's a red badge and you click on that icon and you open a list and there's nothing there? Well, the reason that happens is because that red badge and the list in the tray are powered by different backend endpoints and they're fetched separately. So client-side React itself doesn't have this problem. If you have some state and then you're rendering a tree of React components, the view you get is always consistent. But once we add a database and we separate the data fetches, you might get an inconsistent view from your database.

So convex, on the other hand, is always consistent. In this example, when the data changes, the database figures out that those two reads need updating and pushes the update together to the client and then the client instructs again React to render a consistent result in a single pass.

It is simple, highly composable, easy to build on top of, and fully typed, allowing end-to-end type safety all the way to the client. And convex combines the best of SQL and NoSQL databases being relational and yet not requiring you to define a schema upfront.

So taking these five React principles and applying them to the full stack radically simplifies the building of apps and enables a better UX. And of course, this backend needs to scale with your needs. So we are building such a backend at convex. It is fully open source, comes with a dashboard, and a bunch of features, text search, file storage, scheduling, more that I didn't get to talk about.

So if you're interested, check it out, or come ask me a question later. Thank you so much. Thank you. Thank you. Thank you so much. Thank you so much. Thank you. Thank you so much. Thank you so much. Thank you so much. Thank you so much. Thank you so much. Thank you so much.

So convex's database tracks which writes impact which reads, and in convex, read end points are pure functions from database state to the result. Therefore, if no relevant writes happen, the read end point can be cached automatically and with perfect caching validation.

And the final principle I'll mention is that React is just JavaScript, right? And this principle gives React several great properties. It is highly composable, easy to build on top of, and comes with great optional type checking, thanks to TypeScript, as we've heard before.

And JavaScript is getting ever more popular on the backend, which is great, but when it comes to databases, the most popular options seem to be Postgres and MySQL. And SQL is the opposite of JavaScript. It is hard to compose, hard to build on top of, and has no static type checking itself. And this lack of composability leads to complex queries which the database tries to optimize, which then leads to unpredictable performance.

And this is why the API from the convex database is just JavaScript. It is simple, highly composable, easy to build on top of, and fully typed, allowing end-to-end type safety all the way to the client. And convex combines the best of SQL and NoSQL databases being relational and yet not requiring you to define a schema upfront.

So taking these five React principles and applying them to the full stack radically simplifies the building of apps and enables a better UX. And of course, this backend needs to scale with your needs. So we are building such a backend at convex. It is fully open source, comes with a dashboard, and a bunch of features, text search, file storage, scheduling, more that I didn't get to talk about. So if you're interested, check it out, or come ask me a question later.

Thank you so much. Thank you. Thank you. Thank you so much. Thank you so much. Thank you. Thank you so much. Thank you so much. Thank you so much. Thank you so much. Thank you so much.

So if you're interested, check it out, or come ask me a question later.

Thank you so much. Thank you. Thank you. Thank you so much. Thank you so much. Thank you. Thank you so much. Thank you so much. Thank you so much. Thank you so much. Thank you so much. Thank you so much.

Thank you so much. Thank you so much. Thank you so much. Thank you so much.

The third principle has to do with overlapping writes. The simplest example you can demonstrate this on is incrementing a counter. You need the current value and then you update the counter to the current value plus one. And in React, we can ensure that this always works correctly even if there are multiple places where the state can be updated, multiple state updates together by passing an updater function to the set function. React then runs all state updates serially so that two updates can't mess up each other's logic. But in a database, which can have many tables, each with many rows, you can't just serially run every mutation. So that's where transactions come in, and they do solve this problem.

The issue with current backends is that transactions are costly and therefore optional. It's super easy to write backend code like this, and for it to fail, not in tests, not during development, but only in production when you get sufficient write volume to get those concurrent writes to mess up each other's logic. React is designed so that transactions are cheap. This allows it to require that every end point that writes to the database runs as a transaction automatically, ensuring that no concurrent write can mess up its logic.

The fourth principle relates to caching. A React component is a pure function from props and state to the rendered UI. And this allows us to cache rendering of components easily with React memo. That leads to improved performance. Caching is even more important on the backend, where it's the server owner, sometimes us, paying the computation cost, not the user.

But caching today on the backend is hard because cache invalidation is not automatic. Take the to-do list example. We want to cache the list of to-dos but when a new item is added, a traditional backend doesn't know it needs to invalidate the cache. Again, we need to instruct it manually.

So convex's database tracks which writes impact which reads, and in convex, read end points are pure functions from database state to the result. Therefore, if no relevant writes happen, the read end point can be cached automatically and with perfect caching validation. And the final principle I'll mention is that React is just JavaScript, right? And this principle gives React several great properties. It is highly composable, easy to build on top of, and comes with great optional type checking, thanks to TypeScript, as we've heard before.

And JavaScript is getting ever more popular on the backend, which is great, but when it comes to databases, the most popular options seem to be Postgres and MySQL. And SQL is the opposite of JavaScript. It is hard to compose, hard to build on top of, and has no static type checking itself. And this lack of composability leads to complex queries which the database tries to optimize, which then leads to unpredictable performance. And this is why the API from the convex database is just JavaScript. It is simple, highly composable, easy to build on top of, and fully typed, allowing end-to-end type safety all the way to the client.

And convex combines the best of SQL and NoSQL databases being relational and yet not requiring you to define a schema upfront. So taking these five React principles and applying them to the full stack radically simplifies the building of apps and enables a better UX. And of course, this backend needs to scale with your needs. So we are building such a backend at convex. It is fully open source, comes with a dashboard, and a bunch of features, text search, file storage, scheduling, more that I didn't get to talk about. So if you're interested, check it out, or come ask me a question later. Thank you so much. Thank you. Thank you. Thank you so much. Thank you so much. Thank you. Thank you so much. Thank you so much. Thank you so much. Thank you so much. Thank you so much. Thank you so much.