This is follow-up work to further improve the performance of the components API. Caching component lists is a bit more tricky than applications because of the number of watches required. A component list may be composed of multiple component kinds and versions of those components. Also, a component is only a member of the list if it matches the selector from the application object.
The number of watches required to maintain this cache and their potential for needing to be restarted may be more costly than the theoretical benefit. If we watch the resources more loosely, e.g. any change to any Deployment invalidates the cache, then we could get away with less watches but have a higher potential for a false positive that clears the cache. Needs investigation.
This is follow-up work to further improve the performance of the components API. Caching component lists is a bit more tricky than applications because of the number of watches required. A component list may be composed of multiple component kinds and versions of those components. Also, a component is only a member of the list if it matches the selector from the application object.
The number of watches required to maintain this cache and their potential for needing to be restarted may be more costly than the theoretical benefit. If we watch the resources more loosely, e.g. any change to any Deployment invalidates the cache, then we could get away with less watches but have a higher potential for a false positive that clears the cache. Needs investigation.