{"API Evangelist"}

Code Resiliency Lessons In How Twitter Deploys Their Embeddables

I am learning about how Twitter deploys their widgets. Extracting some insight for my research around how we can build change resiliency into our client code. As I'm doing my regular monitoring of the API space I am trying to keep an eye out for any examples from leading providers of how there are investing in client code being more change resilient. This Twitter blog post provides me with three concepts I wanted to add to my research:

These are change elements that seem like they need consideration as we craft our web, mobile, device, visualization, bot, voice, and other types of API clients. These three elements should be present in the code, anywhere I'm making an API call. Being able to reverse how I'm interacting with an API, the incremental release of new API paths or changes to existing APIs, and having an analytics layer can contribute to helping us deal with change.

I think I am going to get started with an analytics layer for my own client code. Start thinking about logging the calls I'm making to any API I depend on. I have this in place for the server side of the APIs that I manage but do not have any sort of logging at the client level. Not only do I not have any plan for change at the client layer, I might not even know there was a change because I do not have any visibility.