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: 

Optimize Frontend calls: 

Objects receive events: 

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

  1. check the update loop.

  2. If the user

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