How to organize an application?

Question

Angular

Good day.
I am writing an application in AngularJS.
On the NodeJS backend, communication with the server occurs exclusively through socket.io (except for authorization).
I am interested in the question of how best to build the application architecture on AngularJS, if, for example, when updating some model, when I receive data from the server, I need to display various Notifications.
The situation is the following. The application has methods for updating some model, for example, a project. The project has some fields, like a name, creation date and an array of people who participate in it. There are methods that update the fields of the model and there is a separate method that adds participants to the project, but this method, in addition to this, also creates a user.
I'm hanging on an event like projectUpdated. If I changed, for example, the name in some method, I need to write to the user that the project has been updated. And if I add a new participant to the project, I also get the projectUpdated event, because it is generated by the same method on the server, but I need to write to the user that the participant has been added. There is no problem in this, but in this case I will write 2 messages to the user, and that the project has been updated and that the participant has been added.
So the problem is, either refuse to notify the user about such things at all, because this will already affect the presentation and he will visually see it, or come up with something with it.
It seems that he managed to form his own thought.
Upd: It seems to me somehow wrong to generate different events for "each sneeze". Or I'm wrong?
Thank you!

Answer 1

If we are only talking about how to tell the application that something has happened, for example, some kind of notification has arrived, then the easiest way is to use events through $rootScope.
Forcibly pushing changes from the server to the client is not a very good idea, it is better to notify that something has happened and then just take the data with a request from the client. How you organize the event hierarchy is up to you, it's up to the backend. Let's say an event like ProjectUpdated does not make sense, since it does not characterize this event. But MemberJoined is already the norm, you can essentially inherit from ProjectUpdated and thus create some kind of hierarchy. But there really shouldn't be two events for one action, just the events should be meaningful.
You can simply send an event to the client and add its type. Then there will be one listener and then it will all be sorted out in the application.
Well, yes, ideally, your application should know little about how to work with socket-io and how you generally interact with the server, that is, everything that has to do with sending / receiving data should be encapsulated in services.
Further without specifics is difficult.