DrupalClient.getIndex() needs to be be cacheable, to reduce 50% of calls made to server.
Every single call that is run uses getIndex() first, which is the base call to /jsonapi, the problem with this is that during lengthy builds, this increases calls to the server by 50%. When using a hosting platform like Acquia, which counts these calls as page views, it can easily push the server call usage over the limit.
To get around this for now, I've extended the class and wrapped the parent call in a cache statement per locale, but having the option to cache this would be very useful.
It would also be useful to make the cache property protected, instead of private, to make extending a little cleaner.
@nonapod - Interested in your suggestions for cache options. I assume something in the sort of an option here? https://github.com/chapter-three/next-drupal/blob/main/packages/next-drupal/src/get-resource.ts#L17
@nonapod if you use the useDefaultResourceTypeEntry setting on the client the overview page will not be called at all
I'm wondering if we should flip this around. Instead of having a useDefaultResourceTypeEntry optimization that 90% of people will want. What if we add a config to opt-in to querying for the entry points of resources?
This would be a breaking change so we need to decide/implement this quickly as next-drupal 2.0.0's release is imminent.
2.0.0-beta.0 will introduce a new NextDrupal class that has a useDefaultEndpoints option that defaults to true. When useDefaultEndpoints is true, the NextDrupal object will programmatically-create the JSON:API endpoint instead of using a request to look up the endpoint.
The new version will continue to have a DrupalClient class that provides backwards-compatibility where the useDefaultResourceTypeEntry option (that defaults to false) overrides the useDefaultEndpoints option.
This code change was committed with #716.