I actually haven’t kept up with the latest variant that also includes Coroutines and the ViewModelScope. Previously, the Repository had the purpose of providing the reactive data resource which the ViewModel would cache. Here is a practical example: https://stackoverflow.com/a/59109512/2413303

In this case, the moment you have a second MutableLiveData for a different Firebase Query, you could create a FirebaseResource that would be a LiveData<T>. So Repository would be wrapping the configuration and instantiation of this lifecycle-bound datasource. But that’s primarily because you don’t have a Room DAO that would do the same thing for you in its generated code.

I might have a slightly more interesting answer once I go through what comes of launchWhenStarted and the viewModelScope when it stops being beta. But I have a feeling that’s for online-first approach where there is no reactivity to manage, so no need for repository in that case. We’ll see later.