Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

withEverything query. #10

Open
adminy opened this issue Sep 11, 2024 · 4 comments
Open

withEverything query. #10

adminy opened this issue Sep 11, 2024 · 4 comments

Comments

@adminy
Copy link

adminy commented Sep 11, 2024

is there a reason why you're breaking it down into parts and not just query with everything there is to query? I'd say that would be great + if you can cache everything you query so that no duplicate queries exist. That way once you cache the result, the next query to be made doesn't have to call the rate limited api.

@Didas-git
Copy link
Owner

It is broken into pieces because that's what graphql is for, there is no reason to fetch all the data at the same time.
About duplicate queries, could you explain a bit more what you mean with it? I plan on rewriting the library soon so depending on what that issue is i could try to address it.

@adminy
Copy link
Author

adminy commented Sep 11, 2024

I'm fine with graphql being on top of anything as an extra, I just think the core api call should be fetching everything for the sake of making less calls. then whatever interfaces the fetched data can be graphql or sqlite or anything really. Caching for the sake of keeping the rate limiting in bounds, so that there is a middle hop, once data is in cache then graphQL can make any amount of calls to it. Also in case anilist decides to change the API, the data is already cached and if something were to change, it wouldn't affect the library because its working on previously fetched data.

@adminy
Copy link
Author

adminy commented Sep 11, 2024

Currently its in a state of everything breaks if anilist is down.

@Didas-git
Copy link
Owner

I'm fine with graphql being on top of anything as an extra, I just think the core api call should be fetching everything for the sake of making less calls. then whatever interfaces the fetched data can be graphql or sqlite or anything really. Caching for the sake of keeping the rate limiting in bounds, so that there is a middle hop, once data is in cache then graphQL can make any amount of calls to it. Also in case anilist decides to change the API, the data is already cached and if something were to change, it wouldn't affect the library because its working on previously fetched data.

The core anilist api is graphql, there is no reason for the library to fetch everything, you as the developer should know what your app needs and fetch accordingly.

And of course the wrapper wont work if anilist is down, thats normal.
If you want some form of caching thats up to you to implement it, its not up to me to implement an arbitrary cache and force everyone to use it, that would not even make sense

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants