• Quango (unregistered)

    If they really cared they'd put a rate limit on the service, so don't fret too much

  • (nodebb)

    One of our microservice's pointless jobs was to refresh the access token every 5, 15, and 30 minutes for 22 of the 24 hours we had access to it.

    So you sent requests to their API 3 times per hour? I somehow doubt that they noticed being "hammered".

  • (nodebb) in reply to Dragnslcr

    So you sent requests to their API 3 times per hour?

    It could be read as one set of requests every 30 minutes, one every 15 minutes and one every 5 minutes, for a total of 2+4+12 = 18 requests per hour. Of course, I still don't see how that counts as "hammered", unless it's the colloquial meaning of "hammered", meaning "very drunk".

  • (nodebb) in reply to Steve_The_Cynic

    It could be there's an implied multiplier of "for each API endpoint" or "per business entity (customer, order, etc.)" Then it might be 18 * 204 or something. Enough to show up on the logs, anyway.

    Or not.

  • Anon (unregistered)

    Even if it is 60 times per hour, that's still pretty minor in the grand scheme of things. That third-party API provider probably has hundreds of clients, and so something every 5 minutes or less frequent is business as usual.

    Thank you for caring, but this is far from hammering, and probably no one noticed because it was such "low" volume. Barely enough to make a dent on the monitoring graphs.

  • Deeseearr (unregistered)

    Depending on just how thoroughly the spaghetti and meatballs were intertwined, "as soon as we get access, we download the data" could mean that every time the token was refreshed, the full data set was downloaded again.

    Also, there's no number given but "Every single consent for that day kept getting refreshed, over and over" does suggest that every query sent to the API received it's own token, and that every single one of those was being refreshed every five, fifteen and thirty minutes in a painfully over-complicated version of Fizz-Buzz.

    I've seen worse, but don't envy anyone the task of trying to untangle it all.

  • (nodebb)

    The missing part of the story is what happens after 24 hours when the token actually expires? Does someone have to manually log-in or something? What's the issue?

  • dusoft (unregistered)

    This is confusing or just not written clearly enough.

  • Fizzlecist (unregistered) in reply to dusoft

    Or it's a case of "I had to suffer through trying to understand this mess, so now let me share some of that pain"

  • (nodebb)

    I've seen some pretty crazy uses for APIs where that sort of refresh happens way too often, sometimes just as sort of an "is there an internet connection" checker. We've then had to have conversations with the clients about what they're actually doing for those cases and why they're choosing our API to determine that sort of thing.

    Also have some APIs where people seem to be just stepping through large amounts of data for ... something. Usually a good indication that we need a better search function somewhere to return just the data desired. :)

  • (nodebb)

    Sounds like a form of OAuth2 with refresh tokens.

    Usually you have to log in and you get an access token and a refresh token. The access token lets you do your work for a short period of time (~an hour). After an hour the token expires. You can then use a refresh token to get a new access token (and a replacement refresh token) so you don't have to ask the user to log in again. If the refresh token expires, then you have to ask the user to log in again to get new tokens.

  • (nodebb)

    Oh no. It sounds like a caching service implemented (or meddled with) by someone who doesn't understand caching.

Leave a comment on “A Refreshing Change”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article