The Hidden Production Risks of Third-Party SDKs

Most modern applications do not function completely independently. For example, analytics, payment processing, user authentication, customer support, testing new features (experimentation), monitoring the app's performance, advertising, etc., are typically provided as third-party SDKs that enable those functions in your app.

Using an SDK has its benefits; you don't have to build an entire piece of functionality yourself. When using an SDK, developers can download the software library, call the initialization method, then begin calling the API methods of the SDK to use its functionality.

import { analytics } from "third-party-sdk";

analytics.track("checkout_started", {

  productId: "123"

});

In some cases, the amount of code required to add this type of functionality can be as little as a handful of lines of code. If the same functionality was built "from scratch", the time required could potentially be several weeks.

However, with great convenience comes hidden complexity. The moment you allow a third-party SDK to run in your app, how well it performs and works (performance, reliability, security, and user experience) depends on what amounts to "someone else" doing something to your app. That is why third-party SDKs are important dependencies that affect how well your app will perform during production hours, instead of just being another library or module to include.

SDKs Can Quietly Affect Performance

The biggest reason front-end SDKs will show performance issues is that they typically run directly in your web browser. If you install a typical analytics SDK, it adds to your front-end bundle, it loads on page init, and then registers event handlers, makes requests over the internet, etc., as soon as there are interactions with your app.

Although one SDK alone has little effect, if you use multiple SDKs for analytics, experimentation, customer service, session replay, ad tracking, and monitoring, your users will likely notice a difference. Therefore, teams need to evaluate whether individual "acceptable" SDK costs can compound into overall user-perceived degradation.

In addition to measuring the cost of each SDK individually, teams need to look at the overall cost of loading the SDK(s), which can include:

• Bundled size
• Time to initialize
• Network requests
• Activity on main thread
• Overall impact on Core Web Vitals

This cost can be reduced by loading non-critical SDKs asynchronously or after the main application experience has loaded.

A Third-Party Failure Can Become Your Failure

Consider an application that will render the main page after initializing a recommendation SDK.

await recommendationSDK.initialize();

renderApplication();

If the third-party service has an issue, your application's overall appearance may slow or become unavailable, even if your backend is functioning properly.

Thus creating unneeded coupling.

Generally speaking, non-essential third-party services should be allowed to fail without affecting the primary user experience. For example, if you're unable to receive recommended products, you should still be able to browse through products; if analytics are failing, checkout should still function as normal; and if a support widget is unable to load, all other aspects of the webpage should continue to function normally.

Applications should define clear fallback behavior for every external dependency.

Timeouts are also important. Waiting indefinitely for a third-party service can turn a small external outage into a much larger product incident.

SDK Updates Can Change Production Behavior

Engineers typically spend considerable time evaluating large-scale framework updates; however, they may be less concerned about small third-party dependencies that make up much of their application codebase.

This could potentially lead to issues.

An SDK update can change how an application initializes, the format for making requests, which browsers an application supports, the default configuration, how data is stored, or how much JavaScript is downloaded during each session. Even if the public API hasn't changed, runtime behavior may still differ based on previous SDK versions.

Therefore, dependency upgrades should follow standard engineering controls such as version pinning where applicable; automated testing; dependency review; and gradual deployment. The idea of automatically allowing all new SDK releases into production just because they have been classified as minor will create additional risk.

Third-Party Code Expands the Security Boundary

Every new SDK you add to your app will be a larger portion of all code making up the system.

Browser apps make this especially important when SDKs can access page content, browser storage, cookies, user interaction, or even application data.

You should know exactly which pieces of information will go out to an outside party. As an example, sending off an entire object to an analytics SDK could provide more information than was ever intended:

analytics.track("profile_updated", user);

Some of the fields in the 'user' object might never have been intended for analytics.

A safer approach is to explicitly select the information required for the event.

analytics.track("profile_updated", {

  accountType: user.accountType

});

You'd be better off sending only the data you need for each specific event.

The principle is simple: third-party integrations should receive only the data they actually need.

SDKs Can Create Hidden Runtime Conflicts

Not all third-party SDKs run independently. In addition to other actions such as modifying a browser's global objects, registering event handlers, intercepting web requests, and manipulating the DOM, third-party SDKs may also create new dependency conflicts that are incompatible with your current application code.

Because of their nature, these issues can be difficult to reproduce because they typically depend on specific conditions (such as browser type, user environment, feature flags/feature toggle configuration, etc.) that cause them to occur only under very specific circumstances.

Another reason why you should track correlation of failures to your integrations during production time is due to this.

Also, when possible, initialize third-party SDKs in an isolated manner so that an error in initializing one service does not bring down the rest of the application.

try {

  await supportSDK.initialize();

} catch (error) {

  logError("Support SDK initialization failed", error);

}

If your optional service fails to start, then your application continues.

Have an Exit Strategy

The other, quite surprising, issue you might have when using an SDK is the difficulty in removing it.

When there are numerous API calls in multiple layers of your app, making changes to which vendor you use as a service provider becomes extremely expensive.

In this case, teams may want to develop their own internal abstraction layer on top of the external SDK.

tracking.track("checkout_started", data);

Your application interacts with an internal 'tracking' interface, and then the internal tracking layer will interact with the external SDK. You still have a dependency on the vendor, but now all vendor-specific APIs are abstracted out of your codebase.

Testing also becomes simpler, and you can easily add validation, filtering, error handling, and fallback logic.

Monitor SDKs Like Production Dependencies

Integrations with third-party tools should look similar in your observability dashboard as your internal services.

Understanding when/why an SDK will fail; how long initialization takes; whether requests are timing out; and which specific integration(s) cause frontend errors/performance regressions helps teams understand when they have a problem. It is also beneficial to understand what feature of your application depends on each provider. This type of information greatly assists during an incident by providing a clear yes/no answer to an important question: Can I disable this integration and still run my core product? For critical integrations, the answer should already exist before an outage occurs.

Conclusion

Third-party SDKs are useful because they enable engineering teams to get things done in less time than would be required if the team had to build capability again, which has been developed by others who specialize in that area of development.

However, when you add a new SDK to your project, you've added a new production dependency.

This dependency can negatively affect your application's performance, reveal information about your application, break at unpredictable times, change with each upgrade, and ultimately become very hard to remove as it spreads across your codebase.

Our objective is not to eliminate third-party SDKs. Our goal is to intentionally incorporate third-party SDKs into the project.

Track how much performance is affected, track what amount of data is transmitted back to the provider, prevent failures from spreading through isolation, maintain control over upgrades, track the use of the service, and do everything possible to prevent tightly coupling core functionality to a service that the application does not control.

A third-party SDK may take only a few minutes to install, but its production impact can last for years.