An Integration in the RudderStack platform is a package including the client-side (Software Development Kit) enhancements as well as server-side (transformer) additions required in order to support a new Destination (analytics/digital marketing/CRM platform or enterprise system).
RudderStack SDKs (web/mobile/server) help developers capture business events within their enterprise systems and route them to the RudderStack Server. The messages sent from the SDK client to the RudderStack Server follows a canonical model and is independent of the programming language or the source platform. The source engine of the RudderStack Server is message-agnostic and performs resilient but optimized routing functions. The transformers are responsible for the final mapping from canonical message to destination-specific semantics.
Given the above high-level distribution of responsibilities among the various elements in the RudderStack data pipeline, it might first appear that incorporation of a new Integration should involve only the development of a transformer since the canonical payload that would undergo the transformation would already be part of the existing SDK. However, such is not the case due to a few underlying reasons:
Most of the Destination platforms provide their own SDKs. While the RudderStack Server relies on the Destination to offer some means of server-to-server communication, such communication support might not always be there and/or might not provide 100% coverage of the functionalities offered by the platform SDK. In such cases, the RudderStack SDK has to rely on the Platform SDK to support the messages not addressed as part of the platform's server-side APIs.
Certain platforms (especially those focused on attribution) rely on establishing a cross-device identifier for delivering actionable insight. Such an identifier is typically generated by proprietary systems within the platform that leverage cross-references gleaned from various other sources. In order to integrate with such platforms, RudderStack depends on leveraging the platform SDK for establishing the identifier
In certain cases, the platform SDK captures events over and above its advertised APIs and in such cases, the RudderStack SDK has no option but to include the platform SDK
The following sections familiarize you with the RudderStack SDK components and then delve into the details of enhancing the SDKs.
RudderStack SDKs have the following two components:
The Core SDK provides APIs that application developers need to use in order to route business events via the RudderStack platform. Apart from routing events to the RudderStack BE, the core SDK also implements a Factory pattern wherein the concrete implementations are the wrappers for the supported platform SDKs.
The Integration sub-component is a combination of the wrapper implementation and the actual platform SDK which the wrapper adapts to RudderStack framework.
Inclusion of a platform at development time can be controlled by including/excluding the corresponding integration sub-component in the Build. The core SDK prepares an inventory of the supported integration modules and includes only those in the Factory calls. Using this approach, the application size can be restricted to include only required components.
Even after an integration component has been included in Build, its usage at runtime can still be controlled through appropriate server-side configurations which the client SDK downloads and uses. Using this approach developers can turn on or off - a direct flow of events to the destination.