— — — —— — —
×
— —— —
— — — —— — —
×
— —— —
— — — —— — —
×
— —— —
← darkroom
Options for searching based on `updatedAt` value
I'm currently working on an application leveraging the AL API that relies heavily on long-ish-term caching. So far so good, but I've recently come across a problem: I'm unable to efficiently* check for changes that were made outside the app.
*Efficient not only meaning performant, but also not causing unnecessarily hefty strain on the API every time the app restarts
Proposal: I'd love for the ability to search for entries based on the updatedAt value (that is, when an MediaList item was last edited) similar to how MediaList has the startedAt_lesser and startedAt_greater arguments.
My specific use-case would look at the most recent change recorded in the app upon startup and send an API request for any entries that were updated after that point (I.e. outside of the app) using the Unix timestamp, and update the cache to match those entries if present.
This option would ideally apply to Page.mediaList, MediaList, and MediaListCollection, but it could also be useful for the forum to prevent overfetch with polling if possible. (Threads might just be too dynamic to put them through the ringer like that, though.)
If there's already an existing way to do this without having to ask for every entry's updatedAt value and filter through them on the client side, please let me know!
Sort by updated_at and get the entries until you get the one you last saw? Really, I don't see that much value in adding a new filtering fields for this when at most you need to fetch maybe around 50 entries more.
Thank you for your response, and thank you for the compromise! However, I do think being able to simply ask for entries updated after a certain date would be massively beneficial in my case. Rather than unnecessarily fetching a dozen irrelevant entries (assuming the user made no external changes, which may often be the case) every time the app starts (maybe with a cooldown), simply being able to call for the data I need would be super helpful from a stability standpoint.
My three concerns are:
- If someone used a tool to mass-edit their list (like adding missing entries from MAL), many of those edits won't be found and the only way to get them is to manually expire the cache.
- Similar to the last point, knowing how many entries to fetch is a bit miscellaneous. You wouldn't "fetch 50 entries at most" because it'd need to be a constant value, and if that value is 50...
- As you might be able to guess, I've put a good amount of effort into preventing under- and over-fetch in order to keep with the principles of GraphQL, and maybe some deep-rooted obsession with caching. I'd love to be able to continue with that.
I can implement client-side mitigations for the first two concerns* but they still wouldn't be nearly as clean (code-wise and principle-wise) or fast as just being able to call for the entries updated after a certain point.
*1) If you don't find the most recent edit made internally, ask for another page. 2) Only fetch theidandupdatedAtvalue for the entries, and when you find the most recent edit made internally go back and ask for the missing fields. (Probably through another paginated request)