Local-first Apps with ElectricSQL and React

Rate this content
Bookmark
Slides

Local-first is a new paradigm for developing apps with instant reactivity, realtime multi-user and conflict-free offline built in. This talk shows how to develop local-first systems with React using ElectricSQL, a open source software platform from the inventors of CRDTs.

James Arthur
James Arthur
12 min
12 Dec, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Electric SQL is a local-first sync layer that allows you to build applications directly on top of Postgres using React. It provides instant results, offline functionality, and built-in multi-user collaboration. The system ensures transactional causal plus consistency and supports real-time multi-user sync and cross-platform usage. Electric SQL eliminates boilerplate code, provides a high-quality user experience, and allows for cost savings and operational simplicity.

Available in Español

1. Introduction to Electric SQL

Short description:

Hi, I'm James Arthur, co-founder and CEO of Electric SQL. We are a Sinclair for building modern apps. Our local-first Sinclair allows you to build applications directly on top of Postgres using React. We have a team of distributed systems geeks who have been researching and strengthening programming on the AP side of the cap theorem. This has led to a shift in application architecture, with local-first systems becoming more popular. These systems allow direct communication with a local database and provide instant results, offline functionality, and built-in multi-user collaboration. Let's now move on to a demo to see this in action.

So, hi, I'm James Arthur. I'm one of the co-founders and I'm CEO at Electric SQL. So this is basically Electric. We are a Sinclair for building modern apps. So, specifically, it's a local first Sinclair, which I'll talk about, and it allows you to build applications like Figma, Linear, directly on top of Postgres, using React.

Just to give you a bit of context on who we are, we're basically a bunch of distributed systems geeks. And so, the company comes out of a bunch of research into the AP side of the cap theorem, and we have a number of the people who've pioneered a bunch of stuff in that area on the team, including two of the inventors of CRDTs, etc. And basically, these academics, over the last probably couple of decades or more, have been working to basically strengthen what you can do with programming on the AP side of the cap theorem. And I won't go into the details here, but you can kind of look into a bunch of the kind of research.

And what that's now being used for is to change the way that you build applications today, and particularly, it's about targeting the state transfer piece of application architecture. So traditional cloud-first systems, you run on the server, they talk to web services over the network. Whereas what you have now is you have local-first systems, where you talk directly to a local database that's embedded inside the application, and then data syncs in the background. And this kind of architecture is now being used by a whole range of successful applications. So I mentioned things like Figma, Linear, you have the new Facebook Messenger, new Google Workspace applications, you have SuperHuman, for example.

And just to give you a very quick sort of sense of actually what's happening there, with a traditional cloud-first system, you have the network on the interaction path. So the user clicks a button, it sends a request to the server, the server sends something back to the user, and then you see the results. And so you have latency from going over the network, the server needs to be online, you get network errors that you have to code for every time you go over the network, and the user's out there watching a loading spinner or waiting for the page to load. Whereas, with local-first, you basically move the database, or a subset of the database, into the client, the user clicks the button, everything is instant, so there's no latency because you don't have the network on the interaction path, the user sees the result immediately, applications default to working offline, if the server goes offline, the application still works. Then you introduce this kind of live sync layer between the database and the client and on the server. And together, what this gives you is this model where you get a kind of holy trinity of modern consumer or prosumer great user experience, which combines instant reactivity so that apps just feel instant to use with built-in multi-user collaboration and also applications that can work offline and handle conflicts for you.

I'm just going to jump out at this point and let's hop over to a kind of demo just to sort of see that in action. I'll just change windows. So this is coming over to electric. Like first, I'm just going to jump in to give you a sense of sort of some of the code if that's useful as an orientation. So for example, like how do you get this thing set up? Right. So so we have an architecture where you have a Postgres database in the background. You run an electric sync service. So this as it happens is an elixir sync service. It's stateless. It runs in front of PostgreSQL and it handles that replication for you.

2. Data Access and Syncing

Short description:

We generate a type safe data access library from the Postgres data schema. Define your schema as normal and use rules to control data exposure and permissions. Authenticate the local app using a JWT and wrap the SQL light driver with electrify to get a reactive live version of the database connection. The API uses shapes to control data syncing on the local device. Define shapes for dynamic partial replication and bind live queries for real-time updates. Write data directly to the local database and keep everything live and reactive.

What we then do is we generate out a type safe data access library from the Postgres data schema from the DDL schema. And so the way it works is you just define your schema as normal using whichever tooling you would use to work with Postgres. So something like for example, you then, we, we then provide a set of rules to be able to control what data is exposed to the system. And also who can, who has what permissions on what data. It's a bit like row level security, but it's a bit different because it's designed to be portable so that you can run the rules in the sync service and in the client that allows you to achieve something called finality of local rights. So you don't have to code for rollbacks and error every time you do it.

Right. You then authenticate the local app using a JWT, and then inside the client, you basically take the standard SQL light driver for your environment. So whether that's a web browser using a Wasm build of SQL lights, or if you're making a mobile app, it's like a react native driver or an expo or a capacitor driver. And then you wrap that with this call to electrify it. And that gives you a kind of reactive live version of the database connection that's also aware of your schema, and sort of knows where to connect to replication.

