Large Rollup build bundle size for @gomomento/sdk-web

[DomDerrien]

I use Vite + Rollup to bundle my webapp.

The impact of the @gomomento/sdk-web is more that 1.6 MB after minification. The heaviest part is all the code related to the prptpbug handling, with the interface definitions for the serialization over the wire.

Hopefully I load it asynchronously with:

const { CredentialProvider, TopicClient, TopicConfigurations, TopicSubscribeResponse } = await import('@gomomento/sdk-web');

To help the tree shaking process, I would like to be able to do 4 dynamic imports:

const { CredentialProvider } = await import('@gomomento/sdk-web/dist/src/topic-client.js');
const { TopicClient } = await import('@gomomento/sdk-web/dist/src/config/topic-configurations.js');
const { TopicConfigurations } = await import('@gomomento/sdk-core/dist/src/messages/responses/enums/topics');
const { TopicSubscribeResponse } = await import('@gomomento/sdk-core/dist/src/auth/credential-provider.js');

However, the code of topic-client.js starts with a import {...} from "'";, the barel file I want to avoid!

Here is the beginning of the topic-client.js file (source]:

import {TopicConfiguration, TopicConfigurations} from '.';
import {PubsubClient} from './internal/pubsub-client';
import {TopicClientProps} from './topic-client-props';
import {AbstractTopicClient} from '@gomomento/sdk-core/dist/src/internal/clients/pubsub/AbstractTopicClient';
import {WebhookClient} from './internal/webhook-client';
import {TopicClientAllProps} from './internal/topic-client-all-props';
import {getDefaultCredentialProvider} from '@gomomento/sdk-core';

You can see that it's a inconsistent with the inclusion of two barel files ("." for "sdk-web" and "sdk-core"). while the definition for AbstractTopicClient is loaded from the file where it is defined.

Would it possible that import statements are tuned in both the sdk-web and sdk-code? That should help reducing the weight of the library.

If you go further and tackle sdk, Lambda function users will be happy too (see issue #1478).

Additionally, I would like you to look at replace the old google-protobuf library by something like protobuf-es 😉