Update Summary Document

[ms007]

Hi

Based on the question: https://forums.fauna.com/t/get-count-of-related-documents/3683 I have created a Next React Server component that gets the Lists and a count of the associated Todo’s.

import { Client, fql } from "fauna";

const client = new Client({
  secret: process.env.FAUNA_KEY,
});

const getAllLists = fql`List.all().map(list => list {
  id,
  ts,
  name,
  todoCount: Todo.byList(list).count()
})`;

export default async function Home() {
  const response = await client.query(getAllLists);
  const { data } = response.data;

  return (
    <main>
      {data.map(({ id, name, todoCount }) => (
        <div key={id}>
          {name} {todoCount}
        </div>
      ))}
    </main>
  );
}

I understand that this solution works great for a ToDo App. But when I theoretically have thousends of Todo’s in a List then it is probably a performance issue and then it would be better to have like a Summy Document for each list, where the count of the ToDo’s are aggregated.

But then I need to update the Summary document when a ToDo gets created or deleted or moved to another list.

Is there a way in fauna that theese operation could be done server side and not in the client logic?

Like a detection of these events?

Thanks for the help. I am still new to fauna.
V10 seams to be very powerful.

[ptpaterson]

One way to scale queries like this is captures events in a kind of log Collection. Then you can run a background process at some interval (every 5 seconds, 1 minute, 10 minutes, etc.) to aggregate the logs and make a single update call. You can keep track of when the last update was an then only fetch the events that have happened since.

Alternatively, rather than a background server job, you can incorporate the aggregation logic into your read queries. How efficient that would be would depend on how often reads happen and how frequent change events are.

This pattern is sometimes called “event sourcing”. We have a page in our docs that goes further into it. The page is written for FQL v4, but the same methodology applies.

UPDATE: (how about I share that link to the docs)

Write throughput scaling