Forem: Lucas Correia

Contract Tests with TypeScript and OpenAPI Codegen

Lucas Correia — Sat, 08 Feb 2025 17:22:40 +0000

Introduction

At Chili Piper, one of our ongoing challenges is ensuring our frontend applications stay in sync with backend changes.

For context: We utilize auto-generated clients via OpenAPI Codegen to maintain a strongly typed contract between frontend and backend.

A recurring issue we've faced is the backend team deprecating an endpoint or field and removing it after a few weeks. Issue is that often, the frontend team doesn't stop using the deprecated field in time, leading to runtime failures upon deployment.

This post outlines our approach to addressing this problem using contract tests with TypeScript and OpenAPI Codegen.

Minimal Setup for Contract Tests

To set up contract tests effectively, it's essential to have a mechanism to store the currently deployed versions for each service or application.

In our case, we use a YAML file in one of our repositories. Deployments are triggered when a version is changed through a PR, thanks to our diligent SRE team.

Steps to Implement Contract Tests

Determine the deployed versions: Detect the versions of backend services currently deployed in the target environment.
Generate API clients dynamically: Use OpenAPI Codegen to generate clients based on the detected backend versions.
Checkout frontend versions: For each frontend application, checkout the tag corresponding to the deployed version.
Override API clients: Replace the API clients in the frontend apps with the environment-based generated code.
Run TypeScript checks: Use TypeScript to validate that no API contracts have been broken.

This process ensures that any breaking change in the backend will immediately fail the TypeScript checks, providing early feedback before deployment.

Performance Considerations

One downside of this approach is its computational expense.

With around 15+ micro-frontend (MFE) applications, running this check across all of them takes about 10 minutes, even when parallelized across three runners.

To improve performance, we implemented several optimizations:

Skipping checks if there is no breaking change: We use openapi-diff to detect whether the deployment contains a breaking change. If none is found, we skip the contract tests, reducing runtime to just 2 minutes.
Caching dependencies: By caching dependencies, we reduce redundant installations and builds.
Grouping tests: If multiple applications share the same monorepo tag, we run their checks together to avoid redundant executions.
Using TypeScript project references with incremental mode: This allows us to reuse previously built code, improving build times.
Skipping Frontend checks: Unlike backend deployments, we can't quickly determine if there is a breaking change in frontend applications (e.g. openapi-diff). However, we can detect version bumps and skip runs for unaltered apps.

One of the most interesting improvements was leveraging TypeScript project references with incremental mode.

This allows us to reuse compiled output from previous runs, significantly reducing build times.

But the best improvements were the ones were we would skip checks.

Why Contract Tests Instead of Just Relying on `openapi-diff`?

While openapi-diff helps detect breaking changes, it doesn’t tell us which frontend applications are affected.

Contract tests allow us to:

Identify which apps are still using deprecated endpoints.
Detect which apps need to be deployed together. For example, if a breaking change affects app A but not app B, we only need to deploy app A.

We considered using Pact.io, but it requires maintaining separate contract files, which can be forgotten or become outdated.

With TypeScript, the contract is directly enforced by the code, eliminating the risk of stale contracts.

Handling False Positives in TypeScript Project References

While TypeScript project references help improve performance, they introduce a key issue:

TypeScript builds and reports errors for all files in a project, even unused ones.
Example: If app A depends on a shared package B, and package B has an error in an unused file, app A will still fail the build, leading to false positives.

This is especially problematic because our automation blocks deployments, and false positives would require us to deploy more apps than actually needed.

Our Solution

To mitigate this, we created a small wrapper around the TypeScript build tool that suppresses errors from unused files, ensuring that only relevant issues cause test failures.

You can check out our Gist with the implementation here.

We initially considered going even further by leveraging AST (Abstract Syntax Tree) analysis to only report type errors for actually imported code. The current file-based filtering approach means that if function A has a type error but your app only uses function B, it will still report an error. With AST-based filtering, we could theoretically ignore errors from unimported code, reducing noise in the checks.

However, after discussing this with a friend who has more experience with ASTs, he pointed out that this would essentially mean rewriting tree shaking, which is far from trivial. Given the complexity involved, we opted to stick with file-based filtering for now. That said, we’re actively keeping an eye out for existing public implementations of tree shaking that we could potentially leverage, such as those used in Webpack or other bundlers.

