The Tangle of APIs: Are We Over-Complicating Interactions?
Every action on a web application triggers a cascade of network calls. Take the simple act of engaging with a post on a social media platform like Instagram. Opening a post fires off a GET API call, hitting 'like' triggers a POST API call, and commenting sparks another POST API call. Each interaction, each click, and each submission reels out a string of API calls from the frontend to the backend, fetching or updating data in the database.
This traditional setup, while functional, piles up layers of interaction between the user interface and the backend. Every added layer is a potential point of failure, a delay, or a bottleneck. For Developers and Engineers, managing this entanglement of APIs can be a daily grind. Each API call is crafted, tested, and maintained. The overhead is real, both in time and resources.
Moreover, the users on the other end, often find themselves waiting, even if it’s just for a split second, for these network calls to complete. In an era where speed and real-time interactions define user experience, these micro-delays can add up, affecting user engagement and satisfaction.
Now, imagine a setup that trims down these numerous API calls, a setup that allows direct interaction with the database, cutting through the delay and the clutter. This is where ElectricSQL (ESQL) steps into the picture…
ElectricSQL: Cutting Through the API Clutter
ESQL proposes a cleaner, streamlined approach. It operates alongside your Postgres DB, reducing the need for these multiple API calls. With ESQL, actions like commenting or upvoting are handled in dedicated tables within the browser’s local storage(SQLite), which then syncs with Postgres. This setup eliminates the need for a backend API call to store data to the Postgres, thereby reducing the layers of communication and the associated delay. The front end and the database can now interact more directly and efficiently. This simplifies the workflow for developers and speeds up user interactions on the front end. Now let's see how this is achieved and what goes on internally.
Interaction Between Browser and Postgres DB using Electric
The diagram demonstrates the communication pathway between the browser and the Postgres database through the Electric service. Essentially, Electric Sync Service, an Elixir application, orchestrates active-active data replication between the user's local DB and Postgres.
The browser interacts with the local DB through the electric-sql library. The local DB is connected to the Electric service, there is a satellite present in the electric-sql which is used to communicate with the electric service, and used for data replication between the local DB and Postgres.
Whenever data alterations occur in either the local DB or Postgres, the Electric service acts as a conflict resolver, ensuring seamless data replication. This configuration eliminates the need for API calls to store new data entries like comments or updates, thereby streamlining the data interaction process.
Continue reading the full article https://journal.hexmos.com/reduce-apis-using-electric/
Top comments (15)
What about data abstraction and aggregation, business logic validations, reporting, monitoring, logging, integration with other services and so on.
Will all this be on the client side as well.
This seems applicable only for very simple/prototype applications, I am not sure this can scale well ...
The title says goodbye CRUD APIs, not goodbye to "data abstraction and aggregation, business logic validations, reporting, monitoring, logging, integration with other services and so on"
The purpose here is not scaling up, but scaling down: utilizing simpler approaches for simpler problems.
Which seemed to be a forgotten art for a long time, and now finally back.
I think we are on same page that this works only for very simple solutions.
I am not against using simple solutions to simple problems, but I would prefer a solution that also gives flexibility to extend the application.
Otherwise the oversimplified solution will just be road block.
The new becomes old, the old becomes new again.
Direct SQL access, then rpc, then rest, then back to direct SQL access via this electricSQL. Have we learnt nothing?
Also, sounds like Meteor - what's different about this?
Apples and oranges - Meteor doesn't proactively/optimistically fetch and locally cache data changes - I think that's what sets this solution apart ... I just wonder how feasible this is and how well it works in reality.
Right
The history repeats itself 😊
:D
Interesting idea, in theory I can see this work - its practical viability depends on how well this has been implemented (i.e. all of its corner cases).
Found this interesting enough to bookmark it.
P.S. people who compare this with Meteor and say "what's new" have not read the article, or have missed the point: it proactively fetches and locally caches data changes to eliminate roundtrip "lag" ... just wondering how well this works in reality.
After HTMX, here ElectricSQL comes. There are always incredibly innovative engineers who are more than ready to put this industry into a loop.
Do we have anything like this for MongoDB
You probably want to look for MongoDB Change Stream
Maybe Realm + Atlas
mongodb.com/docs/realm/
If you're a Flutter user you might be better off opting for Powersync.
The security implications of this are hard to fathom. So i can just run some ecma in my console and create 1M comments on a site?