Tim [DonorDrive] - Extra Life Community Hub Jump to content

Tim [DonorDrive]

  • Content Count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About Tim [DonorDrive]

  • Rank
    Regular Member

Extra Life

Profile Fields

  • Location

Contact Methods

  • Twitter
  • Discord

Game IDs

  • Blizzard Battletag

Recent Profile Visitors

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

  1. Oh I'm sorry, I just assumed you were on there... Hop onto the ExtraLife4Kids server. There's a #donordrive-support channel in there. I'm "@Tim [DonorDrive]"
  2. You *shouldn't* be, but I can't rule it out. If you'd like to DM me with some network info, I can take a look. You can find me over on the #donordrive-support Discord channel. As far as polling strategy, let me walk you through what we do internally. We leverage the `etag` + `if-none-match headers` to determine the need to poll "subordinate" endpoints. Using the participant + participant donors model above, you can poll the /participants/XXX endpoint on your 30 second intervals furnishing the `if-none-match` header. If you get a 200, then that means something changed (you'll get a 304 if nothing has changed), you can subsequently compare `participant.sumDonations` with your previous iterations `participant.sumDonations`. If the values aren't equal, you know there are new donations to fetch, otherwise, you dont even need to bother polling /donations. The ancillary benefit of this route, is that you don't have to assume a refresh (and subsequently the parsing/rendering overhead) of your assets on every polling interval. Hope this helps, Tim
  3. Interesting. Can you confirm that you're hitting the API via https? You *must* use https to make calls to the Public API. If that's not it, I might need some actual code to look at. Do you have a repo for this anywhere?
  4. Hey @djotaku, Can you share the endpoint and request headers you're furnishing with your call? Thanks!
  5. Greetings, @Alex Lewis! That is indeed the case right now, since the API is exclusively public and we consider that a "private" field to the fundraiser. We're working on adding support for authenticated requests to the API, but there's nothing firm with regards to a timetable. Sorry for the inconvenience (for now), Tim
  6. Ok. Are you still seeing the issue? Can you clear your browser cache, including cookies for the Extra Life site?
  7. Hi, @Zosoled, we're upgrading the certificate soon. It should be done well before Google flags it. Thanks!
  8. @Zosoled, right now the JSON endpoints are simple analogies for non-JSON equivalents (you can see this by removing the &format=json from your request). We're evaluating ways to make the API experience better, and having more semantic endpoints is high up on the list of things to investigate. We'll be sharing planned changes once we've finalized our approach. In the meantime, keep the ideas coming!
  9. great questions @deliciousbees. re: rate limit - the rationale/thinking was that for integrations pulling recent information, the most 100 records within a 60-second period would be the most relevant for the use cases we're seeing in the wild (showing recent donors on twitch). we don't strictly enforce rate-limits on API consumption - if you're doing an initial population of data, then it'd be fine to grab those records sequentially after each previous request completes. the issue would be doing that as part of every fetch, every 60 seconds. re: the pagination - the goal was to furnish the most relevant information in a format that was as easy-to-consume fashion as possible. pagination will affect a small minority of fundraisers, and was a necessary function of consolidating all team-member donations inside the now-relevant "team donations" endpoint. additionally, as @Matt [DonorDrive] mentioned in the other thread: we're now including a timestamp down to the millisecond with each record we pass back. this should satisfy requirements for identifying uniqueness at the participant and team level. we're actively looking into ways to make this information more-useful to people that want to integrate, so any additional feedback/concerns/questions would be most welcome. cheers!
  10. @bread_man, welcome to the discussion! I've been talking with @Zosoled about latency in some of the JSON endpoints. I believe we've tracked down the culprit, so updates to the participant and team totals should be happening more quickly. The caching mechanisms in place are entirely server-based, so client-based cache-busting strategies wont help you. We're actively monitoring the API cache, and are making adjustments as needed to ensure a smooth experience for consumers of the JSON-formatted pages. Thanks!
  11. @Zosoled, you are absolutely correct. We do make a server-side delineation between XHR and requests made to the EL website. That being said, if you're experiencing persistent 5+ minute delays in updates to the &format=json endpoints, then there is something on our end that may require additional investigation. I'll dig in and see what I can find. In the meantime, would you mind describing which endpoints you use, and for what purposes? There may be other ways to slice your requests that result in a better experience. Cheers!
  12. @Zosoled the latency you're seeing is a function of the cache mechanisms in place. Depending on current request volume, it may take a couple minutes for the totalRaisedAmount you're accessing via XHR to reflect the amount you see in your browser. We are always working on ways to improve the experience and responsiveness of DonorDrive. We value your feedback, and will do our best to make sure your game day experience is top-notch. A friendly reminder that responsible JSON consumers poll a given endpoint once-a-minute at most. Thanks! P.S. Double-thanks for answering @heartandthesynapse's question!
  • Create New...