The work on #232 had an ultimate goal yet unfulfilled, which is to make the web application faster when searching for a lot of data. The query performed in the provider itself might be faster, but then the DIM-level aggregation and serialization procedures are not memory-efficient and lead to very large loading times after it was requested.

Granted, we know that there are limits in the query interface itself, and we can only go so far without DIM-level querying, which is being worked on as we speak. However, it should already be possible to leverage the /searchDIM API, as extended in #232, to retrieve the results page by page, thus making the web app request for less data. We may also consider only fetching patient and study-level data until the user chooses to navigate deeper into the result tree.