You'll hate my answer, but here it is - it depends on the use case.
While syncing with the server, you generally, want to achieve two things:
- have the latest data state at all paries as soon as possible (server, client)
- have the smallest number of requests and transferred data
To achieve this, you must familiarize yourself with your business requirements, i.e.:
- how often your data changes?
- do you need to support offline mode?
- what data is crucial for correct usage?
- will users be happier with old data but served immediately or it's crucial to show only fresh data?
- who depends on user-generated content and what is thair tolerance time for fresh data?
For example, if your app needs to support offline mode and there are some actions that are relying on some data available, you'll probably need to fetch all that data at soon as possible.
For other apps, that do not have those kinds of sensibility - it's an overkill and bad usage of resources.
So, the decision of when to sync data is a business decision more than a technical one. If I were you, I would require those answers from the product owner, and only after that, you can start thinking about technical implementation.
Very often, in the fear of looking bad or not skilfull enough, we programmers avoid asking crucial questions from our business teams and instead search for those answers in design patterns, practices, etc. But patterns are useful only after we know the business case.