Conclusion

By combining OpenAPI Codegen, TypeScript, and contract tests, we have built a robust solution to detect breaking API changes before they impact production.

Key takeaways:

While the solution is in fact resource-intensive, there are available workarounds to mitigate this issue.
This strategy for making contract tests is not the simplest to setup, but it is maintenance-free. You setup once and forget about it.
Whatever solution you pick, make sure it is something that will help developers more than block them. In my experience, false positives and long CI times are the main issues, so make sure to address those.

If you're facing similar issues with breaking API changes, I highly recommend setting up a contract testing strategy tailored to your stack!

Client-first RSC: A scalable solution for data aggregation

Lucas Correia — Sun, 19 May 2024 21:06:07 +0000

RSC vs SSR

First of all, we need to be in the same page on the fact that RSC and SSR are not the same thing.

RSC is a strategy to run part of your react application on the server-side. Server components are isolated in the cloud and will never be sent to the client. Same is valid for server actions.

SSR is a strategy for rendering your client components in the server. It generates HTML. Those components are sent and will run in the browser.

Do you need SSR?

SSR is really good if you have performance-critical applications. When you have pages that need to load on really poor connections. On really bad devices. If you do have this scenario, then you can drop this article and assume SSR is for you. Otherwise, keep reading.

SSR scalability

When trying to pitch next, one of the things that puts me in a corner is dealing with scalability. You're rendering your app on the server. You need computing power for that. You need to think about scalability, something you wouldnt need to worry if you were serving static assets instead.

A co-worker gave me a scenario of thousands of parallel requests happening to our FE and asked how to solve this. At the time the only thing I could think of was horizontal scaling, but I believe this is not the answer he was expecting.

Then why RSC?

Now that I've explained myself on why I dont wanna use SSR, let me explain how Im planning to use RSC without facing similar issues: By avoid using server components.

TBH, the only part that really interests me in the whole RSC hype is server actions. If you have a server component, when the user requests a page, you will be running some code in your cloud. This is what we are trying to avoid.

Why server actions?

The bauty of server actions is how simple it is for you to make a client-side function become a server-side function. All you gotta do is add a "use server" directive. A one-liner.

My idea is to move the data aggregation layer into a function. The default behavior of the application Im trying to build is to delegate everything to the user machine, so we run that function in the client.

If a specific page needs more performance (N+1, etc), we can just decide to run that function in the server. All it takes is a one-liner.

How does it solve scalability?

Considering that SSR is disabled, your server only needs to run server actions. But whats the difference when comparing against running SSR?

The idea is that you wont start with server actions. Your functions will start in the browser, making requests to the microservices directly. Initially, your server will be in charge of serving static assets and thats all.

As needed (and only if needed), you can make a specific page use a server action instead of a client function, or even enable SSR only for that page.

Optimizing only what is absolutely needed helps alleviate server load and save on cloud costs.

Why not GraphQL?

GraphQL is a really good BFF strategy that brings a lot to the table. I've consired using it myself a lot of times, but always decided to try some other approach because of its query language.

What puts me off is that it requires me to follow a set of rules and structure my data in a way that complies with them.

Im not 100% free on the way I consume the API cause I need to query things following another set of rules.

If you start using it early, you will be able to allow the tool to dictate how your data will look like. If youre trying to adopt in an pre-existent project, its no easy thing.

Solving the data aggregation problem

I have a situation at work where our BE uses microservices. They dont provide a BFF, so FE needs to load entities from multiple services. You can get a glimpse of how things currently work in this other article I wrote.

The great thing about GraphQL is that if you configure things correctly, you dont need to write code to aggregate entities. Apart from performance and scalability, I want to be able to have this level of simplicity when making my requests.

Maybe JSON:API?

I know... Its 2024 and Im talking about JSON:API...

What I want do accomplish here is to have a standard which allows me to know what relationships are available for a given entity.

Not only that, but a standard means that I can expect data to be structured in a specific way. And with that, I can create generic solutions to accomplish the level of simplicity I want to have when aggregating data.

