ContentHubUI: Content hub client is sending a lot of identical requests

Description

Acceptance Criteria

  • The content hub client should cache results for requests for a short while and re-use the results of these requests whenever it needs.

Background

Every time the content hub client is opened up it sends several search requests for content and many of them are identical. Every time the search is cleared the same request is sent.

It is reported that there are 5 identical requests going on, but with the current implementation it was only meant to send 3 (one for each list).

Since the “Popular Content“-list is already fetched by the main tabular list, we can skip this request, and just pick the 6 first from the main list. In that way we end up with 2 initial requests.

Acceptance Criteria

None

Activity

Show:
Frode Petterson
September 15, 2020, 7:20 AM

No. When opening the HUB there are at least 5 simultaneous requests from the browser to the same endpoint. There is definitely something wrong with the hub client if it sends more before getting a response to the initial request. You could have a look at the content type section to see how we manage with one request there?

Pål Jørgensen
September 15, 2020, 7:28 AM

: It definitively shouldn’t be 5 requests. But I think it actually should be 3. I.e: one for each list.

Frode Petterson
September 15, 2020, 7:44 AM

Why 3? Isn’t 2 enough? In the plans, it says we should group them all into one initial request, but I’m fine with having 2 if it makes the implementation quicker.

Erik Langhaug
September 23, 2020, 12:11 PM

The caching seems to work as expected!

When we cache every search like this, should we to think about informing the author that results might be stale if the page has been open for a while? Something like a warning message somewhere at the top of the page simply suggesting to refresh the page perhaps.

If not, should we have some cache expiration logic?

Pål Jørgensen
September 24, 2020, 7:14 AM

I agree, I’ll add some cache expiration logic.

Assignee

Pål Jørgensen

Reporter

Thomas Marstrander

Funding

None

Code reviewer

Erik Langhaug

Released

None

Time tracking

4h

Sprint

None

Priority

Medium
Configure