From 58f54d6327399909b8a7ab21038498807477b06a Mon Sep 17 00:00:00 2001 From: Oleksii Sholik Date: Wed, 20 Sep 2023 17:08:53 +0300 Subject: [PATCH] chore(docs): No motion graphics explainer for now (#462) --- docs/intro/real-world.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/intro/real-world.md b/docs/intro/real-world.md index ba7c500c42..f7725117ae 100644 --- a/docs/intro/real-world.md +++ b/docs/intro/real-world.md @@ -14,8 +14,6 @@ Bringing it all together and coming back to a high level, what kind of apps does ElectricSQL is designed to support relational applications which match a particular pattern. This pattern has a central, Postgres-based, backend application as a control plane or management system. You can then then expose multiple local-first apps and interfaces on top of this, much as you would with traditional API-based architectures. -> XXX todo: motion graphic explainer here. - In this architecture, ElectricSQL replaces traditional APIs and state transfer protocols, like REST and GraphQL. You still define your data model [using your existing web framework](../usage/data-modelling/migrations.md), like Prisma, Phoenix or Rails -- any framework that handles migrations and works with Postgres. You replace your server-side business logic with a local-first client app and background processing triggered by database events. And you codify your imperative authorization and validation logic into declarative security and sync rules.