Improve performance dramatically

I've opened a merge request with these optimizations. The improvement is dramatic. After label, section, and collection data has been cached the initial load of the media library has gone from about 7.5 seconds down to about 1, and every interaction with the filters has gone from a whopping *20 seconds per interaction* to just 1 second per interaction!

Previous to this optimization, every interaction with filters entailed a full 71 requests to the BF api for me (your numbers will be at least partially driven by the number of labels in your BF instance)! The optimization gets this down to 1 request.

I've arbitrarily chosen a 10 minute cache TTL for the label, section, and collection data. I want them to reflect changes in BF in a relatively timely fashion while still benefitting from the caching. I could see exposing this as an option to users, or even letting the user choose to have the cache never expire and forcing the user to do a manual re-load of their BF data if it's stuff that changes extremely seldom. But a 10 minute TTL seemed like a reasonably balanced starting point.

Hi azinck, I definitely agree with the direction here. Labels in particular can be time consuming currently.
I'm working on performance improvements for the 6.x branch, which has a number of other changes, but I'm open to approving this for the 5.x to help users more immediately & broadly. Can you update the MR to make the cache lifespan configurable?

Hello, I am a colleague of @azinck, and working on the same project with the Brandfolder integration. I was working on routine module upgrades, and looking at the Brandfolder 6.x version. It seems that the 6.x release notes state:

New, decoupled asset browser to enable better UX, better separation of concerns, better performance, better DX, new features, etc.

The new UI looks powerful, but it brings with us a couple of issues. The one in scope of this is that I'm not seeing any significant performance improvement in 6.x Vs. 5.x. In fact, requests to Brandfolder seem to be taking 13-15 seconds each for me (maybe less that 20s Aaron mentions, but my observations were fairly anecdotal, but in any case, both are a bit extreme for a normal fetch/read operation). Also a side note, the "Fetching assets" text is a bit unclear that it's doing anything, it might make it more clear if the ellipses had a little animation or something.

Looking at the module, it seems we are still hitting a lot of these endpoints for every request, and a short TTL cache could go a long way here.