Thank you for your kind words and great question!
Yes, you are 100% right, I tried to keep the examples as simple as possible. And you are right, there are many different scenarios and possibilities.
Let me start by saying that even in a provided example, there are plenty of options that affect how we would build the real-life application. For example, Comments can be considered as a separate business domain and have their own API endpoint, or they can be delivered as sub-domain/sub-resource of the Article. That’s a business-related question. Or, do we have a limited amount of comments that can be loaded once, or should we think about pagination of some sort? That’s more the realm of technical details, maybe with a flavor of business rules too. And there a many others!
However, this architecture is flexible enough to support these scenarios. It’s just a matter of adjunction and extension. And we don’t have to put anything in the Store if there is no value in that. As you aptly noticed, Store is just an implementation detail and can be skipped.
Consider this file. This is a Vue plugin which we used to inject Service provider into the Vue components. It allows them to work with Services directly, without a Store. I would defer this decision to those who will consume the data and keep options open as long as possible (which is usually a good idea from an architectural point of view). Each consumer will decide, depending on their situation, whether they need to store data globally or if a local state is enough.
I would argue, however, against a unified interface. And I reason that behavior and data flow is different in case of using Store vs. accessing Service directly. And this difference is significant enough to keep them separate.
Would love to hear your thoughts, thank you!