Evolving the Microsoft Graph SDKs
In the few months I have been part of the Microsoft Graph team I have heard a number of community members express a sentiment about client SDKs that I have heard before. People are concerned about their value and the potential negative effects of using them. This is not a conversation that is unique to the Microsoft Graph. For several years the API community has been having the conversation as to whether SDKs do more harm than good.
Time to first call
Proponents of client SDKs for HTTP APIs will cite the importance of how quickly developers can make their first call to your API as a metric of success. It is true that we developers have little patience for APIs that are challenging to get started with. We all have deadlines. We just want to get the data and get on with delivering value for our customers. Well designed SDKs should make calling an API trivially easy.
Unfortunately, sometimes in order to achieve “trivially easy” we hide certain inherent complexities of making network calls to remote systems. Those details may not be important when it comes to getting to that first call. However, building a complex commercial application, that adds signifiant value to Microsoft 365, can’t necessarily afford to ignore those very same details.
Efficient, Fast and Resilient
Many experienced developers believe the convenience layers of SDKs bring with them the risk of obscuring what is actually going over the wire. They believe that in order to efficiently use the API, it is important for developers to understand the details of the HTTP request. Those details are often important, and developers sometimes need all the knobs and switches to fine tune their requests.
Having your cake and eating it too
Both perspectives are valid. However, by introducing some architectural seams into the SDK, it is possible to provide convenience layers that, when necessary, can be peeled away to provide access to the raw HTTP interaction. This can be done whilst still providing significant value to even the most experienced developers.
Way more than models
SDKs are commonly perceived as little more than a set of methods that send objects over the wire and return a response object. This vastly underestimates the capabilities of HTTP. You can control the way network requests are made, how failed requests are handled and how HTTP clients adapt to new behavior. Some developers choose to pass on the Graph SDKs and simply use Authentication libraries like MSAL or ADAL to handle token creation. However, with the Graph SDKs we are building middleware infrastructure to make integrating the MSAL libraries more transparent. The new content classes will make dealing with Graph payloads simpler and more robust. We have lots of opportunity to deliver value.
Evolution is our goal
In the coming months we will work to evolve our current SDKs to support more usage scenarios, by enabling more components to be opt-in and opt-out as your needs require. It is our goal to continue providing the simplest onboarding experience possible, but also be a library that every developer uses when building applications for the Microsoft Graph, because there is no value to our partners writing code that every partner needs. This is the work we need to do.
Light
Dark