search

Medialist / medialist-app

Mission: Increase PR team productivity 10x
0 stars 1 forks source link

QUESTION - handling subscriptions #283

Open richsilv opened 8 years ago

richsilv commented 8 years ago

There is a broad open question around handling subscriptions. In general, we would be parsimonious with subscriptions, tying them to template such that they get automatically stopped when the template is destroyed. This minimises server load as well as avoiding memory-leaks on the client.

Given the nature of Medialist, there is an argument for large subscriptions to remain open in the background as:

  1. The user base is somewhat predictable.
  2. Sessions are likely to remain open for a long period of time.
  3. Publications are identical across users (or at least they could be).

This could clearly make sense for the Medialists collection, and is clearly not appropriate for the Posts collection, but what about the stuff in between (i.e. Contacts).

Is there an argument for sending all contacts to the client on login? After initial load, the app would be snappy (and avoid problems like #282 ). Server load would be minimised as the publication would be duplicated across all users. However, there is obviously an upper limit on the collection size for which this is feasible, otherwise the data requirement would be prohibitive. Is it worth doing some load testing to work out where this number is?

Thoughts welcome.

OllyGilbert commented 8 years ago

@richsilv really appreciate your considered thoughts on this. My inclination is that we should be subscribing to all contacts so the app is nice a snappy. It would be interesting now know where the upper limit on the collection size lies. First deployments aren't likely to go over 1000 contacts, but this number will increase quickly as the app is deployed to larger PR teams.

OllyGilbert commented 8 years ago

@olizilla @alanshaw what are your thoughts?

alanshaw commented 8 years ago

I'd be cautious of spending too much time on this until it becomes an obvious problem. We could quite easily subscribe to the first n medialists and contacts globally, but it might be better to subscribe to favourite or most recent medialists in terms of UI snappyness - temporal locality and all that jazz.

That said, subscribing to favourites might have a negative effect on scalability....My point is, if there are obvious easy performance wins then we should probably take them, but we should aim to do any significant optimisation work when (or ideally just before) it becomes an issue.