We then provide an API using a primitive called shapes, which allows you to control what data syncs on and off the local device. So if you imagine like you start with, say, a large postgres database, and you want to sync just a subset of the data onto the local device. You define a shape which could be like project 1234. So for instance, here, like, we can say a project and include all of the issues and comments and the comment authors kind of underneath that. So it's a bit like doing a kind of ORM query with an association graph. And then you can define multiple shapes as you sort of go along. And you can update them at runtime. And they will get aggregated into a kind of combined shape subscription for a particular client application. So that's an API that controls basically dynamic partial replication, what data syncs onto the local device.

And then once you have the local, once you have the data in the database for the local device, you bind live queries. So in this case, this is an example of like results as a react state variable, and use a use live query hook. And then you have a prisma inspired query builder for defining queries for how you want to access the data in the database. Or you can drop down to raw SQL. And then at any time, you can just write data directly to the local database. And basically everything stays live and reactive. So because you have this model of bi-directional active, active replication, kind of underneath the components controlling what data syncs on and off the device, instead of just doing sort of static queries or static fetches against the kind of backend service, what you do is you keep everything live so that if another user also changes the data somewhere else, your components also just naturally update. So here's an example of a simple React component. You get a handle on the electrified database. You set up a live query for all of the items.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Everything Beyond State Management in Stores with Pinia
Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Query: It’s Time to Break up with your "Global State”!
React Summit Remote Edition 2020React Summit Remote Edition 2020
30 min
React Query: It’s Time to Break up with your "Global State”!
Top Content
An increasing amount of data in our React applications is coming from remote and asynchronous sources and, even worse, continues to masquerade as "global state". In this talk, you'll get the lowdown on why most of your "global state" isn't really state at all and how React Query can help you fetch, cache and manage your asynchronous data with a fraction of the effort and code that you're used to.
Jotai Atoms Are Just Functions
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
Announcing Starbeam: Universal Reactivity
JSNation 2022JSNation 2022
27 min
Announcing Starbeam: Universal Reactivity
Starbeam is a library for building reactive data systems that integrate natively with UI frameworks such as React, Vue, Svelte or Ember. In this talk, Yehuda will announce Starbeam. He will cover the motivation for the library, and then get into the details of how Starbeam reactivity works, and most importantly, how you can use it to build reactive libraries today that will work natively in any UI framework. If you're really adventurous, he will also talk about how you could use Starbeam in an existing app using your framework of choice and talk about the benefits of using Starbeam as the state management system in your application.
Thinking in React Query
React Summit 2023React Summit 2023
22 min
Thinking in React Query
Top Content
In this talk, I'll explain React Query from a different perspective. After having maintained React Query for over two years and having answered many questions (often the same ones multiple times), I feel like there might be a fundamental understanding missing about the lib. I'll start with a quick introduction about my journey into open source and how I got to know React Query, followed by showing which mindset change is beneficial when working with React Query - how to "think in React Query". I'll have 3 major takeaways: 1) React Query is not a data fetching library It's an async state manager, we'll quickly talk about what makes a state manager, why React Query is one and what "async state" means. 2) staleTime is your best friend I've seen a bit of confusion about how to use React Query as a state manager, so I'll explain why setting staleTime is mostly all you need 3) parameters are dependencies This is important to understand to show the boundaries between client state and server state, and is essential when doing state management with React Query I will then end with a note on "separation of concerns" and about the tradeoffs of just calling `useQuery` wherever you need it in your component tree.

Workshops on related topic

Rethinking Server State with React Query
React Summit 2020React Summit 2020
96 min
Rethinking Server State with React Query
Top Content
Featured Workshop
Tanner Linsley
Tanner Linsley
The distinction between server state and client state in our applications might be a new concept for some, but it is very important to understand when delivering a top-notch user experience. Server state comes with unique problems that often sneak into our applications surprise like:
- Sharing Data across apps- Caching & Persistence- Deduping Requests- Background Updates- Managing “Stale” Data- Pagination & Incremental fetching- Memory & Garbage Collection- Optimistic Updates
Traditional “Global State” managers pretend these challenges don’t exist and this ultimately results in developers building their own on-the-fly attempts to mitigate them.
In this workshop, we will build an application that exposes these issues, allows us to understand them better, and finally turn them from challenges into features using a library designed for managing server-state called React Query.
By the end of the workshop, you will have a better understanding of server state, client state, syncing asynchronous data (mouthful, I know), and React Query.
State Management in React with Context and Hooks
React Summit Remote Edition 2021React Summit Remote Edition 2021
71 min
State Management in React with Context and Hooks
WorkshopFree
Roy Derks
Roy Derks
A lot has changed in the world of state management in React the last few years. Where Redux used to be the main library for this, the introduction of the React Context and Hook APIs has shaken things up. No longer do you need external libraries to handle both component and global state in your applications. In this workshop you'll learn the different approaches to state management in the post-Redux era of React, all based on Hooks! And as a bonus, we'll explore two upcoming state management libraries in the React ecosystem.