Maybe not JSON:API, but I do need a standard.

Generic solutions and caching

Im talking about aggregating data from multiple services. Multiple entities. But what about caching?

If my client has a aggregated table with information from entity X and Y. If for some reason, entity Y updates in the same context of that table (e.g. in a modal). Do I want to refetch all the aggregated entities by calling that server function?

The answer is no. The solution Im seeking has two steps: Fetching and querying. With that, When entity Y updates, I dont need to refetch the whole table. I can just re-query from a local storage. This can be done on client-side, which improves scalability even more.

Reinventing the wheel?

While Im writing this, I can't stop thinking that Im trying to implement exactly what GraphQL is. I can even bet that there is some JSON:API client doing exactly what Im talking about:

But, my goal is to have a solution that fits my needs at work. I have my reasons why I dont want to use GraphQL. My BE team may have their reasons on why they dont want to follow JSON:API strictly. My SRE team has their reasons on why they dont want to use SSR.

In the end, the solution Im proposing here is made to solve the problems Im facing. Its a glove. There is no silver bullet.

To be continued

I will be writing a separate post specifically on data management tools. Probably exploring a few of the JSON:API client libraries I shared. I wont go into details here for a few reasons:

Im not there yet. Im still trying to find the best tool for my use-case.
I want to share a solid solution/strategy and not only opinions based in a few hours of research.
This post is already too big.

Conclusion

Maybe with all the good things that RSC brings to the table its time to start looking back to check how it improves pre-existent tools.

It opens a door for client-first solutions where you can gradually move things to the server as-needed. With the correct set of tools, you can accomplish similar performance as BFF in critical scenarios while having scalability and simplicity of static apps by default.

We must go for simplicity first. We must optimize only when necessary. Optimization path should follow the first rule.

Integrating Dataloader with Concurrent React

Lucas Correia — Tue, 22 Aug 2023 15:41:52 +0000

You dont need to, but this is a follow up on my previous post on data aggregation. The findings here happened while trying to implement a code sample for a presentation based on the post.

Also, if you want a detailed deep dive on how the whole situation described here works under the hood, you may want to check this article.

TLDR: Add batchScheduleFn: (callback) => setTimeout(callback, 5) to the dataloader config. batchScheduleFn: (callback) => unstable_scheduleCallback(unstable_IdlePriority, callback) if you dont mind about the unstable API.

Facing the issue

First, lets take a quick look at the code in the following codesandbox.

We have a list of Cards, each Card receives an episode and requests a list of characters that are related to the episode. Those requests are grouped into a single request thanks to dataloader. If you check your network tab, you should be able to see the only 2 requests happening: One for the list of episodes, and the other for all the characters existent in the episodes.

Lets say I'd like to use Suspense. Refactor it a little bit and we will end up with the following codesandbox:

Now, if you have a look at your network tab, you will notice that dataloader is no longer working as expected. You will see 3 different requests for characters.

Finding the root cause

First, lets add a few logs to know when each Card is Suspending the request and when they are resolving it:

