Store the user stats like followers, subscribers in the socialStatsHistory after they sign up

[SrijithRad]

This issue resulted after the discussion on how the stat history should work. #48

Issue

• The user after signed up, has data in two collections namely user and userSocial. The former stores the token and other details whereas the latter stores the followers, subscribers counts.
• To show the percentage up or down on the stats, we need to store the history for which a new collection called socialStatsHistory would be created and a cloud function would fetch data for this collection on a timely basis e.g. 24 hours
• The issue is that userSocial's data and socialStatsHistory data is almost the same. There is data duplication and doing complex queries in the future would require to join the two collections

Solution (Proposed)

• Get rid of userSocial
• Move the profilePic to user
• When a user signs up, now we create the user data and the socialStatsHistory data.
• The first document in the socialStatsHistory data would thus be populated
• Easy to do any queries in the future
• Cloud function would keep inserting new records into the socialStatsHistory on a schedule

@eddiejaoude @VenkatVenkatesh

[eddiejaoude]

Yes they would be similar, but I still think the userSocial would be useful to store the latest information, to make querying for the dashboard easier.

For example when a new entry goes into socialStatsHistory, the information for the dashboard (followers/changes...) can be calculated once rather than each time the page is loaded.

So the dashboard stats is calculated on write not read. What do you think?

[SrijithRad]

Makes sense. Good with whichever is easier. So, we would be still keeping the userSocial but storing the latest information there. Everytime something goes into userStatsHistory, it also updates the userSocial record.

[VenkatVenkatesh]

Yes they would be similar, but I still think the userSocial would be useful to store the latest information, to make querying for the dashboard easier.

For example when a new entry goes into socialStatsHistory, the information for the dashboard (followers/changes...) can be calculated once rather than each time the page is loaded.

So the dashboard stats is calculated on write not read. What do you think?

Could you please elaborate more on this @eddiejaoude ? Should the stats for the cards in the dashboard should be fetched from userSocial instead of socialStatsHistory? And use the socialStatsHistory for the charts and graphs?

[SrijithRad]

Yes they would be similar, but I still think the userSocial would be useful to store the latest information, to make querying for the dashboard easier.
For example when a new entry goes into socialStatsHistory, the information for the dashboard (followers/changes...) can be calculated once rather than each time the page is loaded.

So the dashboard stats is calculated on write not read. What do you think?

Could you please elaborate more on this @eddiejaoude ? Should the stats for the cards in the dashboard should be fetched from userSocial instead of socialStatsHistory? And use the socialStatsHistory for the charts and graphs?

That's correct. Atleast from my understanding

[eddiejaoude]

From my understanding also 😂 👍

[VenkatVenkatesh]

@eddiejaoude @SrijithRad Here is the normalised JSON for socialStatsHistory
{ provider: "", userId: "", followers: 0, following: 0, repos?: 0, tweets:?: 0, createdAt: "" }

Please let me know if I have missed any fields.

[eddiejaoude]

I think we only need the common data between all the platforms

socialStatsHistory

{ 
   userId: "", 
   provider: "", 
   username: "",
   followers: 0, 
   following: 0, 
   createdAt: "" 
}

Note: What about the actual change in users who follow/unfollow? Will that be added in later?

@VenkatVenkatesh @SrijithRad what do you think?

[VenkatVenkatesh]

yes @eddiejaoude . Will modify and add the rest of the properties when we work on #26