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

IGDB API v4 migration #541

Open
tkashkin opened this issue Mar 20, 2021 · 2 comments
Open

IGDB API v4 migration #541

tkashkin opened this issue Mar 20, 2021 · 2 comments
Labels

Comments

@tkashkin
Copy link
Owner

IGDB was acquired by Twitch and new IGDB API is now part of Twitch API, so it now uses Twitch API authentication.

Basically this means that GameHub can't include an API key and should either have a server to proxy requests or require end user to create a new app on Twitch and use an app token to call IGDB API.
Both of these options seem inconvenient.

Here is the message I sent to the IGDB Discord at the time they were deprecating v3 API:

Hi. I'm trying to migrate my serverless app to new IGDB API.

Currently app contains a default user-key and suggests users to register their own keys if limits are hit.
(Yes, I know user-key shouldn't ideally be available on the client, but there's not that many users and requests.)

So if I understand docs correctly, my options are:

  1. Setup a server to proxy requests (I'd like to avoid relying on additional servers)
  2. Include default client_id and client_secret, generate new app tokens, hit 25 tokens limit repeatedly and probably get banned
  3. Include default client_id and client_secret, authorize user on Twitch, generate user tokens (do user tokens even work for IGDB endpoints?)
  4. Require end users to register a new Twitch app and set client_id and client_secret, then use option 2

Are there any recommendations for apps without a server (other than "don't do that")?

Answer:

  1. do this and optionally cache data so you don't do a round trip if you don't need to
  2. Thats against the agreement (leaking tokens/secrets)
  3. Same problem and user tokens don't work
  4. That works but clunky for the end user

I'm not sure what to do, option 4 seems to be the best, but it will be inconvenient for the users.

@tkashkin tkashkin mentioned this issue Mar 20, 2021
17 tasks
@Lucki
Copy link
Contributor

Lucki commented Mar 22, 2021

From a user perspective 1. is the best. The 4. option requires some serious willpower to get through the hassle.

Are there other services which provide similar information and are viable?
A quick search showed me https://rawg.io/apidocs - https://api.rawg.io/docs/#operation/games_read

Free for personal use as long as you attribute RAWG as the source of the data and/or images and add an active hyperlink from every page where the data of RAWG is used.
Free for commercial use for startups and hobby projects with not more than 100,000 monthly active users or 500,000 page views per month.

@tkashkin
Copy link
Owner Author

Are there other services which provide similar information and are viable?
A quick search showed me rawg.io/apidocs - api.rawg.io/docs/#operation/games_read

Looks interesting and I'll think about integrating it.


But it doesn't really solve the problem: client bundles API keys it ideally shouldn't.

A server to manage keys, proxy and cache requests is the proper solution, but it raises a few questions:

  • Where to host it?
  • What happens when it's offline and eventually completely dead?
    That's one more point of failure that is more likely to fail than individual APIs like Steam, GOG, IGDB, etc.

Currently there is no other functionality that may require a server.

If there is a server:

  • It must be open-source and self-hostable
  • GameHub must allow to override server address
  • GameHub should be able to work with APIs directly in serverless mode by either hosting a server on localhost or allowing to set all API keys in the app and continuing to work as it does now

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

No branches or pull requests

2 participants