Should we be sending all CFDs through the projection feed on every update?

[luckysori]

I suppose this was done on purpose to keep the client simpler, but does this have an impact on performance?

The same observation applies to our offer and quote feeds.

[da-kami]

The simple answer: No

I would propose a pattern, where we don't send data over the update feed, but only tell the UI that something changed, and the UI can then decide what data is to be loaded.
I think this will result in a more efficient user interface and experience, because the UI (i.e. the consumer) decides what is needed according to what is displayed. This allows adding e.g. pagination in a simple way.
However, it will require somewhat more code, because we will have to add endpoints to fetch data.

For offer and quote I would apply the same principle, but it is not as critical because there is no ever growing list of quotes/offers.

[luckysori]

@da-kami: Could you open a ticket to reflect your proposal? We may not want to tackle this any time soon, but it would be good to document this good idea.

[da-kami]

I created #2906 - @klochowicz if you don't agree feel free to dispute the ticket :)

[klochowicz]

as a perhaps simpler solution that would have a dramatic improvement on performance I would like to propose sending only open CFDs on the feed on every update.
There's no reason we're sending the closed ones again as they will never change; moreover, it is very likely that the user will not care about them unless they want to dig in the history (we could even postpone fetching them until then, but of course that's an UX trade-off).

[da-kami]

We could do that as an in between solution, but I generally think that it would be better to stop sending updates over the feed. I think the UI should be able to decide what it needs based on what is displayed. If we detach knowing when to update from fetching data we are more flexible in choosing what data is to be loaded - we can keep this simple and load e.g. all open ones via an endpoint initially, but can optimize it later. I think we should be able to do this quite fast.