Video Summary and Transcription
React principles can break down for full-stack apps, but Convex has built a backend and database to address this. The five React principles discussed include reactivity, consistency, overlapping writes, and caching. Convex's database ensures consistency, handles overlapping writes with transactions, and automatically invalidates caches based on relevant writes. Convex combines the best of SQL and NoSQL databases and applies React principles to simplify app development and improve the user experience.
1. Introduction to Convex and React Principles
React has revolutionized the way we build interactive front ends for our apps. Convex has built a back end and a database that carries React principles to the full-stack developer and user experience. The first principle is reactivity, allowing you to build endpoints as reactive as your state. The second principle is consistency, ensuring a consistent view even with separate data fetches. The third principle deals with overlapping writes, guaranteeing correct updates even with multiple state updates.
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.
1. Introduction to React Principles and Convex
Hi, everyone. I'm Michael, a software engineer at Convex. React revolutionized front-end development, but its principles break down for full-stack apps with multiple user interactions. At Convex, we built a back end and database to address this. Today, I'll discuss five React principles, each solving common problems. The first is reactivity. By utilizing Convex, you can build reactive endpoints that automatically update the state and trigger React to re-render.
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.
1. Introduction to Convex and React Principles
React has revolutionized the way we build interactive front ends. Convex solves the problem of building full-stack apps for multiple users. React principles break down when it comes to building full-stack apps. Convex introduces five React principles. The first principle is reactivity, which allows for automatic updates. The second principle is consistency, ensuring consistent UI. The third principle deals with overlapping writes and ensures correct state updates in React.
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.
1. Introduction to React Principles
React has revolutionized the way we build interactive front ends. However, when it comes to building full-stack apps for multiple users, React principles break down. Convex solves this problem by building a reactive back end and database. The first principle is reactivity, where Convex allows building reactive endpoints that update the client automatically.
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.
2. Transaction, Caching, and Database API
Transactions in React are cheap and ensure that no concurrent write can mess up its logic. Caching on the backend is difficult due to automatic cache invalidation. React's principle of being just JavaScript provides simplicity, composability, and type safety. The convex database API is simple, composable, and fully typed. Applying these principles to the full stack simplifies app development and enables a better user experience. The convex backend is fully open source and comes with a dashboard and various features.
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.
2. Consistency, Overlapping Writes, and Caching
The second principle is consistency. In a client-side React, the view is always consistent. However, adding a database can introduce inconsistencies. Convex, on the other hand, ensures consistency by updating the client with data changes in a single pass. The third principle involves overlapping writes, which can be solved with transactions. Current backends often lack transactionality, leading to logic failures. The fourth principle focuses on caching, where Convex's database automatically invalidates caches based on relevant writes, ensuring perfect caching validation.
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.
2. Convex Principles: Transactions, Caching, and API
Transactions solve the problem of running mutations in a database. React ensures cheap transactions and caching. React is highly composable and easy to build on top of. Convex's database tracks writes and impacts reads, allowing for automatic caching. The convex database API is simple, composable, and fully typed. Convex combines the best of SQL and NoSQL databases. Convex is building an open-source backend with scalability and various features.
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.
2. Consistency and Convex
Inconsistent UIs can be frustrating, especially when different parts of the UI are powered by separate backend endpoints. Convex ensures consistency by pushing updates together to the client, resulting in a consistent view.
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.
3. Convex Backend and Features
The convex backend combines SQL and NoSQL databases without requiring upfront schema definition. Applying React principles to the full stack simplifies app development and enables a better UX. The convex backend is fully open source and comes with a dashboard and various features.
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.
3. Backend, React Principles, and Convex
Convex's database tracks writes and reads, allowing for automatic caching and perfect validation. React's great properties include being highly composable, easy to build on top of, and having optional type checking with TypeScript. SQL's lack of composability leads to complex queries and unpredictable performance. Convex's database API is simple, composable, and fully typed, combining the best of SQL and NoSQL databases. Applying React principles to the full stack simplifies app development and enables a better UX. Convex is building a scalable backend, fully open source with features like text search, file storage, and scheduling.
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.
3. Convex: Next Steps and Gratitude
If you're interested, check it out or come ask me a question later. 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.
3. Overlapping Writes and Transactions
React ensures correct handling of overlapping writes by running all state updates serially. In databases, transactions are needed to handle concurrent mutations. However, current backends make transactions costly and optional, leading to potential failures. React, on the other hand, makes transactions cheap and requires endpoints that write to the database to run as transactions, ensuring logical consistency.
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.
4. Caching, JavaScript, and the Convex Backend
Caching in React leads to improved performance. Backend caching is challenging due to manual cache invalidation. Convex's database tracks writes and reads, enabling automatic and validated caching. React's use of JavaScript provides composability and type safety. SQL databases lack composability and type checking, unlike JavaScript. The convex database API allows simplicity, composability, and end-to-end type safety. It combines the best of SQL and NoSQL databases, simplifying app development. The convex backend is open source, scalable, and offers various features.
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.
Comments