3 Comments


  1. It’s awesome that TechCrunch are giving back to the platform they use and open sourcing this plugin. Sites with massive traffic like TechCrunch need to solve different problems to the average website so it always great to be able to see how others tackle theses issues.

    It’s something that we try to do at our agency whenever we can, and in some cases we were able to commit code that was developed on bigger projects back into popular plugins that were used.

    Reply

  2. I’ve been trying to think of use cases for this library.

    I agree with non-blocking and running heavy lifting tasks in the backend, rather than on the fly in the template etc.

    Unless the heavy lifting was directly connected to the action, ie, after save_post you need to do some stuff.. but for example of polling an API for something on the front end, this isn’t the nicest way to do it. IE save_post could be sporadic, and you’d obviously not want to do admin_init, etc.. as it’d be way too much.

    To date we just setup external crons that do heavy lifting and pre-populate transients, etc, so it’s super fast for the template to grab the data it needs.

    Reply
    1. John P. Bloch

      Generally, I agree. Suffice it to say that, for some things, cron simply wasn’t a viable solution for us. Additionally, this allowed us to refresh ONLY the data we needed to refresh.

      With traffic like TechCrunch’s, getting a lock for the task on a front end page load is indeed a challenge. We’ve used the object cache to do it in some cases, which (if done right) only results in a couple of duplicate processes. In the end, though, 2 extra processes is much preferable to tacking on up to 30 seconds for the API request.

      Also, the majority of our uses of the library are actually on hooks like save_post. Alex and Nico just wanted to show off uses that visitors can actually see on the front end. ;)

      Reply

Leave a Reply