fix: add cache disabling option

[isekovanic]

CLA

• I have signed the Stream CLA (required).
• Code changes are tested

Description of the changes, What, Why and How?

Fixes the issues mentioned in this Zendesk ticket.

Mainly, this flag is meant to be used for a very niche' usecase of the LLC when it's used purely as a REST API on the backend. The issue boils down to a couple of things:

• For performance reasons, we often do caching of various heavy operations/entities within the LLC (such as channels, polls and similar) in order to be able to look already seen things quickly
• This works well in principle, however if used on the backend it can quickly increase the LLC's memory and likely crash any pod it's being run on

As an example - let us say that we have 10000 users and each user has 5 distinct channels (some group ones, maybe some direct messaging channels etc.). The first time one of these users runs queryChannels towards the custom backend (which in turn runs client.queryChannels), the entities will end up in both client.activeChannels and client.configs until the pod is restarted.

On the client side app this works fine because you physically would not be able to query through so many channels given a userId.

Provided below is a quick summary on why it's okay to do this in a REST API setting:

• The only place where client.activeChannels is being used in this setting is here, the rest are either WS event handlers or state dispatchers (none of which we need given the constraints)
• The client.configs object is only really used to get a channel configuration in the client-side SDKs, in the case of a REST API they can use the config returned from the HTTP request
• The pollCache is something we do not need on the server-side, as again we have other ways to get a poll (and it also comes baked in its own messages)

Changelog

[github-actions]

Size Change: +601 B (+0.13%)

Total Size: 467 kB

Filename	Size	Change
dist/browser.es.js	102 kB	+121 B (+0.12%)
dist/browser.full-bundle.min.js	57.3 kB	+112 B (+0.2%)
dist/browser.js	103 kB	+124 B (+0.12%)
dist/index.es.js	102 kB	+121 B (+0.12%)
dist/index.js	103 kB	+123 B (+0.12%)

_{compressed-size-action}

[MartinCupela]

@isekovanic Is it possible that due to Channel._checkIsInitialized some methods interacting with the BE will not work? (channel.sendEvent, channel.deleteReaction, ...)

[isekovanic]

@MartinCupela I would say no, since the channel instances do exist and are returned adequately - it's just the cache that is not being populated - meaning the channel itself should be initialized as it should if they watch() it (which is typically not something done on the BE as far as I know).

I think that might also be out of scope of the constraints we give to the flag, since this is really only meant to be used as a REST API.

What do you think ?

[MartinCupela]

I realized that the check for being initialized is looking into whether the client is running server-side, so should be ok.

[szuperaz]

@isekovanic I think a nice test for this PR would be to run the chat QA tests - the test use both a client-side client and a server-side client as well (code) - but I assume you don't yet have a chat backend set up locally

[isekovanic]

I do not, no @szuperaz - would be happy to though

[szuperaz]

@isekovanic did you check that we don't add references here: https://github.com/GetStream/stream-chat-js/blob/master/src/client_state.ts#L14-L16 - this is new to me as well, so I might be missing something, but following source code it seems possible that we'll store data even if cache is disabled

[szuperaz]

@isekovanic I went through all activeChannels references and checked if we read from them without null checks. I found two places (it's very much possible you can't reach these without WS connection, still, I think it's better to add null checks everywhere):

• https://github.com/GetStream/stream-chat-js/blob/master/src/client.ts#L1224
• https://github.com/GetStream/stream-chat-js/blob/fix/add-cache-disabling-option/src/client.ts#L1986

[MartinCupela]

@isekovanic I think we should also make sure that client.mutedChannels and client.mutedUsers are not populated server-side. WDYT?

[isekovanic]

@szuperaz sounds good, will do that !

@MartinCupela saw those too, however they only every updated through WS events, which we consider out of scope for this. I could add the flag for brevity but would prefer to not touch too many of these places at once if you don't mind

[szuperaz]

PR for chat QA test update: https://github.com/GetStream/chat/pull/7890

[MartinCupela]

I am wandering whether it makes sense to even have client.state when the client is initialized with cache disabled. But that would probably be a breaking change right?

[isekovanic]

Not necessarily a breaking change, but I guess it's safer this way for now - I guess it's better to have it there in case the client.state is extended at some point with other things so that we don't have to revisit the stuff here.

[MartinCupela]

Why do we even have a attribute called state that keeps user cache only 🤦 .

[isekovanic]

No idea either :D Hadn't fiddled with it before sadly, hence why it took me a while to reverse engineer everything here