Ideas

~~Problem: Heavy Queries, mostly on Feed: Do we remodel or do we fix queries? More work at index time and less at query time.~~

~~We need to optimize the queries~~

~~related to moves, rename paths,~~

~~mentions and comments.~~

~~Some events cause the frontend to perform lookups.~~

~~We would skip this.~~

~~We need to model events from the business logic:~~

~~deletes, updates, moves, and renames.~~

~~How will this alleviate this:~~

~~We stored these events as the app needs them. So we don't need to do huge queries.~~

~~Search API was broken~~

Connect to a Peer is extremely slow and high volumes.

Improve Object Modeling.

Cancel requests when the user moves away.

Deactivate observability with a flag until we make it work.

~~Pagination Documents and Query Blocks.~~

~~Optmized the middelend or the daemon paginates the document.~~

~~renderer can't keep up with the requests. they are tiny but a lot. they can only make 5 at a time.~~

~~it shold be done in the frontend or~~

~~Backend doesnt know the document graph. Viewport knows the resources.~~

~~Make the Sync Engine processes based with an WriterObject:~~ How Erlang Beam fixes this

Objects receive events: How Reactive we can be?

Optimized Syncing: Discover and Compute Haves

Reconcilization Process. The server does it per round-trip and per peer.

Queries are expensive: we not only do document changes, but also profiles and capabilities.

Domain Store

Table of domains, frontend asks domains

The information is cache. It has the metadata

Background we hit the domains to make updated.

The idea is that the user can go offline and continue working with domains.

there is an api

Why do we need to keep

check the update loop.

If the user

we want to resolve domains, and this should be cache. and for subscription.