deliciousbees - Extra Life Community Hub Jump to content

deliciousbees

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

6 Neutral

About deliciousbees

  • Rank
    Novice Member

Extra Life

Profile Fields

  • Location
    Seattle

Contact Methods

  • Twitter
    deliciousbees
  • Twitch
    deliciousbees

Game IDs

  • PSN ID
    deliciousbees
  • Xbox Gamertag
    deliciousbees

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hey! Reposting questions here instead of our initial feature request thread so that it's all in one place: --- Two quick questions on the latest API update: * Does fetching multiple pages of donations count towards the 60s request rate/DDoS flagging? Or is that only for re-requesting/refreshing the same page? * Are you guys worried about the new "100 record" default breaking other applications that use the API before it was paginated? Don't get me wrong, I'm glad we have this functionality and that we have the bandwidth to roll with integrating that change here, but shifting that to the default a few days before game day also seems pretty scary in general.
  2. Hey Matt, thanks for the update! We'll implement changes today and yell if we run into issues. Two quick question: * Does fetching multiple pages count towards the 60s request rate/DDoS flagging? Or is that only for re-requesting/refreshing the same page? * Are you guys worried about the new "100 record" default breaking other applications that use the API before it was paginated? Don't get me wrong, I'm glad we have this functionality and that we have the bandwidth to roll with integrating that change here, but shifting that to the default a few days before game day also seems pretty scary in general. Edit: Just saw the other thread, I'll repost in there.
  3. I'd like to release it wider and it should be doable if all goes well (we're using NodeCG and our donation code is pretty isolated in its own bundle), but it'll depend on how busy we get with our other projects. If I haven't posted anything by October, shoot me a PM and I'll send you what we've got privately
  4. Hey there, @LeaveIt2Beaver! We're working on adding donation incentives to our backend for Extra-Life 2017, but we're running into a hurdle in that the guid and email for unique donations isn't exposed, so we have no way to determine a unique donation and emailing a code as "valid" through JSON alone. We can see the data we need if we manually scrape portal.donations while logged in - the data-id guid and data-email is perfect! - but I'd really prefer to use the JSON links and not revert back to manually scraping the site (or slamming extraLifeDonationsExport and generating our own guid) like the Dark Old Days. Any chance of getting that data exposed to JSON before this year's event? And even better, any chance of exposing data-id to the donor somehow so that we don't have to send them an automated Thank You email with their guid? Thanks! -Dan
  5. Hey @LeaveIt2Beaver, just pinging on this again - we're finishing up our backend revisions soon and it'd be great to have a reliable way to reference a donator at the very least.
  6. Hi there, LeaveIt2Beaver! Short version: We'd love some way to get a unique id for a donation (and/or donors). Also, depending on how limiting works since it's ambiguous right now, we'd love a way to either get all donations OR get donations in a range. Long version: Thanks for opening up the JSON feed last year - we used it during our stream for managing donations and our live counter and it was super useful! We did run into a few problems though that we'd love to get some solutions for before the big day this year: - Unique IDs for donations. Right now the closest we have is hashing some combination of donation amount, username, and time donated. Unfortunately, all of these are unstable for us - you can have multiple people donating the same amount in the same second (like the $4.20 rush on the Giant Bomb main stream), and the display name can change at any time and retroactively change the name of previous donations, making it unusable for hashing. It'd be great if we could bypass all of that and just have a donation ID that we could use instead. If that's tough, getting the donor ID would help us close that hole to a degree too - while we'd still have the money/time issue, we could include a stable donor ID into the mix to get something unique since the same person isn't going to donate twice in a second. "Can't you use the order that these donations come in?", I hear you say? Well, that leads to the next request! - A way to get all donations, OR a way to get a range of donations, depending on intended behaviour. Our initial testing last year showed that on some big pages, the JSON request would only show the most recent donations (~170 iirc?) - hence why we had to generate our own ID per donation. When we were live, we did manage to get a full list of multiple hundreds though - so I'm not sure if the behaviour changed between testing and live, the limit was raised, or if we weren't flagged as a "big" fundraiser. So depending on functionality... If the behavior is that JSON returns all donations all the time - we'd love a way to get donations in a range too, so that we aren't pulling in big sets of data every minute when we don't need to. It'd be great if this includes the row count as well. If the behavior is that JSON returns the most recent x donations - we'd love a way to get the full list of donations, for situations where we need to wipe our local cache. Thanks again! -Dan
×
×
  • Create New...