Yes this will be heavy on database if you have a lot of publications going on.

Fair enough.

Instead of a full refetch on the client, I think you could still efficiently retrieve any missed changes to state since you last lost connection. For example, if your Messages are cursor based, you can just check for any new Messages after the cursor on reconnect — which is really not so different from what you’re suggesting.

I think you make a good point about db/system structure in something like WhatsApp in that it’s more event powered than just some classic db model architecture. I’d probably alter the GraphQL models a decent bit to homogenize any updates associated with a Group instead of just having Messages.

I think we’re converging on very similar organization for something like WhatsApp, and your PR adds convenience to making that setup happen by letting the saving get triggered by a publish method instead of say in the resolver of the mutation. In the case of a creation event, like a new Message, I don’t think I’d want to store both a new Message and a separate Publication event — really just one sorta GroupEvent that happens to be a Message. I’d prefer one source of truth (one db/state model) to represent what’s going on in the app — both for efficiency and also because I fear inevitably running into issues where states become inconsistent.

What do you think?