spike: data-layer evolution

[boudra]

Overview

• how to handle new challenges with the data layer?
• we want to keep data fetching decoupled from ui
• we want to avoid issues related to repeated code
• we want to avoid issues related to shared queries being updated and breaking unrelated things

possibilities

• typed queries? codegen from graphql schema?
• composable queries

Details Say more

[boudra]

Overfetching:

Example here: https://github.com/gitcoinco/grants-stack/pull/2988#discussion_r1499222803

This is basically fetching data we don't need, I am not talking about loading small columns that we don't use, I think we need to find a balance between have a query for everything and reusability, but if the feature you're building only needs round data, please don't fetch projects or applications.

Also keep in mind that the data layer is shared, before adding fields to a query, check where it's used and create a new query if needed. Don't be afraid of repeating yourself or giving the query a super long name.

Type narrowing:

Example: https://github.com/gitcoinco/grants-stack/blob/main/packages/data-layer/src/data.types.ts#L252

Here instead of adding an optional field, we should make a new type called RoundWithProject (like RoundWithRoles), where project always is present.

With an optional field what will happen is that the responsibility to validate that project exists is pushed everywhere were this type is used, pushing complexity to the UI.

The data layer knows exactly what data it's returned so the type should match exactly the shape of the data.