Event Bus pattern

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hi there and welcome back. We are continuing our season of looking at software architecture patterns and anti-patterns. We've gone through quite a few. We can continue focusing first on patterns. In this episode, we're going to look at the Event Bus pattern. Now, that may sound very familiar if you've done Android development because Event Bus is a major part of the Android system. But it is also one that shows up in general notification and event style problems as a solution. And by notification and event style, I mean things where you have things going on and other things need to react to those things that go on. Now, you can do stuff like we've, you know, priorly we talked about a peer-to-peer network. Well, one of the problems with a peer-to-peer network would be if there's too many things going on, too many changes, you can flood and crash the network. The Event Bus is an attempt to take a smarter approach to that. And typically there are, really in the pattern, there are three main players in this. And that's sources, the bus itself, and then there's listeners. And then within the bus, there are going to be different channels. And the way they work, it works is sources published to a channel and then listeners listen to channels. So it's almost like a software newsfeed is that you have things that go on and in some way they are posted, you know, a message or something like that. And the message may be an actual message. It may be data. It could be just about anything. It's put into a channel. And then there's listeners out there that say, hey, anything that goes to this channel I want to know about. So it could be for as simple as like, you know, are our services up or down? Is there a change that's gone on? Much like, you know, this is where we look at the peer-to-peer. If you think of a graphical environment, maybe like say there's a button in a graphical environment and it gets disabled or actually, better yet, let's say it gets clicked. So somewhere, something needs to know that that button got clicked. And it's not necessarily that click is going to go to every process that cares because it's just too unwieldy to do so. Instead, what's going to happen is that click message is going to go to, let's say the button click channel. And then anything that cares about that button click, which may be the panel that it's on, the page that it's on, some sort of overall operating system, listener or some sort of smarts behind that, may be listening for that channel. So when the button is clicked, everybody that cares about it, because they've said, I care about it, I want to hear what happens with that button, then can react to it. And this may be things like a button click and then there's layers of controls underneath it. And so there's some sort of a, you know, the listeners are there and there's something that says, hey, if somebody else hasn't listened to it or if somebody else hasn't taken care of it and there may be some sort of a, like a grading scale or something like that, or maybe when one listener comes on, it essentially boots another listener. That's a little tougher to do. That's not your standard event bus. Because typically what happens is the channels are just there. It's like, think of it as like a table in a room and sources can go in and put stuff on the table and listeners can come by and see what's on the table and maybe do something based on that. That's not normally and shouldn't be, it's not going to be a cue. So it's not like a source comes in and puts a pie on the table and then a listener comes in and picks that pie up. Instead, what it may do is it may, it's more like a message or something like that where it isn't a single use. It's not a cue. So it's not like you're like popping it off and saying, okay, I'm going to take this and do something with it and nobody else can. This is, it's there and it stays there. So everybody that cares about it can act on it and can be updated based on that. Now that does point to one of the challenges with the event bus is there has to be some sort of expiration or something like that on the bus. Otherwise, I guess unless you have a lot of storage, what's going to end up happening is channels get filled up. So you do want listeners to essentially, they're going to look at things that have changed since the last time they checked the channel. So it sort of implies that you're going to have some sort of a date stamp, timestamp, something like that to say that, hey, this message, this thing that's in the channel was posted at such and such a time, such and such a date. And then the listeners can look at it and say, oh, I've already grabbed everything in that time date range. I don't have to look at it again. Otherwise you can get duplicates and things of that nature. But that also means that generally speaking, you want to expire stuff out. There's a certain point where you don't want to just keep every message ever, although you could. But again, like in a device, you think about an Android device, it's got its event bus. As those events are being filled out, it may be that when you turn off the device and turn it back on again or turn an application off or back on again, then it clears that channel or maybe the bus itself gets cleared. But typically it'd be like the channel. So maybe a source can, maybe it's set up so that the source can refresh a channel or do something like that or expire a channel so that there's a certain point where every once a listener comes in, they're going to look at a point and say, oh, okay, we've stopped pushing to this channel for now. So you can shut yourself down and come back later or just swing back around until we see data again. But we're clearing stuff out. And if something new comes in, then it's sort of a watershed moment. It's not going to see the older items in the queue. So if a listener's down for a while and comes back, it may be that it, quote, missed some stuff because there's no guarantee delivery or anything like that. It's just, hey, I'm putting it out there on the channel. Anybody that wants to listen to the channel can register to it, say hey, or actually even within that, they're just going to check that channel on a periodic basis, most likely, and then do something about it. Now, typically a listener is pushed updates from the channel. So when there is an update to the channel, it goes to the registered listeners and says, by the way, we have an update. And that allows them to grab that data. It may even push it, but typically it's not going to. It's just going to say, hey, we have an update. And that way all the listeners can check the channel and grab that updated information. And of course, this becomes a very efficient way to send updates to only things that care. And when you think about that peer-to-peer network, when we talked about the information flood that you have an update, it updates everything because in peer-to-peer, every peer assumes that it cares about every other peer. This is a situation where that's not necessarily the case. You may have multiple processes going on that don't care about certain channels. Typical application, you can see stuff like that based on the layers. So there are things that go on on the network piece of an application that the UI doesn't care about. Things that go on the UI that the network doesn't care about. Things that go on in the file system or persistence piece layer that the UI and the network don't care about. So you have these events, you have these things going on and these messages, and only the care about it will actually register and say, hey, I want to hear about that. Think about it again like a news feed. If you go out and look at a typical, like an RSS reader, you can go in and select whichever RSS feed you want to get information from. And all the others that are out there, there's still pumping information. There's still stuff going on out there. You're not going to see it because you don't care. And that's basically what the event bus gives you is these things, these sources are publishing to the event bus. Even if there's zero listeners, they're still going to publish to it, which may be another problem is it why you publish if there's no listener. But nevertheless, that's really not the concern of the pattern. It's just something that as a designer, you want to make sure that you're checking on those such things in some way so that you're not putting more into the event bus than needs to be put into. You know, why send extra traffic across the network that is effectively useless? And then these things go into the channels and then as one, five, five million listeners can check that channel and they're going to get notified and say, hey, there's an update. All right. It can be a passive kind of thing where they're just they're checking on a regular basis, but then they're not really listeners. It's more of a it's more of like a ping that they're going to go on every so often and say, hey, is there an update? Hey, is there an update? Not quite the same as listeners because with a truly defined pattern, that channel has got a list of listeners. And so when it gets updated, it sends something out to each of them and says, hey, by the way, we have a new update. Go ahead and do what you want with it. And that brings us back around to the overall design of this pattern. Actually pretty straightforward. You just have to have something that event bus, you have to have this channel that a source knows how to essentially contact or message or place a message within the channel. Then the channels and it may be those channels just exist. So there may need to be some way for sources to get a library of channels and say, oh, these are the channels I want to post to. And then there's the listeners that are going to be able to see what channels are there and say, oh, these are the channels I want to get a hold of potentially. Now maybe as you see in events very often, there are events that are fired off all the time that go into an event bus, an event channel of some sort. And then you have listeners or not that can deal with it. So for example, you may not, you may have a button and certain environments like Android, you can have a button that you can click all day and it does nothing because nothing's actually listening to it. Or at least nothing that you know of because it's just going click, click, click, click. It's filling that up. There's no listeners. So nothing happens. Now it can grow to a very large solution, but it can also be rather straightforward. So it's something that you may use. And often you're going to see it in like message queue systems and things like that because they are built to essentially have that kind of a message kind of support. Granted you're going to pop stuff off, but in a message queue you don't have to. And so you can't, or at least most of them, so you can treat it as an event bus and have all of the infrastructure, the foundational pieces for that pretty much in place. So it's just a matter of almost like a push and a pop and you're off and running with your own event bus. And I think that's it for this pattern. It's another one of these, it's like peer to peer, it's very well documented. There's a lot of examples out of there, out there. A lot of how to's and things of that nature. And this includes things like existing event buses, like the Android bus and how to interact with it and things of that nature. So this is one of those patterns that you may not have even realized was a pattern because it's just so pervasive depending on what kinds of tools that you work with, environments and software that you build. So basically, as the name implies, event bus, if you deal with user interfaces and events that are event handling within that or notification type systems where there's events and then there has to be a notification, then you probably have run into this many, many times. So we'll go ahead and wrap this one up again, another sort of straightforward pattern, which are the best kind. And we'll come back next time and just continue chopping away at these things. But until then, have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. There are two things I want to mention to help you get a little further along in your embracing of the content of Develop-a-Nor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Develop-a-Nor site. You can also find it on Amazon, search for Rob Rodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week. And this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at Develop-a-Nor dot com if you would like more information. Now go out there and have yourself a great one.