This doesn't add any complexity on the backend since the LISTEN/NOTIFY mechanism is baked by default with first service (which is a simple REST server). But yes, on the frontend it adds its layer of complexity.
Why we need LISTEN/NOTIFY ? Because it is needed to plug other services like a log service, a webhooks service, or anything else. All those services are actually needed in the system, but for simplicity it is better to separate them from the base service since they are not needed to run the first layer.
In relation to the pub/sub service, it is indeed icing on the cake and could be completely removed from the stack. At first, I wanted it to have consistency in cache data hosted by the clients (which come from the REST service). This is needed to support offline connectivity for the mobile application mostly. But, in reality, offline connectivity is really hard to build and, IMHO, offline-first is a chimera. The only way to do it well is by caching the data when it's requested by the user iteratively (and not all at once). Because of that, it is impossible to foresee what data the user will need when its device becomes offline and the only way to have access to the right data is by improving the UX of the application so the user is responsible of what he'll need and must retrieve the relevant data beforehand.
When I first analyse the pub/sub service, I wasn't aware of this. But now that I'm thinking this through it seems this service does not meet any real need. It is just cool to have data automatically updated on clients when someone modifies it. And developing something that is just cool to have but at the price of hundred hours of work, well... Why bother :D
I'm replying here to your both comments ;)
This doesn't add any complexity on the backend since the LISTEN/NOTIFY mechanism is baked by default with first service (which is a simple REST server). But yes, on the frontend it adds its layer of complexity.
Why we need LISTEN/NOTIFY ? Because it is needed to plug other services like a log service, a webhooks service, or anything else. All those services are actually needed in the system, but for simplicity it is better to separate them from the base service since they are not needed to run the first layer.
In relation to the pub/sub service, it is indeed icing on the cake and could be completely removed from the stack. At first, I wanted it to have consistency in cache data hosted by the clients (which come from the REST service). This is needed to support offline connectivity for the mobile application mostly. But, in reality, offline connectivity is really hard to build and, IMHO, offline-first is a chimera. The only way to do it well is by caching the data when it's requested by the user iteratively (and not all at once). Because of that, it is impossible to foresee what data the user will need when its device becomes offline and the only way to have access to the right data is by improving the UX of the application so the user is responsible of what he'll need and must retrieve the relevant data beforehand.
When I first analyse the pub/sub service, I wasn't aware of this. But now that I'm thinking this through it seems this service does not meet any real need. It is just cool to have data automatically updated on clients when someone modifies it. And developing something that is just cool to have but at the price of hundred hours of work, well... Why bother :D
Hahahahaha, I love the way your brain made its way to a conclusion here ... :D