[Feature Request] Propagate fetchOptions to all internal API requests and reference resolutions

[CaarLo1337]

Hello,
we’ve noticed that the fetchOptions provided to API methods like fetchByFilter are currently only applied to the initial fetch call and are not propagated to any subsequent or internal requests.

const contentAreas = await remoteApi.fetchByFilter({
  filters: [
    {
      field: "fsType",
      operator: ComparisonQueryOperatorEnum.EQUALS,
      value: "GCAPage",
    },
  ],
  fetchOptions: getCacheOption("cmsGlobalContentAreas") as RequestInit,
  locale: input.lang,
});

In this case, we use a Next.js cache strategy via fetchOptions:
{ next: { revalidate: 300 } }

However, this setting only affects the first fetch. Any internal requests – such as those for resolving references – do not inherit these fetchOptions.

Feature Request:
It would be highly beneficial if the provided fetchOptions were automatically applied to all nested or recursive internal API calls. This would ensure consistent handling of caching strategies throughout the full API request chain.

https://nextjs.org/docs/app/api-reference/functions/fetch

[nico-mcalley]

Hi CaarLo1337!

Thank you for your feature request.
There are two main options available for moving forward:

1. Submit a Pull Request (PR): We work together to bring your improvements to this repository.
2. Work in a Fork: Alternatively, you can implement the feature in a personal fork of the project.

A fork can often be the more practical approach, especially if you prefer to move independently and at your own pace. It gives you full control over the implementation, though it may introduce slight divergences from the main project.
A Pull Request may be slower and more work, as it requires review, adherence to project standards, and may be rejected if it doesn't align.
The use case you describe appears to be relevant and potentially beneficial for other users of this project as well.
If you choose to contribute via a Pull Request, please ensure that it meets the following criteria:

• The changes are concise and limited in scope (eg affecting the least amount of files necessary)
• Backward compatibility is maintained
• New functionality is thoroughly tested
• Existing tests continue to pass
• The PR can be merged cleanly without conflicts

Additionally, please make sure to read and follow our contribution guide before submitting a PR.
Note that both the RemoteApi and the ProxyApi need to be properly considered in your implementation.

Best regards,
Nico