-
Improvement
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
None
I want to decrease the number of API requests needed to save users time and server resources.
Use case: The user wants to see every information provided for a specific festival.
Problem: We need 50+ requests to fulfill this, depending on the size of the festival. See Wacken for example. Seven days with 10+ stages each.
Proposal: Include Sub- and Sub-Sub-Events (Main-Day-Stage) in lookup responses. Maybe a parameter for specifying the depth. It is important to have the event-artist rels included for each event. And maybe event-place rels as a bonus.
Is this even possible? How much work will it be?
I want to help as much as I can with implementing. The problem is, that I am more of a client/frontend developer. C#, WPF, Kotlin/Java, Android.... But I am willing to learn. My SQL knowledge is basic.
[MBS-13963] Include Sub-Events in Event lookup
Hmm, I'd rather not add more ad-hoc recursive queries to the webservice. recording-level-rels and work-level-rels have already caused us significant problems already. Even though event parts are much less numerous than those, it still becomes critical to handle the depth restriction correctly because relationships can have (incorrect) cycles.
I think the solution should be more generalized and fit in with the rest of the API. We can probably resolve this ticket by simply adding support for browsing events by event (which I'm surprised isn't supported yet), and allowing the client to specify multiple event MBIDs to browse against, similar to what was done for URLs in MBS-13943. That should let you get all sub-events with approximately one request per level (keeping in mind browse requests are paged).
One Request per level (3) sound way better than 50+.
How much work will it be? Can I help?