blog post: Local-first with your existing API. #2006
Conversation
✅ Deploy Preview for electric-next ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| </p> | ||
| </div> | ||
|
|
||
| One of the exciting things about [local-first software](/use-cases/local-first-software) is the potential to eliminate APIs and microservices. Instead of coding across the network, you code against a local store, data syncs in the background and your stack is suddenly much simpler. |
There was a problem hiding this comment.
make this third person?
| One of the exciting things about [local-first software](/use-cases/local-first-software) is the potential to eliminate APIs and microservices. Instead of coding across the network, you code against a local store, data syncs in the background and your stack is suddenly much simpler. | |
| One reason many people are exciting about [local-first software](/use-cases/local-first-software) is the potential to eliminate APIs and microservices. Instead of coding across the network, you code against a local store, data syncs in the background and your stack is suddenly much simpler. |
|
|
||
| This is why we work with [any data model](/docs/guides/deployment#data-model-compatibility) in [any standard Postgres](/docs/guides/deployment#_1-running-postgres), allow you to sync data into anything from a [JavaScript object](/docs/api/clients/typescript#shape) to a [local database](/product/pglite) and focus on providing [composable primitives](/blog/2024/07/17/electric-next) that work with your existing stack. | ||
|
|
||
| As a result, with Electric, you can develop local-first apps incrementally, using your existing API. So you get the benefits of super snappy apps that feel instant to use, collaborative, multi-user sync, local, offline data access for reads and writes and locally encrypted data for security and privacy. |
There was a problem hiding this comment.
adding some concrete examples of people adopting electric incrementally would help e.g.:
- trigger.dev adding real-time SDK
- ottogrid swapping out loading sheet data to use electric
- team that shipped live notifications
anywhere that you need real-time or want to load mbs of data — syncing makes a big diff & you can cherry-pick specific types of data or screens to convert first.
There was a problem hiding this comment.
great post! Very helpful framing for both local-first folks & people in the broader engineering world more interested in specific benefits e.g. just a better real-time stack or the idea of loading more data into the client appeals to them but can't or don't want to go all in on a more vertically integrated tool.
|
@KyleAMathews ta, will incorporate when looping back to this 🙏 |
|
Next.js ran/runs a very effective incremental adoption strategy. Their og blog post is pretty good here |
Sketched out the intro here: https://deploy-preview-2006--electric-next.netlify.app/blog/2024/11/21/local-first-with-your-existing-api
Pausing drafting further pending more example content and write patterns.