Why you should consider building 1 unified SDK for all your APIs

The key topics covered in this video

• [00:00] What do we mean by Unified SDKs vs. Separate SDKs?
• [01:47] What should an Organization consider when deciding on the direction for their SDK program?
• [04:50] Does this decision impact SDK maintenance cost ?
• [06:10] Real-life examples of Separate and Unified SDKs
• [07:04] Case Study: Verizon 5G Edge APIs

Introduction

In this edition of API Conversations, we delve into how companies with extensive API portfolios approach building SDKs. 
When thinking about how customers will consume their APIs, teams need to decide whether to create a unified SDK for all APIs or maintain separate SDKs for each. Knowing what factors to consider when faced with this decision can make the job of API Owners relatively easy. 

Let's start with an example to clarify what we mean by a unified SDK. Imagine you have an Orders API for ordering products and a Payments API for processing payments. Since users integrating with the Orders API will also need the Payments API, it makes sense to bundle these into a single SDK. This unified SDK approach brings related APIs into a single, easily consumable package, simplifying the integration process for developers.

Key Considerations When deciding between a ‘Unified’ or ‘Separate’ SDK approach

Consumer Usage Patterns: Begin by understanding how your consumers use your APIs. If there's significant overlap in the functionalities your APIs offer or the user personas, a unified SDK might be beneficial. This approach ensures a seamless experience for users who need to integrate with multiple APIs.

API Requirements: Organizations often acquire different APIs through mergers and acquisitions, leading to a diverse set of functional and non-functional requirements across APIs, such as security considerations. These differences need careful consideration before deciding to bundle APIs into a single SDK. You do not want to bundle a highly secure API that requires users to go through a rigorous KYC process with APIs that have much more relaxed security requirements.

API Size and Complexity: Consider the complexity and size of your APIs. Bundling multiple large APIs into one SDK can result in a complex and unwieldy package. If developers only need a few APIs from a massive SDK, this can be inefficient.

Installation and Performance Constraints: Evaluate the overall installation size and potential performance impacts. If memory or performance is a concern for your API Consumers’ use cases, such as applications that need to run on embedded systems or small edge devices, separate SDKs may offer better flexibility, allowing developers to pick and choose the specific SDKs they need.

SDK Maintenance and Operational Challenges: Maintaining SDKs is another critical aspect to consider. Developing and supporting multiple SDKs across different programming languages involves significant operational overhead. This includes building, testing, publishing, versioning, and updating each SDK. If your organization lacks the resources to manage this complexity, a unified SDK might be a helpful compromise.

Industry Examples

Unified SDKs: Microsoft Graph SDKs are a prime example, bundling various services within the Microsoft 365 ecosystem—such as Teams, Calendar, and Email—into a single SDK. This approach works well for Microsoft due to the integrated nature of these services.

Separate SDKs: Twilio offers separate client SDKs for its voice, video, and conversation services. This separation aligns with the distinct use cases and user needs for each service.

Case Study: Verizon's 5G Edge SDK

Verizon recently launched SDKs for their 5g Edge API’s with APIMatic. 
This product line consists of 15 different APIs managed by various engineering teams within Verizon. 
Most Verizon customers use more than one of these APIs, hence the team needed a unified SDK and Documentation site to streamline the developer experience of their Consumers. APIMatic's API merging capability allowed us to automatically merge the 15 different OpenAPI that describe each of these APIs into a single, conflict-free SDK for six different programming languages.
You can view the SDKs and Documentation here.