Change Details

Based on the data we have in usage tracking we can (not completely, but close enough) reproduce what resources will be loaded from the repo, thus we can preload these in one go. This has been discussed before and I just looked into this again, thinking it was easy to implement and could probably save us some time. There are a few design decisions that we need to make here. The simplest way to go about this it to have a caching decorator around UsageLookup and then have individual means of making use of that data for `EntityPrefetcher`, `LanguageFallbackLabelDescriptionLookupFactory` and (maybe later on also) `CachingSiteLinkLookup` (T95567). The benefit of this is, that we can use the data from usage tracking and do the prefetching where needed, but it also means that we potentially have some duplicate code and it might be messy to handle a case where two titles are rendered in a single run (does that ever happen? Is this relevant?). Another way to do this would be to have a central service which individual prefetchers good sign up for prefetching. The downside of that is, that it will probably create quite some abstraction (I didn't yet think of an exact design). Also it seems difficult to handle the state between that service and the actual users, especially given how we use `LanguageFallbackLabelDescriptionLookupFactory` right now (see `Scribunto_LuaWikibaseLibrary`). Also we might want to not do that at all, should we decide to drop usage tracking based on MySQL tables?

Based on the data we have in usage tracking we can (not completely, but close enough) reproduce what resources will be loaded from the repo, thus we can preload these in one go. This has been discussed before and I just looked into this again, thinking it was easy to implement and could probably save us some time on page rendering as entity usage barely (fundamentally) changes. One way to do this would be to have a central service which individual prefetchers can sign up with for prefetching. The downside of that is, that it will probably require quite some abstraction (I didn't yet think of an exact design, but I guess we would need to have at very least one extra class per type of prefetcher and an interface). Also it seems difficult to pass the state (the cached data) between that service and the actual users, especially given the many places we use instantiate term lookups during page rendering right now (for the parser function and Lua). Also we might want to not do that at all, should we decide to drop usage tracking based on MySQL tables?

Based on the data we have in usage tracking we can (not completely, but close enough) reproduce what resources will be loaded from the repo, thus we can preload these in one go. This has been discussed before and I just looked into this again, thinking it was easy to implement and could probably save us some time. There are a few design decisions that we need to make here. The simplest way to go about this it to have a caching decorator around UsageLookup and then have individual means of making use of that data for `EntityPrefetcher`, `LanguageFallbackLabelDescriptionLookupFactory` and (maybe later on also) `CachingSiteLinkLookup` (T95567). The benefit of this is, that we can use the data from usage tracking and do the prefetching where needed, but it also means that we potentially have some duplicate code and it might be messy to handle a case where two titles are rendered in a single run (does that ever happen? Is this relevant?). Another way to do this would be to have a central service which individual prefetchers good sign up for prefetching. The downside of that is, that it will probably create quite some abstraction (I didn't yet think of an exact design). Also it seems difficult to handle the state between that service and the actual users, especially given how we use `LanguageFallbackLabelDescriptionLookupFactory` right now (see `Scribunto_LuaWikibaseLibrary`)time on page rendering as entity usage barely (fundamentally) changes. One way to do this would be to have a central service which individual prefetchers can sign up with for prefetching. The downside of that is, that it will probably require quite some abstraction (I didn't yet think of an exact design, but I guess we would need to have at very least one extra class per type of prefetcher and an interface). Also it seems difficult to pass the state (the cached data) between that service and the actual users, especially given the many places we use instantiate term lookups during page rendering right now (for the parser function and Lua). Also we might want to not do that at all, should we decide to drop usage tracking based on MySQL tables?