Informatieobjecttypen retrieving performance improvement

[Xaohs]

The informatieobjecttypen fetch call takes about ~12-15 seconds with ~1k informatieobjecttypen, this means roughly 1.5 seconds per 100, this is extremely slow.

These get fetched in the loader on the zaaktype page, which slows the page down unecessarily as we do not need them until the informatieobjecttypen tab's select field.

Suggested solution:

• Select field asyncronously fetches, based on search query, with a max of ~20 ish results

[CharString]

See #271 (review)

Best solution IMHO:

• Check if OZ responses have Cache-Control, ETag and Vary headers (according to the spec and OZ OAS, GET on a specific informatieobjecttype should have ETag headers set, but that doesn't help options)
• Move options to a separate endpoint on the BFF (Promise.all() is our friend) so bff can reuse these headers¹, and responses are cached in the browser's local cache.

Alternative:

• implement a cache on the BFF
• invalidate it if request has Cache-Control: no-cache header, to force refreshing.
• ensure that front-end obeys the regular ctrl-F5 refresh that sets that header
• maybe add UI elements for cached data recognition and refresh requesting because ctrl-f5 may not be common knowledge
• still move options to separate endpoints, because busting the cache by user request will still bust all caches¹

From experience with managing caching proxies in the 90's it is important that you implement caches with the correct granularity, and as transparant and correct as feasible. Because otherwise users will make a habit of busting it, degrading the whole thing back to where you started (or worse), but with added perceived jank.

Footnotes

1. having all options for all related objects inside GET zaaktype makes it impractical to cache a zaaktype response, because any change anywhere will invalidate that cached response, making it useless. Paginating has a smaller but similar issue, maybe that's why only GET'ing specific resources is specified as having cache headers. ↩ ↩²