Why does the sdk create the Analytics instance right in the source code

[duannx]

The SDK creates an Analytics object right in the source code like that:

const instance = new Analytics();

It leads to the code will be run immediately when the SDK is imported into the source code. I think it is an anti-pattern because the code runs without user awareness.

Example: running the SDK on a Vuejs SSR app. The SDK currently is not universal (Nodejs friendly) so it can not be run in the SSR context. The SSR will break whenever we import the SDK. The solution is to dynamic import the SDK on the client side. But it will lead to other problems like another separate chunk, difficulty when typing for the wrapper that dynamic imports the SDK...

[gitcommitshow]

I do not fully understand the suggestion here. Can you share the code sample for your SSR app and point out the issue there?

[duannx]

@gitcommitshow You just need to import the SDK in the Nodejs environment:

import RudderAnalytics from 'rudder-sdk-js'
export const AnalyticsWrapper = {
  track: RudderAnalytics.track,
}

The Nodejs will throw the error: ReferenceError: window is not defined. The reason as I said above is that the Rudderstack SDK automatically creates an Analytics object right in the source code. That runs sub-sequence code what uses the window object.

[gitcommitshow]

Got it. I guess, you already understand following but mentioning here for the clarity

1. rudder-sdk-js is a client-side library and built with the purpose of being used in browsers
2. For server-side tracking(sending events from the node backend), you should use rudder-sdk-node
3. For server-side rendering, you can follow this guide on GoogleAnalytics OR this guide by Gatsby on loading client-side only packages during SSR (although these guides are for react, but the principles remain the same)
4. We need to brainstorm on how to refactor the rudder-sdk-js code to make sure that it works in context of SSR without the need of any additional changes as per above point no. 3 (@duannx if you know how to do this, would you mind creating a PR?)

[duannx]

Thank you for understanding.

I've already found a workaround. It is using the dynamic import on the client side only. But it has some tradeoffs as I mentioned above. So refactoring the JS SDK is still needed. I would love to work on it. But a PR now is too early. We should decide the way of refactoring first.

My suggestion is to follow this rule strictly: Definition only, don't execute anything. As a library, we should provide the definition only, not the execution. And the developer who uses the library should have the right to decide where to execute it. The SDK should look like this:

// Just pure definition
export class Analytics {
   constructor(){
      ...
   }
   track(){}
   identify(){}
}

When using the package, the developer will decide when to execute it like this:

import Analytics from 'rudder-sdk-js'
if (isOnTheClientSide) {
   // The window object will be valid here
   const analytics = new Analytics()
   analytics.load(...)
}

The segmentio/analytics-next is a good example.

[gitcommitshow]

Looks like a good plan to me. Let's get more opinions on this.
@saikumarrs what do you think?

[saikumarrs]

With multiple work disruptions, I couldn't find enough time last week to look into this. I'll share my thoughts as soon as possible.

[saikumarrs]

Firstly, apologies for the delay.
@duannx Thanks for highlighting this. The suggestion you made makes sense and offers more flexibility to the SDK users. However, it might be a breaking change for the existing users and hence needs careful execution.

There is a plan in the pipeline for a significant code refactor and change the way SDK is served, but it may not happen very soon. We'll scope this out as part of that and address it accordingly.
CC @bardisg

Again, thanks for bringing this to our notice.

[duannx]

@saikumarrs I agreed. Could you please share the roadmap of rudder-sdk-js?

[saikumarrs]

@duannx, I've totally missed your response. Apologies for that.
Unfortunately, we do not yet have a public-facing roadmap for the JS SDK. However, I can assure you that we are aware of such issues and have bigger plans to execute in the coming quarters. We'll let everyone know once the time is right.