Avoid having all integrations in the same package

[danielgomezrico]

Current

We add integration with things like amplitude, firebase and so on and that requires that the dependency is added on each platform like this:

• Android: https://github.com/la-haus/flutter-segment/blob/master/android/build.gradle#L38
• iOS: https://github.com/la-haus/flutter-segment/blob/master/ios/flutter_segment.podspec#L19

PRs related to this:

• feat: add option to activate native integration with appsflyer #19
• Firebase Integration #48
• Mixpanel integration #15
• Facebook App Events Integration #54
• MoEngage integration #63

This makes that the effort made by the Segment team to avoid having a big library and instead adding the dependencies you need on your project pretty bad.

Expected

Somehow if I should be able to include the dependencies I need for each platform and just those.

[ariefwijaya]

This is needed because one of the benefits of the segment is as a portal to all CRMs. Maybe cloud mode doesn't need this, but not device mode.

[b099l3]

Just seen the MoEngage PR and I was also looking into integrating Adjust, this is a repeating problem. @danielgomezrico Sorry for the delay. I have been thinking about this a lot and how we would architect it. I believe we have these issues to address:

Architecture:

I had the idea that we would need the following:

1. A core package that

• keeps all the standard segment calls:
• Starts Segment and adds the other integrations (some registry that looks for the integration packages added)

2. Packages for each of the integrations, Firebase, AppsFlyer, etc

I got stuck trying to work out how we could build a registry... until I watched a talk on federated plugins at Droidcon 2022, and I realised that the FlutterFire plugin has a similar set-up. We could copy that pattern by filling in our registry.

I will use iOS as an example to highlight how this would work, but there are Android and other platforms. If we look at the core package:

• It has FLTFirebasePluginRegistry that plugins register to using e.g. example of the remote config:

 [[FLTFirebasePluginRegistry sharedInstance] registerFirebasePlugin:instance];

We could potentially get away with something like this on the native side if we can get access to the config object, native setup of the firebase integration:

[config use:[SEGFirebaseIntegrationFactory instance]];

The Integrations Plugin would do this code.

I have started a small proof of concept with Melos but will try to get something working to show how this could work. It would mean we could house multiple packages in this Repo and publish them separately. And if someone wanted another repo they could create their own that wraps the native implementation, we could then do federated plugins.

Other non-related issues that we should consider

I can separate these into other issues if needed, but I wanted to raise this here to see what you thought

Melos

Move to use Melos or something to help with multi-package repos, it could also help us structure and have a concise release log, etc. This would mean we could have a mono repo with some of the packages and be able to release them separately. E.g. see the FlutterFire repo. That is not to say we couldn't have federated plugins or something similar.

Pigeon

Move to use Pigeon for inter-language mapping. Still determining how much of this we will be doing, but if we start to get more, we should consider adopting Pigeon.

Integration setup

We should move away from using a bool to enable plugins
Using bools like isAmplitudeIntegrationEnabled is going to limit us

Newer native segment packages

From researching, I noticed that we depend on analytics-ios, last updated 05 Oct 2021, over a year ago 😬. They also mention migrating over in their docs
Both analytics-kotlin / analytics-swift seem to be updated more often. We should move to the newer native segment packages, as it looks like this is the way Segment is going. Maybe not for this change, but it should be our next priority as they are not supporting it anymore.

Sorry for the long post but I wanted to get this out of my head 🤯😂 WDYT?

[danielgomezrico]

Thanks for those ideas @b099l3, this is an excellent starting point to resolve the issue.

We are sorry but as a company this month this got a low priority, and we need to ultra focus on other things, we will come back in a month or so to continue with it :)