Takes long to retrieve information

[Niall7459]

It takes around 3-4 seconds to receive the data.
Is there anyway to speed this up?

[Tustin]

Well, if you're properly storing your refresh token and only refreshing your access token when it expires, that could help a little bit. Ultimately though I'd like to lazy load all of the profile properties so that the data is only fetched & parsed when requested. Although I'm not totally sure how that works in PHP.

So to answer your question, not really at the moment. My suggestion is that if you run a stat viewer website, maybe only allow manual stat updates when the user clicks a button or something?

[Niall7459]

I’m updating it to use jquery to fetch info, instead of pre-processing it when the page is loaded. Great project though 👍

[atgrau]

What about using sessions?

        session_start();
        if (!isset($_SESSION['auth'])) {
          $auth = Auth::login('epic_email@domain.com','password');
          $_SESSION['auth'] = $auth;
        } else {
          $auth = $_SESSION['auth'];
        }

Elapsed time is reduced from 4.5 to 1.5.

[Niall7459]

Thanks, also is there any api requests limit. I don’t really want my account banned. I tried a new epic games account but didn’t have permission to view the stats.

[atgrau]

I do the same to avoid using mine, why you don't have permissions to view stats? You must login once, to accessing data.

[Niall7459]

I have logged in and verified the account, although I might try logging into fortnite itself.

[BulgarianHealer]

@Niall7459 Use cache service like Redis or Memcache, also account need to be only for api because if you start playing old session will be killed and no more stats.

[NeVeR2TrY]

@atgrau the session code isn't working it takes too long time also, on postman 4-5 seconds on localhost wow its 15+ sec

[atgrau]

It works for me... Using only PHP with CURL.

PD: nº4 is the first call, and nº2 second call (few seconds later, when session was created), check elapsed time.

[Niall7459]

Worked for me as well.

[NeVeR2TrY]

@Niall7459 how did you fix the unauthorized problem with the new account ?

[NeVeR2TrY]

@atgrau

time with session same as time with out session, do you have any explanation ?

[BulgarianHealer]

I would recommend to use a framework like laravel and use inbuild cache system. Example TTFB(Cached with Redis). Why do I recommend it? Because you can cache every request and use queue and cron job to automate everything.

[NeVeR2TrY]

@krokit i am using laravel, but i am new to laravel i don't know how to use it, already downloaded redis with composer yesterday but when i stored "auth" in cache it gave error that profile not recognized .

[NeVeR2TrY]

@krokit Thanks man it worked

[NeVeR2TrY]

@krokit if i used forever to store the auth it would be a problem ?
or what is the best time to keep it in cache?

[BulgarianHealer]

@NeVeR2TrY Depends on what you store in the cache. For example, i cache Auth for 475 min. because the session is 480 min, yes i can refresh it but for dev i prefer to re-cache it. For the leaderboard, i set 15 min. cache. For the store is caching time depends on the left time to midnight.

        if (Cache::has('fortnite_api_get_auth_request')){
            $auth = Cache::get('fortnite_api_get_auth_request');
        } else {
            $auth = Auth::login('email@examople.com','password');
            Cache::put('fortnite_api_get_auth_request', $auth, 475);
        }

[BulgarianHealer]

@Tustin I recommend Auth to be renamed to Fortnite because other cms and scripts usually are using Auth for login and it's possible to have bugs with 2 packages with the same class.

[NeVeR2TrY]

@krokit how you got leaderboards working 👍 ?

[BulgarianHealer]

@NeVeR2TrY Check PR #36 :)

[Tustin]

@krokit It's under the Fortnite namespace so if necessary, you could always do Fortnite\Auth::login. Although if it's necessary I can always make the change 😄.

Edit: Although come to think of it, I might end up restructuring this library a bit to be similar to my psn-php project rewrite, so that all my PHP related API wrappers stay at least somewhat consistent.