Discussion around hooks / event broadcasting

[Mike S]

First off, I wanted to say awesome job to the entire team behind Service Weaver. It's a very exciting and promising project and I really admire the approach, design and philosophy. I'm looking forward to seeing how the project evolves over time.

In a lot of modular frameworks that I've used (non-distributed), modules/components have the ability to broadcast events to any other components that may be interested in reacting; and those components can hook in to any event defined in the system. This allows for improved modularity because it reduces coupling and allows for modules to easily be removed, swapped, etc, in situations where there isn't a direct dependency required. This is especially true in producer/consumer scenarios.

Taking the online store example from the repo, the checkout service directly requires and calls the email service in order to email the customer after the order is processed. The shipping service is also required and called. You could make the argument that neither should be required in order to place an order - and the amount of components that have to react to an order can just continue to grow (or shrink); and perhaps the checkout shouldn't even be aware of what happens to the order after it creates it. For example, if the email service is going to either be removed or supplemented with a text message notification, the checkout service should not need to be altered or even know the details of that. Rather, in a framework that supports hooks/events, a "new order" event would be emitted and components such as shipping and notifications can listen and react.

There is a downside to this - it's much less explicit and somewhat hidden behind the scenes. It makes it harder to understand the flow of execution. And the other obvious argument, especially in a distributed system, is to use something like PubSub to broadcast these events; which makes perfect sense. But, I was curious to hear your thoughts about this. Since the framework has full understanding of all of the components and controls the communication between them, perhaps adding support for "subscribing" or hooking in to events that other components decide to emit would not be too hard to support; that is, if it makes sense to include a feature like this.

Thanks,
Mike

[Srdjan Petrovic]

Hi Mike,

Thank you for your email and your thoughts on the benefits of the event-driven model. At Google, both models are used and we definitely don't have a preference for one model over the other. In the Online Boutique example you mentioned, the email and shipping services could be implemented using asynchronous events just the way you described. (And it may be a better idea in fact.)

We went with RPCs because they are more performant and for that reason probably better suited for real-time serving systems. We don't mention this on our website, but the framework is likely best suited for those systems, because of its failure model and focus on performance. But we're not that opinionated about this, and I think frameworks like Dapr can be used in conjunction with Service Weaver. I think, however, that it is too early for us to add event-driven communication as a core feature to the framework.

Thanks again for writing.

-Srdjan

[Mike S]

Hey Srdjan,

Thanks for responding. I completely understand that it's too early and possibly not a good fit for this framework. I was just curious to hear your thoughts about it.

To elaborate some more, what I had in mind would still be RPC and not exactly event-driven, though it would seem that way. The framework could abstract those details. Let's say the checkout service declares that it supports an event, NewOrder, possibly in the config, type or Init(). The shipping and notification services declare that, if available, they want to listen for NewOrder and provide their callback for it. The framework is able to make this connection. In the checkout service, after the order is created, it calls something like weaver.DispatchEvent(NewOrder, orderData), and the framework knows which services it needs to call and pass orderData too; which can be done asynchronously. So in the end, the calls are the same, it's just the framework that stitches it together for you and your checkout service never needs to be aware of who's interested in what it is doing.

It's just an idea to provide a different way of achieving ultimately the same thing, but perhaps allows for more/different modularity.

Thanks again