// src/Card.tsx
export function Card({ episode }: { episode: Episode }) {
  console.log("before request", new Date().toISOString());

  const { data: characters } = useCharactersByIds(
    episode.characters.map(getCharacterIdFromUrl)
  );

  console.log('after request')

And then, check the logs...

So, we know that all cards are rendered between .650 and .665 milliseconds. Thats around 15ms to render all cards. If you rerun enough times, you may have different results like something between 10 and 15. If you go back to previous codesandbox (before Suspense), you will also have similar results. So whats happening here? Why adding Suspense breaks it?

Dataloader docs states:

DataLoader will coalesce all individual loads which occur within a single frame of execution (a single tick of the event loop)

And they also provide a function in case you want to change that behavior. So lets use it with its default configuration and add some logs to see whats happening:

// src/api/queries.ts
export const characterDataLoader = new DataLoader<string, Character>(
  async (ids) => {
    const characters = await getCharactersByIds(uniq(ids));
    const charactersMap = keyBy(characters, "id");
    return ids.map((id) => charactersMap[id]);
  },
  {
    batchScheduleFn: (callback) => {
      return setTimeout(() => {
        console.log('calling callback')
        return callback()
      })
    },
    cache: false,
  }
);

And then check your logs:

Ok, it seems like we found something here: That callback is not supposed to be called multiple times like its happening. If you apply the same changes in the previous codesandbox (before Suspense), the callback will only be called once and after all cards render.

So lets start changing the behavior of dataloader's batchScheduleFn by increasing the setTimeout delay to 15ms. Remember how long it takes to render all the Cards?

    batchScheduleFn: (callback) => {
      return setTimeout(() => {
        console.log('calling callback')
        return callback()
      }, 15)
    },

Then, lets check our logs:

Wait, this is starting to look like a fix, right? What about our network tab?

Ok, this looks like a fix. But I dont want this number to be this magic. I also would like to know the minimum amount of time I should wait. So lets reduce the 15m and test.

By bruteforcing this change, you will get to a point where 4ms will sometimes work, sometimes not. And 5ms seems like it will always work?

But wait, if this magic number is not tied to the amount of time it takes to render my list (15ms), what is it tied to? Why 5ms?

Know your internals. Or at least go to conferences?

The moment I started to wonder about those 5ms I immediately remembered about a talk I watched on React Summit. One of the statements of the presentation is based in this comment:

Our current heuristic is to yield execution back to the main thread every 5ms. 5ms isn't a magic number, the important part is that it's smaller than a single frame even on 120fps devices, so it won't block animations.

So that was it? But why it only happens when you use Suspense? The answer is that when you use Suspense, the tree that got suspended is marked as idle priority. Meaning that if you dont use it, the rendering of that tree is going to be thread-blocking:

Rendering list > setTimeout > Thread busy > Finished rendering > Thread idle > setTimeout executes > Callback is called.

A different thing happens when youre using Suspense and the tree has idle priority:

Rendering list > setTimeout > Suspense > At 5ms, it rendered the list partially > Yields execution back to the main thread > Main thread is do its thing and executes the setTimeout cause its not blocked by rendering anymore > Main thread becomes idle > Rendering proceeds to next list items > Repeats until the whole list is rendered
So basically, the rendering of the list happens in chunks and, because its "non-blocking", every time it yields back to the main thread, the setTimeout executes and triggers dataloader before all the Cards can make their requests.

Confirming the assumptions

Surely all of this is only one big assumption from my side. How can I test it?

Instead of using a setTimeout, we can use the Scheduler to schedule the callback. If this is done, we are not dependant on any "magic numbers". Unfortunatelly, the API is still marked as unstable. But we can already use it for the sake of curiosity:

// src/api/queries.ts
import { unstable_scheduleCallback, unstable_IdlePriority } from "scheduler";

// ...
  {
    batchScheduleFn: (callback) =>
      unstable_scheduleCallback(unstable_IdlePriority, callback),
    cache: false,
  }
// ...

And then we have our updated codesandbox with a working solution:

Uncertainty about the 5ms setTimeout

To this date I am not 100% sure if the 5ms timeout works for all scenarios. The Scheduler implementation differs from simply using a setTimeout and there may be some corner cases that the 5ms timeout wont cover.

I would say that using the Scheduler is a safer approach and recommend it, but unfortunatelly the API is still marked as unstable.

Uncovering Frontend Data Aggregation: Our Encounter with BFF, GraphQL, and Hydration

Lucas Correia — Wed, 22 Mar 2023 12:01:16 +0000

Our team at Chili Piper has recently started migrating our backend to a microservices architecture. As a front-end developer, I've been documenting my journey and insights while tackling the challenge of handling aggregated data in this new scenario.

NOTE: I've made slight modifications to the samples to prevent any potential exposure of Chili Piper internals

First of all, what is data aggregation?

Data aggregation in the frontend involves combining and organizing data from multiple sources to display it in a way that makes sense to the user. In a microservices architecture, where services are designed to be agnostic of each other, data aggregation can be a challenge because it may require making multiple requests to different microservices to retrieve all the necessary data.

This means you will often find yourself loading entities that look like the following:

{
  title: 'Billie Jean'
  artistId: 'some-uuid-here'
}

To display a card with both the track title and artist name, there are several steps to follow.

First, make a request to the tracks microservice to load the list of tracks.
Next, iterate over the tracks to collect the artistId.
After that, make a batch request to the artists microservice to collect all the artists from the list.
Finally, map each requested artist back to its corresponding track.

Although it seems simple and manageable with just a few lines of JS, it can quickly become complex. This is because the track entity may contain other entities besides the artist, and the artist entity may also contain sub-entities such as bands.

The n+1 problem

The N + 1 problem arises when an application retrieves data from a database and iterates over the results, resulting in repeated database queries. Specifically, the application will issue N additional database calls for every row returned by the initial query, in addition to the original query (+1).

It may seem familiar to what we just discussed, right? If you replace the database with microservices, that's essentially it.

The solutions we experimented with

Our use-cases often require us to load a list of items, and then make additional requests to fetch more data to display information related to each individual item. It can quickly become complex if we need to go several levels deep to retrieve all the necessary information.

Batch endpoints as first solution

Initially, we relied on frontend calls to batch endpoints to display data from multiple sources. However, we soon discovered that this approach had limitations, particularly in terms of performance due to the n+1 problem. Additionally, making multiple requests to the backend in frontend can be costly and not very user-friendly, particularly when waiting for data to load. This led us to explore more efficient data aggregation methods.

We identified two possible methods for implementing data aggregation in the frontend:

Transforming the received data and adding the related entities

const aggregatedCards: Card[] = cards.map(card => {
  const draftPayload = card.draft.payload
  const publishedPayload = card.published.payload

  const updatedDraft: DraftCard = set(
    'payload.cardType',
    cardTypesMap[draftPayload.cardTypeId]
    card.draft
  )

  const updatedPublished: PublishedCard = set(
    'payload.cardType',
    cardTypesMap[publishedPayload.cardTypeId]
    card.published
  )

  return {
    draft: updatedDraft,
    published: updatedPublished,
  }
})

Pros:

The related entity is directly injected into its parent, making it easily accessible.

Cons:

Transformation logic needs to be implemented, adding complexity to the code.
Predefined types (Our case involves auto-generated types based on our backend's OpenAPI specification) must be extended to accommodate the new entities, which can be cumbersome.

Dealing with code transformation logics can be even more challenging if the parent entity is part of a union. Here's an example of code we used in one of our experiments:

type AggregatedCardA = CardA & {
  cardType: CardType
}

type AggregatedCardB = CardB & {
  cardType: CardType
}

type AggregatedCard = AggregatedCardA | AggregatedCardB

export interface CardData {
  metadata: SimpleMetadata
  payload: AggregatedCard
}

export interface Card {
  draft: CardData
  published: CardData
}

We had to redefine all the types because of the necessary data transformation to aggregate cardType into CardA and CardB within that union.

Relationship maps as alternative

We also explored an alternative approach where instead of transforming the data, we provided a relationship map to send down the React tree. When we needed to use a relationship, we could simply pick it from the map. Here's an example of the code we used for this approach:

export const aggregateData = async () => {
  const data = await getCards()

  const cards = data?.cards ?? []

  const cardTypesIds = cards
    .map(card => {
      const { payload } = card.draft
      return payload.cardTypeId
    })
    .filter((item): item is string => !!item)

  const cardTypes = await findBatchedCardTypes(cardTypesIds)

  const cardTypesMap = keyBy(cardTypes, 'id')

  return { cardTypesMap, cards }
}

Drawbacks of this approach:

It can be challenging to memoize the cardTypesMap when passing it down to card items components, depending on the specific use-case.
The approach relies on prop drilling the cardTypesMap.

Note: We considered implementing these features on a raw node BFF server to reduce loading times and eliminate the need for multiple backend calls. However, we realized that we would still face the same issues with types and data transformation.

Following discussions with individuals outside our organization, we decided to experiment with GraphQL as a potential solution.

The findings when experimenting with GraphQL

In short, we chose not to pursue GraphQL due to some limitations with union types and a lack of support for maps. This is further detailed in this link: limitations.

We are aware that we could use aliases as a workaround, but that would mean the data structure would differ from what our types are expecting, and we would face the same issue of having to extend our types.

Anyway, we came across two amazing tools that are useful in situations where a BFF is necessary:

graphql-mesh is a tool that allows you to integrate backend microservices (whether they are REST with OpenAPI specs, GraphQL, etc.) into a single GraphQL Gateway. It's easy to set up as it generates schemas, queries, and mutations based on the provided specifications. You only need to implement additional properties for data aggregation

The main setup for us consisted of three files:

.meshrc.yml

sources:
  - name: Card
    handler:
      openapi:
        endpoint: https://cp.com/card
        source: card.json
        operationHeaders:
          Authorization: "{context.headers['authorization']}"
  - name: CardTypes
    handler:
      openapi:
        endpoint: https://cp.com/card-type
        source: card-type.json
        operationHeaders:
          Authorization: "{context.headers['authorization']}"

additionalTypeDefs:
  - ./typeDefs/card.graphql
additionalResolvers:
  - ./resolvers/card

./typeDefs/card.graphql

extend type Card {
  cardType: CardType
}

./resolvers/card

import { print, SelectionSetNode } from 'graphql'
import keyBy from 'lodash/keyBy'

import { Maybe, CardType, Resolvers } from '../.mesh'

const resolvers: Resolvers = {
  Card: {
    cardType: {
      selectionSet: `
      {
        cardTypeId
      }
      `,
      resolve(root, _args, context, info) {
        return context.CardTypes.Query.find_card_types({
          root,
          key: root.cardTypeId,
          argsFromKeys: ids => {
            return {
              id: ids,
            }
          },
          valuesFromResults: (data?: Maybe<Array<Maybe<CardType>>>, keys?: string[]) => {
            const map = keyBy(data, 'cardTypeId')
            return keys?.map(key => map[key]) || null
          },
          selectionSet(selectionSet: SelectionSetNode) {
            return print(selectionSet)
          },
          context,
          info,
        })
      },
    },
  },
}

export default resolvers

Another tool we discovered was wundergraph, which we didn't have the chance to fully explore. However, based on our initial research, it appears to be similar to graphql-mesh but more powerful, using JSON-RPC instead of GraphQL.

Mixed approach: Lazy-loading with dataloader

What if, instead of loading all the necessary data at the list-level, we loaded it at the item-level as needed? This would eliminate the need for data transformation or changing types, and there would be no prop drilling. Instead, we would load the data for each individual item when it is needed and use it directly where it is needed. Additionally, we could display a placeholder or blurred version of the component while the data is loading:

const { data: cardType, isLoading } = useCardType(card.cardTypeId, {
  enabled: Boolean(card.cardTypeId),
})

// if its loading, render blur version, if its not, render cardType info

The downside of the item-level loading approach is that it requires each item to make its own request, which can lead to a high volume of requests to the backend as the number of items increases. However, after researching potential solutions, we found that GraphQL's dataloader tool could help us address this issue through its batching feature.

For those who are unfamiliar with the dataloader batching feature, it groups together requests that occur in the same event loop tick and calls the provided loader to make a single request instead of multiple. Once it receives the results, it automatically maps the response back to each individual call. This feature essentially solves the main issue with the lazy-loading strategy.

Implementing a react-query + dataloader hook is a simple process. Here's how we did it:

type Key = { id: string; }
const cardTypesLoader = new Dataloader<Key, CardType>(
  async keys => {
    const resultMap = await CardTypesApi.findCardTypes({
      id: keys.map(key => key.id),
    })
    return keys.map(key => resultMap[key.id])
  },
  {
    cache: false, // <-- IMPORTANT, dataloader doesn't have the same cache management as react-query
  }
)

export const useCardType = (id: string, options?: { enabled?: boolean }) => {
  return useQuery(
    ['card-type', id],
    () => {
      return cardTypesLoader.load({ id })
    },
    options
  )
}

How does it solve the problem of data aggregation?

First, let's address the question: Why is data aggregation necessary?

We want to have a fast way to request all the sub-entities so users can see/interact with our items as soon as possible. We want to reduce user idle time.
We want to map all the requested sub-entities to their respective parent. So in our case, we want to aggregate the card type into the card because we want to use it in the card component.

How does lazy loading with data-loader address these issues?

With lazy-loading, we can display list items to the user without waiting for the additional information related to other microservices to load. This approach allows users to see and interact with cards sooner than any other approach, including BFF, and results in the least amount of idle time.
By using dataloader, we can use react-query in each item of our list to request the sub-entity we want to use in that item. This eliminates the need to map sub-entities to entities since the place we request them is the place where we use them. We don't need to change types or data structures in any way.

Extra points for lazy-loading

Since we will be utilizing batch endpoints and not aggregating data, the final JSON payload exchanged between the backend and frontend is reduced. This is because duplicates can be removed when sending the request to the dataloader if two cards have the same card type.
By using react-query to retrieve sub-entities in a pagination scenario, already-resolved entities in page 1 will not be re-requested in page 2.
This is also true when using a virtualization library. Sub-entities are only loaded for what's on the user's screen, and when the user scrolls down, react-query cache is utilized to prevent reloading what's already been requested.

But hey, wont we have too many rerenders?

Using dataloader actually groups all sub-entity requests for a given entity, resulting in simultaneous resolution of requests and minimizing rerenders, even in scenarios with a high number of items on a page. For example, in the team card card, 3 sub-entity requests are required (card-type, user, and progress), which means that regardless of the number of cards on the screen, only 3 (visible) rerenders will occur.

Additionally, incorporating smooth CSS transitions between the loading state and actual state can enhance the user experience even further.

Note that if the 3 rerenders in your list are causing performance issues, it may be more effective to address these issues through virtualization rather than attempting to reduce the number of rerenders.

Hydration as a opt-in performance improvement

This approach allows you to take advantage of react-query hydration for data prefetching, even without utilizing SSR. By creating a node endpoint that fetches your queries and returns a dehydrated state to the frontend, you can benefit from partial hydration. This enables you to prefetch essential queries while leaving the frontend to lazy-load the rest. Consequently, you achieve performance comparable to the BFF approach, without the need to manage aggregation logic.

It also has a built-in fail-safe: if the prefetch endpoint is down, the frontend will resort to directly requesting data. This ensures that your application remains functional even in the face of potential issues.

A downside is the necessity of introducing prefetching logic to the BFF, though it's notably less code than aggregation.

There is no silver bullet

In instances where the n+1 problem occurs or when optimizing performance is essential, implementing the prefetching strategy is not optional.
If you find yourself in a scenario where you need to handle data from several interdependent sources and your processing logic requires data from both sources prior to displaying it to the user, then this alternative is likely unsuitable.

In the end, which approach did we take at Chili Piper?

General consensus claims that the lazy-loading and dataloader method is a more elegant solution and it is commonly adopted in various scenarios. In a particular case, we use BFF due to the need to process the data before presenting it to the user.

As a bonus, here's how lazy-loading looks like in one of our pages:

Forem: Lucas Correia

Contract Tests with TypeScript and OpenAPI Codegen

Introduction

Minimal Setup for Contract Tests

Steps to Implement Contract Tests

Performance Considerations

Why Contract Tests Instead of Just Relying on openapi-diff?

Handling False Positives in TypeScript Project References

Our Solution

Conclusion

Key takeaways:

Client-first RSC: A scalable solution for data aggregation

RSC vs SSR

Do you need SSR?

SSR scalability

Then why RSC?

Why server actions?

How does it solve scalability?

Why not GraphQL?

Solving the data aggregation problem

Maybe JSON:API?

Generic solutions and caching

Reinventing the wheel?

To be continued

Conclusion

Integrating Dataloader with Concurrent React

Facing the issue

Finding the root cause

Know your internals. Or at least go to conferences?

Confirming the assumptions

Uncertainty about the 5ms setTimeout

Uncovering Frontend Data Aggregation: Our Encounter with BFF, GraphQL, and Hydration

First of all, what is data aggregation?

The n+1 problem

The solutions we experimented with

Batch endpoints as first solution

Relationship maps as alternative

The findings when experimenting with GraphQL

Mixed approach: Lazy-loading with dataloader

How does it solve the problem of data aggregation?

Hydration as a opt-in performance improvement

There is no silver bullet

In the end, which approach did we take at Chili Piper?

Why Contract Tests Instead of Just Relying on `openapi-diff`?