Jon (00:02.49) Hey there, welcome back finally to another Gone Mobile. Although you might be listening to this one after we've got back to the regular cadence, we missed a week there. Kinda. Well. Allan Ritchie (00:11.218) Kind of. I don't think people are going to know. We're just winging over an episode. no, you forgot to release last week, didn't you? Jon (00:16.698) I did. Yeah. Well, I mean, yeah, I forgot slash, hurt my, hurt my butt and, didn't feel like doing a whole lot. Could barely sit on the couch. yeah. Yeah. I'm even more cranky now. And probably the video won't go out for this one yet. Cause it turns out like a while back where, you know, it's like, let's start going to YouTube and video editing is hard. It's, it's not super easy compared to the. Allan Ritchie (00:26.098) Yeah, John's getting old. John's getting old. That's why people want to listen to us because we're old and cranky, right? Jon (00:45.626) audio but we'll figure it out one day. It's just I haven't haven't got there yet but otherwise you would be able to see that I'm I'm higher up than I was because my desk is now standing mode because I can't sit down. Allan Ritchie (00:57.424) There's so many jokes we could make, but we'll let this one go for now and let people use their imaginations. Jon (01:00.282) Yeah. Jon (01:05.53) Wow, it all has to do with the pool. That's the season right now. Allan Ritchie (01:09.424) Yeah. So John is back from Disney. So he's, he's a little brain drained and as usual, we are going to wing and wallet drained. You just got a whole bunch of toy stills. You get a whole bunch of cool stuff yesterday. Jon (01:13.366) Yeah. Mm -hmm. And wallet drained. Yeah, it's just at Disney. Well, no. Yeah, I mean, that was unfortunate timing. Kids' iPads stopped working. Allan Ritchie (01:28.463) Yeah, okay. Unfortunate. No, they were still working. You just wanted the new ones. Which I understand. Jon (01:34.394) No, the one, the one didn't work anymore. And then like I said, I was not about to get one on USB -C and then not get the other one that way. All I have left now is my wife's phone to get to USB -C and then no more lightning cables. Like I can just put them all in my drawer for my own use and then everything else in the house is just USB -C. Allan Ritchie (01:53.199) you're holding out for the flip phone, aren't you? Because otherwise she would already have your iPhone 15. But since the sixteens are coming. Jon (01:55.802) Yeah, maybe, maybe. Well, yeah, I was going to say I have to, I'm not going to go that route until there's something newer to get, right? To upgrade to. I'm not going to get another 15 and just, you know, skip that opportunity. Allan Ritchie (02:11.023) That's fair. That's fair. I'm waiting for my flip phone. I refuse to get a new phone until Apple gives me a flip. Jon (02:17.114) The problem is that I see rumors again too that they're going to make next year, like this upgrade will be fine, you know, incremental. And then like the next year is going to be the, the new design again, or like, you know, form factor changes. So we'll see. Allan Ritchie (02:32.046) Gotcha. Gotcha. I'm gonna get, I can keep open. I can keep open. So what are we talking about today? Am I, I'm gonna, I'm gonna tell you. All right. So today we are going to talk about some architectural patterns. Some of the stuff, I mean, I've seen it all. I'm not sure how much you've seen John, but I've seen the wheel invented. Jon (02:36.026) Yeah. Yeah. Jon (02:40.474) You tell me. Jon (02:51.226) It's, I just say that it's almost as exciting of a topic as going to Disney was exciting. Allan Ritchie (02:58.541) yeah, you like this one, do you? Jon (02:59.866) No, no. Well, I mean, yeah, yes, yes, I do. I did. That's what I'm saying. This is less exciting. Sorry. It's a little bit more dry architectural patterns. I mean, so we got to make it not dry. Allan Ritchie (03:02.764) You're supposed to like Disney. Allan Ritchie (03:07.244) Just, okay, the scholastics. Okay. Yeah, cause yeah, well, speaking of dry, John did not go for either of my suggestions for Disney, just for, for those that know John, he's. Jon (03:19.834) I thought you were going to say speaking of dry, something to do with falling in the pool and breaking my tailbone. Allan Ritchie (03:24.717) No, but that, you know, that's up there, but you, you went to Disney and did not buy a lightsaber. You resisted like the, no, no. Jon (03:27.482) Okay. Jon (03:32.314) We have droids. We got two droids. The kids each built a droid. I got, I didn't actually get this t -shirt there, but it's, I looked, I looked for something to bring home. I wasn't going to do the lightsaber because you know. Allan Ritchie (03:37.804) Okay, all right, let's just start. Allan Ritchie (03:45.26) because I suggested it so he fought it. And then I also suggested he get Mickey ears because you have to go to Disney and pick a custom Mickey ears. And I harassed him. I harassed him constantly every day. I would find some way to swing and did you get Mickey ears? Jon (03:47.738) Exactly. Jon (03:52.826) I... Jon (04:01.114) Yeah, you'd even have other people harass me on your behalf. Allan Ritchie (04:03.756) Yeah, I had, I had, listen, I didn't pull the big card. I only had Maddie bug you. But I was at the portion of just like bugging Shane and getting Maddie and David to ask the entire team to text you at the same time on the same day. And I was like, it's going a little too far. Maybe. Jon (04:19.386) No, the, the move to Matt, to get Maddie to do it was, was perfect. Cause like, she's like, I get a text and we're, I don't know, walking around Hollywood studios or something. no, we weren't even, we were in the plane still. I was on the plane or waiting for the plane. So you almost should have waited until I was in a park that would have been, been even more, you know, like, what's going on? And that's so all of a sudden I get a text from, from Maddie. That's like, John, are you around? It's really urgent. you know, got a big problem. I'm just like, Allan Ritchie (04:29.931) You hadn't even left yet. Yeah. Jon (04:48.89) Allan Ritchie (04:49.388) Now she eased off a bit. She's stuff I told her you said you had to keep your foot on the pedal. Right? It was like it's you kind of said it was minor but like you should have just like right on foot right on his throat. Jon (04:54.394) Hehehehe Jon (05:01.562) No, but I, I, I think my, unexcitable nature, you know, helped keep things at bay too. Cause I'm just like, yeah, I'm sitting here waiting for a flight. What's up? Like just fully expecting some, you know, high priority incident thing coming in or whatever. Allan Ritchie (05:15.371) Fire. Well, it was high priority and you still didn't get the bloody years. So pretty disappointing. Jon (05:23.098) So I'll tell you what, I looked after I was very resistant and I thought it would be funny if I did finally find some and just like casually took a picture and threw some on. But I wanted ones that were like not horrible that maybe I could at least put up in my backdrop after. And I couldn't find any that I liked, so didn't do it. Allan Ritchie (05:40.298) Yeah. Allan Ritchie (05:45.097) Anyhow, now we get to talk about architecture. Hopefully you're more exciting about this stuff than you are about your Disney purchases. Hopefully. Jon (05:52.066) Can I buy some architecture? Can I buy some patterns? Allan Ritchie (05:57.641) you probably can you probably i don't know can you Jon (06:01.306) So, I don't know. So when you say architectural patterns, that's a pretty broad topic. Where do you wanna dial in here first? Allan Ritchie (06:08.713) Well, I usually like to start with the main stuff because we've talked about MVVM and we've talked a lot about XAML. So this episode doesn't focus on the XAML so much, more about the stuff that connects the dots because the architecture doesn't really need to matter the UI. Everybody's so big on the UI, they forget how their applications are architected. Jon (06:14.938) Yeah. Jon (06:19.322) Mm -hmm. Allan Ritchie (06:29.609) It's like they just put, they, they just kinda, this, this sounds what Microsoft wants us to do today. They go and follow the basics and then they outgrow it. No offense, John. And you know, I, I, I know I, I beat up on some of that. Well, Maui, what's that Maui pattern I beat up on. shell. There we go. Let's see. Yeah. Okay. So anyhow, we'll talk today about some architecture and how we can kind of build those things in. So like MVVM, MVU, I think we've kind of covered those, not so much the MVU, but. Jon (06:51.866) yeah. Yeah, I mean, yeah. Jon (07:05.626) Yeah. I mean, we've probably covered some of that. The one thing that kind of always comes to mind whenever this conversation comes up for my, myself and my own experience and use of it, like, and actually it kind of has come up a little bit more in the Maui implementation itself. So like one of the big challenges that I keep seeing with MVVM and maybe it's, it's not necessarily the pattern itself. It's maybe how we've implemented the pattern. is like we ran into another case where we're kind of seeing like when, when a control gets created, you have bindings to things like the, let's take the text, the font, for instance, you might have a text color, you might have a font family and you might have a font size, right? And so with MVVM, what we kind of do behind the scenes is every time, you know, one of those values changes, we map it to what it should do to the platform specific control, right? Allan Ritchie (07:48.038) Okay. Jon (08:05.114) And in the case of font, some platforms might have like, when you set the font color, you actually need to go like update one big property that encompasses all of those different things like the font size, font color, font family, right? And so what's happening is when you get those bindings set up, like the first time that all of those values fire off, we're gonna like reconstruct the same native thing three different times. when we could have like in a sense, waited and had all of those property changes kind of batch up because we know that they all combine into one thing on the native side anyway. So this is something that we see in in Maui itself, but then also like in my own app, I see a lot of this kind of thing where I have a lot of properties on like my view model that influence other properties or other UI elements. Like I might have, five properties that all kind of influence the, you know, one other property that gets displayed. And so every time one of those changes, it's notifying property changed on that one kind of read only property that, you know, basically formats like a fancy string or something like that with a bunch of different sources of info. And so I see this a lot in my own app where it's like, I have a lot of properties that fire over and over again because of just the way that MVVM and our pattern implementation of that kind of tends to, to lend itself to. I don't know if that makes sense. Is that something you see? Is it something that you work with? Allan Ritchie (09:35.142) No, it does. It's in there constantly. People tend to over broadcast, right? Like without going into... Jon (09:41.978) Well, there's that too. Allan Ritchie (09:43.494) Right? So they, they tend to make like, here's a change, change, change, change, change, change. And all of those are calling, like people really don't understand MVVM truly. Like a lot of people, a lot of devs just go, this is how we notify the UI. But they don't look at it from the sense of, you know, that's going to cause a redraw every time. Why not set your properties and then tell it. Right? So if we look at something like, like react react, I like in this, this manner, because you have to set up a, Jon (10:04.602) Mm -hmm. Allan Ritchie (10:13.399) say, I mean, they've kind of gotten a little bit overboard with how they set state, but you basically call set state and you say this property is now this, this property is now this, and then it triggers the redraw, right? With MVVM, everybody's just doing the boilerplate. or they're doing those, you know, the new coach and stuff with observable properties and they fire that stuff away. They'll change like a hundred properties and they'll be like, Hey, Hey, now we slow. Well, no dude, you just told that screen to redraw like a hundred times. What did you think it was going to do? Right. Jon (10:47.066) But the thing, yeah, and I think the struggle here is it's not always the easiest thing to kind of unwind and figure out how to minimize. Like I'm sure I could do better if I sat for an afternoon in my own app and looked at one of the screens that does this a lot. But it might, it's still not, in some of the cases, super obvious how to kind of make it a lot better. Cause you don't always know like in the case where I talked about the font, like we don't, you don't know if. the, all of those properties are going to change that are related to that one kind of combined property that maps down to the native side. And same thing is true in my own app. Like I might have three different entries that all affect kind of the one value at the end of the day. And some of those entries might affect an intermediate property too. And so it's like, you just end up spamming property changed. And it's, like I said, it's not necessarily the easiest to kind of walk back from. Allan Ritchie (11:42.626) Do you have a performance problem though? Jon (11:45.05) Well, and that's why I haven't really done much about it because generally not really. Allan Ritchie (11:49.955) So that's the key thing, right? You don't have to really tackle down these until you have a performance problem. But like I said, what I do tend to notice is people immediately point the finger instead of looking at their own code. They're usually like, it's a bug here. And it's like, no, dude, you just caused a redraw, you know, a bunch of times because you're not really understanding what you're using. Right. so that's a constant one. And I think I'm kind of starting to see that now. Now, envy you salts it a little bit differently. It's more of kind of a set state. Jon (12:03.098) Yeah. Allan Ritchie (12:20.707) type of setup, but I'm starting to see some of the people complain about that in even their Flutter apps, right? Jon (12:26.234) Yeah. I mean, at the end of the day, like the whole idea with MVU, right. Is, is like immutable state that you keep updating and recreating the UI from, right. Or I guess, you know, in the, in the case of something like a flutter, just, I think just redraws, right? Like what we've looked at with, with Clancy's like comet was kind of trying to do a diff of the visual tree so that when you assign a new state and you reconstruct your UI, you're, you're recreating kind of a shadow copy of it. And then. Allan Ritchie (12:55.715) Shadow DOM. It's very HTML. Jon (12:56.698) Yeah, but then that gets kind of applied to like, well, what's the actual, you know, set of, of controls and stuff that exist in our, our, have instances of them. And, you know, can we diff that enough to only apply the changes where they need to be applied. So the idea there being like, I do all of those property changing things on my, my model on my state. And then I pass in the new final calculated state instead of all these pinning of, of a notified property change events. Allan Ritchie (13:25.667) And it's funny because now you get into the case of what's the slow part there. Is it the fact that I did 10 changes or is it the fact that it's now going and doing this diff? It's funny. It's, it's, there's no right way to solve a problem. That's why you got to look at your architect. I always start by looking at my code first, right? Don't be so quick to be like, this is framework. I can't support it. No, man. No, man. Stop. Look at your stuff. You introduced it at some point, maybe rethink about what you're doing, right? Jon (13:29.882) You're right. Jon (13:35.258) Right. Jon (13:42.586) Mm -hmm. Jon (13:52.89) Yeah. And there's a lot of things that, that people don't do, you know, in terms of, I know we're getting into kind of the technical details of, of XAML a bit here, but in terms of how you set up bindings and stuff, right? Like does every binding need to be a, a one way forever binding? Can it be a one time shot? You know, what single, single shot binding, whatever we call those. So people do some funny things with that too. Allan Ritchie (14:10.083) Meh. Allan Ritchie (14:15.171) Yeah, I have seen that. You know, though, usually, I don't know, even myself, I find that I very, very rarely need to set a one time. Like, because most of the time, like a label, it's only ever going to be one way, right? It's only ever going to be from the source, right? Or Jon (14:24.698) Yeah. Jon (14:30.586) One, one, one. Yeah, it's only going to be one way. Allan Ritchie (14:32.675) So a lot of those default bindings usually help you out, but say something like an entry, if it's read only, should it be one way? I mean, it depends on your use case, right? But there's places where you could make those optimizations, but most of the time, most of the time, you, that's probably not where you need to worry about it. I mean, I might be putting my foot in my mouth, but I feel pretty good about it. Jon (14:43.45) Mm -hmm. Jon (14:54.138) Yeah. No, I think it, yeah, it's, it, I think there's, you know, it's again, it's kind of like, do you want to go to that level of optimization? And if you do, it's there for you. And if not, you're, that's probably not the first place to start making your, your app perform better. Allan Ritchie (15:11.585) Now what's another, I'm kind of leading a witness, but where's another place where you generally tend? So if we get outside of MVVM a little bit, where's a, I mean, you probably get to see some real interesting stuff, some real fun stuff. Where's another area where you tend to see without reading our show notes, John, cause I can see your, I can see you looking over there. what, where's another area where you tend to see things going off the rails in terms of performance, maybe. Jon (15:30.01) Allan Ritchie (15:40.704) Just pure insanity. Jon (15:42.682) Well, there's there's a couple spots often it's and it's when we see like lists of things right so like collection views or even bindable layouts people doing weird stuff with like having an observable collection and You know recreating it every or sorry re emptying it, you know and then filling it again because they they're refreshing the list right but it's like okay if you're gonna do that just use a list and create the new list instead of Allan Ritchie (15:59.391) yeah, that's a good one. Allan Ritchie (16:08.671) Yeah. Jon (16:10.01) using observable collection, which is going to fire off an event every time you add an item and it's just, yeah. Allan Ritchie (16:14.145) People, people don't understand that though. That's a, that's another big case. I, I'm anti observable collection, except for places. I, my usual statement is if your data is not in motion. And what I mean by that is constantly having items, not only added, it doesn't count if you're appending because you can still just append, add range to a list and say the list changed, right? Do that. It's better. But an observable collections where you start, like I use Bluetooth, right? I'm, I'm an extreme. Jon (16:42.17) Right. So like as your devices are coming in and out, right? Like it's a great way to keep them there. Allan Ritchie (16:45.216) Right? Right. And there's going to be multiple threads pinging at it, right? Because I have a timer like Bluetooth, a device doesn't really disappear. It's if you haven't heard from it in X amount of seconds. So I have a timer looping and going, I haven't heard from that in like X amount of seconds, take it off the list. And I have another, I have another thread that's running and saying, If you hear one and it's not on the list, add it or update it, right? So it's constantly in motion. It's moving around. You might be sorting it constantly, right? That's a place where observable collections matter. Otherwise don't use the things. Jon (17:16.442) It makes a lot of sense. Yeah. Allan Ritchie (17:19.742) And the funny thing is, is when you look at it underneath, you guys being Maui have to code it two different ways. You have to be prepared for an innumerable of some type and, or you got to look, is it, is it a notifying property, interface that I also now have to subscribe to and deal with that chaos that's about to happen. Right. So people often go, it's not working with observable collection in say the carousel view. I'm going to pick on that one. Cause I've been dealing with it this week and it's like, okay, well did you need, Jon (17:26.234) Mm -hmm. Jon (17:38.81) Yeah, exactly. Allan Ritchie (17:49.696) an observable collection there. No, you didn't. No, you didn't. Right? So this is the thing, right? Just observing those small things. But where I was going, so John didn't read the show notes. He was trying, he was trying to, I saw him going to look, I guess it's on your other monitor today. that's right. Well, it's, is it? I mean, you've got that big curve, but it's not really, you're focused all in the middle. Jon (17:52.09) No. Jon (18:00.378) Yeah, I gotta read the notes. Jon (18:06.202) Well, it's all one big monitor. Jon (18:14.746) That's pretty good. I like it. It's better than multiple. Allan Ritchie (18:16.925) I might get a G9 again. I might, my first gen sucked, but I'm letting you guinea pig it right now. They just don't have an OLED screen, so I won't convert yet. I'm waiting. Gen five will have it, right? Maybe. Anyhow, going back to my topic here was. Jon (18:24.698) Eh, that's fine. It's fine. Jon (18:30.074) Maybe. I'm at a loss as to where you were trying to lead me here. So, okay. Messaging. Yeah. No, you love messaging and you want everybody to use, you know, Allan Ritchie (18:37.308) Messaging. I hate messenger services. I have hated it. I mean, let's be honest messaging in a server side, like where you're getting into service bus and stuff. Absolutely. In apps. I mean, John, get ready to John bleep me. I Jon (18:55.258) But that's messaging server side, that's using it to segment services running in different processes and stuff usually. I know it doesn't have to be, but yeah. Allan Ritchie (19:05.915) I effing hate it. I hate it. I hate it. I hate the weak messenger. I hate, I hate all of it. Don't use it. That's my opinion again, right? If it works for you, great. But the amount of times I have seen some stuff that I can't look at, see all these grays. This is from people using the messaging service wrong or subscribing to it like 800 different ways in like 500 different places. Jon (19:14.522) Yeah, it's... Jon (19:27.13) Yeah, I was going to say like the one thing, cause I had used it in my app and when I did the whole rearchitecture, I took that stuff all out and, and I noticed when I was using it too, and I knew I was doing this, that it really ends up blending itself to you. like using it more just kind of in the, in just in case instances, which ends up doing more of like the, I might do notify property changes when I receive, you know, a message that. the subscription status changed or something, right? And so now I'm like, because it's so easy to like loosely weekly subscribe to those, I found myself anyway, tending to do that like crazy in the app and in multiple places and just kind of overkill like, well, maybe this needs to know and refresh the UI when that happens. And it's like, well, now I've got even more property changed notifications firing everywhere. So. Allan Ritchie (19:58.139) Yep. Allan Ritchie (20:20.763) Well, and it gets it gets hairy, right? So I've worked with apps that have like, just a tremendous amount of screens and discovering the messages you should be listening to is a pain in the ass. It's a pain in the ass, right? And there's messages flying here. There's multiple messages flying there. You don't know what you should be listening to. It just, it gets out of hand, right? So just do service. Events are fine. I mean, observables are better. We won't get into that. That's not part of today's topic, but events are fine, right? I could have a singleton service with an event delegate on it that I can subscribe to. to and I know because it's it's a strongly type that I need to unsubscribe from it because guess what weak references also don't disappear right away so a lot of the times I'll see what's the first thing you generally tend to see with those is an unsubscribe just in case I had one and a resubscribe every time I'm like first of all it doesn't help anyways because you're unsubscribing from an instance that no longer exists but hey whatever these are kind of the things that go on right Jon (21:12.89) Mm -hmm. Yeah. Allan Ritchie (21:26.425) And so just, just, just link a service as a Singleton and hook that event or pass an action. Right. And there's so many ways to get around it. but at least when you're using a service, right? Like an off service, one, that's one a lot of people like to use is I want to know when. user logged, it's a bad example because I wouldn't use it in a view model. I know a lot of people do, but like a logged in event or a logged out event, right? I might want to hook that and deal with something and then kick the user out of the app, right? but at least I know that that's there cause it's part of the off service. I don't have to inject a messenger service, which is technical. It's not business, right? So I'm now injecting in a technical service. I'm having to go, which message is it? that, that sounds like a message I want, but there's probably variations of it because that's what happens if you don't architect it, right? Jon (22:06.81) Yeah, true. Allan Ritchie (22:18.97) So when you get into stuff like service buses, right? Usually you've got architects that are really strongly on it, but usually in the UI world you have smaller teams. So they just generally tend to get a new guy in there and he just starts creating new messages and it gets out of hand. Right? So I've seen so many bad, I don't think I've ever seen messenger service go particularly well for big apps. Knock on wood. Jon (22:29.594) Yeah. Jon (22:46.042) Yeah, yeah, I think it's almost like the... I had a good comparison. I lost it. But yeah, it's too loosely coupled in a sense, right? Allan Ritchie (22:56.121) Well, and it's braised. And if you've got a bunch of things listening to it, that may not even be on screen, like in a nav stack, they're like, Hey, this is slow. Let's play Maui. It's not Maui. You just sprayed it across four different instances. You didn't unhook it on, on disappearing, et cetera. So that kind of leads into the next thing I've been talking about is, is there's not really any new patterns coming out for, for mobile and apps. And I've been kind of trying to think of something. This is a, this is all idea. This is all theory at the moment, but. Jon (23:00.602) Yeah, yeah. Jon (23:24.378) Mm -hmm. Allan Ritchie (23:25.624) I'm really big on the monolith structures in server side, but I use something that a lot of people go, I hate this. This is another technology people hate as mediators, right? I don't like CQRS. It's, it's overrated, blah, blah. Jon (23:36.81) Give a good example of that pattern in use. Allan Ritchie (23:42.935) a mediator, it's basically, if you take a minimal API, right? And you say this end point, I want it to call this command, right? So it's very service bus oriented, right? So I have commands and I have notifications and or events. So it is a messaging service, but again, it's on the server side. Now what makes it a little bit cooler is that, yes, you'll be sending in messages, but we do that anyways with API's, right? So I get a message in like a create work order or something, create work, create order, right? Those come in, I take that message and I can kind of fling it back in. And then you usually have an mediator service that goes, yeah, I know where that message needs to go. and you put that command in that command does something. You have no idea what it does. It's kind of like a service, but it's more of a, of a handler, like a Maui handler, right? so it gets handled and then it may even shoot out an event, right? So I might have an event called order created, right? So now it's, it went into the process of creating it. Now it's actually been created. You might want to send some emails. You might want to send some, I don't know. Jon (24:33.786) Right. Jon (24:45.818) Mm -hmm. Allan Ritchie (24:55.35) push notification, I don't know, something that's usually the routes I like to go down and they can happen out of proc kind of, you know, relatively speaking, but where mediators happens, a lot of people go that's over engineering on the server, but it's really good at vertically slicing your, your concerns, right? So I can still have this modular monolith, which I know is a niche term right now. Jon (24:57.082) Yeah, sure. Allan Ritchie (25:20.118) And I can say like, this is the section that deals with ordering. And this is the, the section that deals with, you know, my product line, you know, I want to get products and I can have events firing. And when I need to break that sucker up, I can do it, right? I can just take those set of messages and move them over. Jon (25:28.57) Mm -hmm. Allan Ritchie (25:39.061) to another library or even another API if you're doing it really kind of like if you want to get into microservices, that's when you can start to break the beast up, right? So these vertical slices with a mediation. Now, when I bring this back to. Jon (25:53.274) So does that then like the consumer or the thing that's talking to that mediator, is the goal then for it to not essentially then care, I guess where that implementation lives, where it's sliced. Allan Ritchie (26:05.877) Exactly, right? So it's it's very segregated. Jon (26:12.314) Yeah, it's kind of loosely coupled isn't the right thing, but like it's. Allan Ritchie (26:18.007) It's still very much like a messenger. Kind of what it does save you is that branch. You can kind of remove like you generally when we have controllers or even like a view model in Maui. Some of the things I tend to see is now that people are going so heavy on dependency injection is you get service hell. Right. So that controller in your web project you probably inject like I've seen. Jon (26:19.546) It's a separating of that concern, basically. Jon (26:40.09) Yeah. Allan Ritchie (26:48.246) again, too many services. Like I've seen things where people inject like 20 services and most of those are like scoped. So they're being recreated and they may use like four, five of those services in that method. But when you get into commands, right? And, and kind of the mediation. Jon (27:00.698) Yeah. Allan Ritchie (27:07.317) It's because it's like a CQRS, which means like, it's going to be a command. It's going to be a query, whatever. It's very focused. Like this is, this is what this command does. I need to do data. Maybe I need to send an email. So I need two services. Maybe I care about the user. Jon (27:20.666) And you're not injecting in the command, so to speak, right? You're injecting in the mediator that you're talking to instead. So. Allan Ritchie (27:27.508) Well, the mediator is the only thing that gets injected into the controller and then it passes the command and it figures out where that command needs to be routed, right? Just like a web API. It's, it's, it's determining its route. It sends it to a home and then that home can spin itself up and it says, I need data. I need to know, you know, user context info and I'm going to be sending an email. So I need some sort of email service, right? So it's very focused. This is what this thing does. Jon (27:29.914) Yeah. Jon (27:34.49) Mm -hmm. Allan Ritchie (27:55.092) You know, you still get some reuse, but I don't need to worry about how that thing works. Right. Whereas when we get into services, like a, like a service, like, well, let's say we have an eye order service, right? I now need to implement that and everything underneath it, like an ad or remove, et cetera. Right. With messages, it's just kind of flinging it over the fence and somebody figures it out and takes it up. And if they don't, it's like, what the hell is this message? Right. Jon (28:01.434) Mm -hmm. Jon (28:13.53) Right. Allan Ritchie (28:22.068) So it's kind of cool. It's focused. It allows you to break these big APIs out, prevents the service, you know, overrun hell is what I call it. Cause I see that in MVBM too, right? Like some of these. Jon (28:31.546) Yeah. Well, well, and like, and like you're saying, like in cases where, you know, if you're, if you're creating, if those are all like scoped and being recreated all the time, like I look at this, like, is this something that I would apply to, you know, my app where I've got, like, and we've talked about this before too, where, you know, you might have like a common service kind of aggregator, right? Like stuff that you, you, you might have five different services, but you know, you need to inject them almost everywhere. And maybe they're singletons. Anyway, so it's not really for that case as much as you know, the, the case where, I mean, you could use it for that. There's nothing stopping you, but. Allan Ritchie (29:10.26) You could, so I, I've been looking at this cause I, again, I'm starting to see some bigger Maui apps and some stuff brought over from Xamarin forms and they use messaging and messaging gets overrun and you know, they're trying to separate out their projects cause some of these have big features, right? So they'll have like feature sets or libraries, but there's so much interconnection. It's like those modules kind of defeat themselves, right? They just, they can't figure themselves out. Jon (29:26.362) Mm -hmm. Allan Ritchie (29:34.675) something like authorization. I've seen like a login page where it has like a, like a B2C login provider, right? So it's going to open a web view. It's going to use MSAL, whatever. And then they're going to pass in a secure storage server service because they need to store it. Even though secure storage, you know, does it really need to service? Why isn't it just a key value thing? Right? So they get into all these service over hell and I know this is what you guys hate. I know this is what I hate, right? It's when they start to get into these, these, you're not separating the concerns anymore. You're just creating concerns, right? An auth service should just be, I call login. If it happens to open a browser for himself, fine. Whoopie. Jon (30:09.594) Yeah. Jon (30:14.458) Yeah, that's fine. Yeah, I don't need to know the details. Allan Ritchie (30:17.46) I don't care how you save my auth token. In fact, when I'm in a login service, I don't even care about the auth token, man. I don't, what do I need it for? You store it. Yeah. You store it somewhere. I don't care where you store it. If you start in settings and it feels fails a security audit. Well, that's whoever dev that service. I blame you. Right. And now my view model just gets this one service. So preventing the service overrun is pretty important. Jon (30:23.258) Right. Am I logged in? Great. Jon (30:33.337) Yeah, that's that team's problem. Allan Ritchie (30:44.179) But again, as I, as I look at this and I'm, I'm looking at like the message bus being overused and people just building tech instead of building business and abstraction over hell, overrun hell, all that stuff. It's like, is there a way we could apply a good mediator pattern to like a Xamarin or dotnet Maui app? I just called the Xamarin. shit. Sticky. Jon (31:06.746) Xamarin's out of support. What is that? What is a Xamarin? Allan Ritchie (31:10.739) It's out of support, but there's a lot of movement going on for getting people off of it. So it's a busy time. So I've been thinking about this because again, I hate messaging. I will avoid it like the black death. And I hate service overrun. Now there's ways I've gotten around it. I think some people are doing my aggregated service idea now. It's not my idea, but it's what I do as I make like a service of services. Jon (31:13.626) yeah. Yep. Allan Ritchie (31:36.563) and that kind of cuts down on it, but it's still, it's still kind of aggregating a whole whack of stuff that I may not need. Right? So if I have a mediator pattern and again, I'm going back to message discovery, but we can focus it now because we know our whole damn app is built off of these, these commands and notifications. Right? So I can get some logical separation in my app somehow. And blast these messages around. So I've thought about it. The problem is in most apps, most services are singletons and notifications. Well, do I need to spin up an instance of a notification? Because I mean, I use notifications in the backend. So I like shiny obviously has jobs. So I'll be spamming events out of them. If something's happening in the background, right? Jon (32:29.178) Mm -hmm. Allan Ritchie (32:33.65) And I may want to tell those things, Hey, you know, this was just happened, deal with it at some point. Right. So those Singleton events, yeah, they can pick up some, they can pick up that event. Right. So I can spray that notification around all those background services that I have will pick it up, but there's still cases where the view models, which are usually, transient or should be transient and or scoped. Jon (32:51.514) Mm -hmm. Allan Ritchie (33:01.777) Speaking of which, you guys scope it out of the box, right? You have a page. Jon (33:05.466) I'm always fuzzy on how the scoping is. I know that we do some things with scoping. I think maybe it's per page. Yeah. Allan Ritchie (33:09.009) by page. I'm pretty sure it's by page. So now that gets interesting because we want to get rid of the messenger service at that layer. How do we get a notification to them? Right. So this is kind of the some of the stuff I've been kind of toying around with because I want that page to respond to that event if it fires like a log out event. Right. Jon (33:30.682) Yeah, but you should still be able to like if you've got that that auth service as a single, I guess that's what you're saying is you don't have that as a singleton then at that point. Allan Ritchie (33:39.249) So I have to get messages to singletons. That's easy. No problem. But I also have to get messages to these view models that are kind of temporary. As soon as they pop off the stack, I don't want them to respawn and start hooking to that event because they're gone. So I've been looking at ways to do this. Jon (33:43.074) Mm -hmm. Jon (33:48.058) Mm -hmm. Jon (33:54.298) Well, but aren't you just hooking up the event and then unhooking it when they go away, when they disappear? Allan Ritchie (33:59.281) Yeah, but that's a problem. Nobody ever unhooks their damn events properly. And then it leaks memory and no, no, no, we won't even go into that. Right. It's just, it becomes a pain. So I've been looking at ways and it's probably going to get into interface hell at some point, right? Cause I want to listen to 10 different events, maybe rethink your events, but I may have a view model that listens for, Jon (34:01.53) Well, I know. Jon (34:14.778) Mm -hmm. Allan Ritchie (34:22.832) Background sync is a good one because often pages, if you're on like a signal R connection or something, and let's say a piece of data, like I'm looking at a detailed screen of an order and maybe it just got shipped. Jon (34:24.538) Okay. Allan Ritchie (34:35.408) And I don't want to have to go out of the page and come back in and then see the updated data. I'd like to refresh right there. So of course I could pick up an ordered service, hook some sort of event and say, if this particular order updates while I'm on the screen, get the order, redraw the screen, et cetera. Right. But then I also have to unhook it. Jon (34:38.842) Right, and come back in. Yeah. Allan Ritchie (34:57.328) I have to know the services I have to pull in. I have to know the events I have to pick, pull in. But if I just said, look, here's a list of events that we have or notifications we have. And I can mark that, that view model that I'm in with an interface with a message type and say, I want to know about notifications, this type of notification when it comes in. And that may force us me to implement one method, handle this message type and it runs. Jon (35:23.93) So then is your mediator just holding that view model as a weak reference until it goes away? Allan Ritchie (35:30.481) Well, I've been toying around with it. I don't, I'm not going to say I have the answer. I'm kind of throwing this out because it's an interesting idea, right? It's one that I'm somehow determined to get to, right? Because what happens is again, looking at these, these big applications that are multi -modules and more with more modules coming, they're huge, right? But they're, they're all inter bleeding with each other. But if all I have is contracts that are kind of bleeding between them, which is common, like a web API, then I, the implementation, Jon (35:57.242) Mm -hmm. Allan Ritchie (36:00.434) can live where they really truly live right I can say look I I placed an order I don't care who manages it I know there'll only be one order command handler because there can only be one the mediators say no no there's one command handler if you register multiple it errors right off runtime Jon (36:03.098) Mm -hmm. Jon (36:17.978) And then the thing talking to the mediator doesn't even care about any of that. Just like, here you go. Allan Ritchie (36:22.448) Exactly. So that's kind of the things I've been thinking about is how I implement this, how I get those big separation of concerns without service, without overrunning our services with DLL or service overrun hell, but how I still get events to these view models, which kind of live temporarily. So that's stuff I've been playing around with. Jon (36:41.978) Well, and I think the other kind of interesting thing there is like, where do you draw the line in some cases be between, you know, just a plain simple, service and, and using the mediator, right? Like one of the things that occurs to me is you're talking about commands and notifications that might be fairly, it's the word I'm looking for. They're, they're, they're not, Allan Ritchie (36:52.56) Messenger. Jon (37:09.754) bound. So they might be bound to each other in a sense, but maybe they're not even, maybe they're not like a, it's not like I send this one command and I always expect, you know, this, this notification to come back or it might be, I send a command, maybe a notification comes in, maybe three of them come in. but then, Allan Ritchie (37:26.703) Well, with mediator, you can still do request response. So that might be something that's not understood. Jon (37:29.93) right. So, so, and that's where I was kind of getting at this, right? Is like, well, you know, obviously there's syntactic trigger. You can add to any kind of thing like that where maybe I send a request and I, you know, have a task completion source that's waiting for the response. And I, I wait on that or something like that. But, but that is like, there's a lot of kind of infrastructure or ceremony there compared to just an interface with a method on it. So like, so I do think it's interesting to kind of consider like, yeah, where do you do? Allan Ritchie (37:46.319) rate. Jon (37:57.85) Both of those patterns in some sense. Where do you draw the line if you do? Allan Ritchie (38:01.586) When you look at mediators on the server the mediator is usually the only source so the message comes in through your web and the mediators generally your only service that goes into either your minimal API view or your minimal API registration or your controller There's nothing else right so it stops the service hell And then when you go into the command, instead of registering, you know, 10 ,000 services against it, because you know, you only need three, it becomes a focused pattern, which is generally speaking also much easier to unit test, right? Now they still have shared services, right? So when we talk about that secure storage and the opening the web view, right? So I may have a command. This is again theory. I may have a command that says I want to log in the users, the users going to log in. So it goes, I inject a navigation, I inject some, or some sort of cell thing. Let's not get too far into cell for both of our sanity. And I may inject a secure store, right? Who knows? Maybe some other things. Maybe I want to inject some pre validation. I don't know. Jon (38:46.682) Mm -hmm. Allan Ritchie (39:13.617) But at that point, what I can do is I can say, look, these are the two services that come in and I'm going to log them in. So that, that window opens, I await it. User logs in, I get back a token and I go, okay, that token goes to secure storage because I made a service for that for some ungodly reason. and off it goes, right? And then maybe I want to request a profile data later on. I could have a service or I can just say, if I'm looking at proper siloed stuff, I can say, give me profile. And it comes back with, did it get my profile out of secure store? Did it maybe use an API and then put it into secure storage or whatever, right? It becomes these very small, tiny pieces of work. Jon (39:38.106) Mm -hmm. Jon (39:44.57) Yeah, there's a get profile request, right? Jon (39:55.93) It's almost like those are almost like the new microservice kind of thing then in a sense, right? It's like they're very purpose built and inject only the things that you absolutely need for the smallest kind of granularity. Allan Ritchie (40:01.649) Absolutely. Allan Ritchie (40:08.145) And it's, it's funny because it is the point we're talking about a point where is it too much engineering or is it not enough? Right? So I look at these like mediator I use in every app I've got right now because it gives me a good starting point and it makes it very easy to fragment out later. I know some people disagree. That's all right. You're wrong. Do what works for you. Right? I have had a ton of success. I've been using service bus for. Jon (40:15.194) Yeah. Jon (40:24.634) Mm -hmm. Jon (40:28.682) Yeah. Allan Ritchie (40:35.409) seems like a hundred years now, but it just, it works, right? It works for scaling these things out, but I'm back to, I don't want to have 10 ,000 services for an app I'm spinning up today because I don't know what's going to be busy. And just because I build it doesn't mean they're going to come. So when they do come, at least I can break those hotspots out and scale them. And. Jon (40:56.314) I truthfully, I, the, the kind of, I don't want to use the wrong term here, but the super, kind of hyper -focused on aspects of my code, part of myself even likes the idea of this, you know, compared to like the service of services. Like what I have is fine. I have almost all singleton. So like, I don't, I don't necessarily gain much from moving to this pattern for my own use because it's just myself working on the app for one. And. Allan Ritchie (41:22.417) Right. Exactly. Jon (41:26.042) But I kind of like the cleanliness, you know, that part appeals to me in terms of the smell of the code. Allan Ritchie (41:32.176) One, and it's interesting too, because the services services, you're right. It's easy for you. It gets a job done. But even if, if let's say we had something that was working today, I bet you if it's working well and it's not a performance bottleneck and it's pretty easy to understand, you might actually find, Hey, this isn't a bad pattern to use. It makes it small. It prevents me from kind of stabbing myself in the eye with a fork. Right. Hopefully. Jon (41:58.266) Mm -hmm. Allan Ritchie (42:00.175) Because going back to messenger, right? So messaging services don't like at least the ones that we're used to in Maui or, you know, I think the community toolkit has the replacement. You guys have a deprecated one. Forgive my ignorance on it because I don't use it. Jon (42:12.218) Yeah, yeah, yeah, we've moved away from that. Allan Ritchie (42:17.071) So there's a messaging service. There's one in Maui or the community toolkit, right? The thing is they don't have a ton of infrastructure around it. So let's say, you know, we were talking about that message spring. So there's no such thing as command. It's basically here's the message. Who's ever subscribed, you know, here you go, do what you will with it. But what happens if one of those things crashes? What happens if I was stupid, right? Or I just had a bad air. Who knows? Right. But that one errors. what if two of them error? Was it fired sequentially? What if I have a hundred subscribers and you know, it went through because it's not, it's not asynchronous. It's kind of sequential, right? It goes through the queue. Jon (43:00.538) Right. Yeah. Yeah. Yeah. Allan Ritchie (43:01.038) So it gets through 30 of them. One errors, right? It's, and then you're like, well, this thing's slow. Well, no dude, you've got a hundred subscriptions to it. Right. And it doesn't have a fire and forget mechanism, right? Which is another thing that mediators have is I can say, I want to know when all of these events pass or fire and forget. Jon (43:09.914) Yeah. Jon (43:18.106) Mm -hmm. Allan Ritchie (43:21.294) And what's better is that I can actually have, because it's a mediation pattern, I can start building it other patterns like a, like a pipeline. So I want to spray that out to 20 different things. I could still have an error handler that catches an error for each one of those specific events and say, yo dude, this view model guy, because I'm not implementing the view model, your damn thing just aired, but I have a good log, right? Jon (43:46.074) Mm -hmm. Allan Ritchie (43:46.894) So all events fired, but this one view model is failing. It didn't crash the app. We caught it. And now I've got a log of it, right? So this is kind of some of the cool things that I think could lend itself to a Maui app, potentially, potentially. Jon (44:01.722) Now, now what about getting into like the do's or don'ts here? You know, if I've got a command and I've got a handler for that command registered, is this a taboo thing to then make that command handler send another command to the mediator? Is that a anti -pattern? Allan Ritchie (44:20.942) No, no, it's quite common because now... You know, you might send an order, but I need to get maybe shipping information, right? Well, the order doesn't necessarily deal with shipping is a whole other process, right? So you may have those, those vertical slices chunked up, right? You may have another module that deals with shipping exclusively, because the orders, hopefully your orders are getting blasted and your shipping's not, but right. So you can ship those, you can pull those two apart and you can just say, look, this is the weight. This is the package. size. Yeah. Tell me the cost, the estimated cost and I'll feed that back, somewhere, right? So it's not uncommon to have mediators calling around command to command because it's a query now, right? So if we talk about seek your ass, that's the query and you can send a command and the command automatically forces a response. There's something you don't get in service bus. If you ever use, have you ever used the service bus? Jon (44:56.474) And here's the product info for the order. Go tell me. Yeah. Allan Ritchie (45:23.406) That's a service oriented thing. So service bus is very much, you can send it to a message queue. You really shouldn't do request response in those scenarios because it is as asynchronous as it gets, right? You send a message. Jon (45:23.674) I think so. Jon (45:35.546) Right. Yeah, it's kind of like keep keep passing things along and if it comes back to you that way, great. But don't don't wait for it. Allan Ritchie (45:40.142) Yeah, right. Because it's going through message queues and things could fail. And the thing about a message queue is that, well, commands should process right away, but there are cases where you're like, it goes in, it may not respond, right? Because the service on the other end, you don't know it's connected. That's, Jon (45:45.05) Yeah. Jon (45:56.794) Yep. And even if it does, you might know how quickly or not, right? So. Allan Ritchie (46:01.55) It could be busy. It may not have been scaled. Who knows? It's not even worth going down. But in this case, it's mediator. We know it's local. That's why it's mediator, not service bus or service oriented. I think there's a play here to make it available to Maui somehow. And if we do this, we get rid of, so we have those commands, we have the mediators, we have these little services. We have the separation. If we can get the temporary view models to respond to events, it saves us having to unhook. We know that this view model's listening. If it errors, we know we've got somebody with a helping hand behind us because we've introduced pipelines. We don't have to worry about service overrun hell right now. I'm sure we'll still find a way to get there. Jon (46:51.386) Yeah, I mean, you're kind of just moving that problem potentially a bit. Not quite, but. Allan Ritchie (46:55.854) maybe it were focused less on a service and more on the, the, the thing, the action, right? Which I think to me that's where service bus stuff really works well. Jon (47:02.778) Mm -hmm. Allan Ritchie (47:08.814) And where these mediators work because I'm focused on the action and when I do the unit test instead of having to figure out how to spin up the whole damn controller or Service now, I'm just spinning up the thing right this this thing has to do this. This is what I need. So I test it And I don't know. I think it has some value. I think Jon (47:29.594) Yeah, I like the general idea. Is there anything out there already today that is an OK implementation to start from? Allan Ritchie (47:38.862) No, that's why I'm bringing this up. This is a theory one. This is something I am looking at because I have a customer right now that just desperately needs something like this. Now their app works, but... Jon (47:50.074) Cause I feel like there were some, maybe even just looking back at old gone mobile episodes, I feel like there was some pattern implementations in Xamarin that were maybe not exactly what you're after here, but they were kind of in that direction. And they might've been a little bit more tied to UI and everything than we're looking for. Allan Ritchie (48:11.566) Yeah. And that's the thing I'm, I'm looking at this from a bigger, bigger standpoint, like how could it work under these cases, right? Where we use messenger service now or where we use services right now, how can we dissect that and pull it apart? Right. And the thing is, is that no matter what comes up, let's say we have a mediation pattern and I am working on one. I'm trying to get some of this to work and seeing, is this too far? Have I gone down the path of over -engineering or does this have some merit? Got to play with it. Jon (48:18.618) Mm -hmm. Jon (48:40.41) Right, right. Allan Ritchie (48:41.294) Right. That's why I figured this is a good medium to throw this out on because I'd love to know what people think about that. Really would even John, the wheels are spinning. I, he didn't have a chance to read this episode. Jon (48:47.386) Yeah, yeah. Yeah, no, I mean, it's new shiny things, right? Like I'm a sucker for like, hey, I like this thing. Maybe I'll spend three hours and change my code that was perfectly fine and you can go use this. No, no. Allan Ritchie (49:01.518) That doesn't sound like you at all. No. But if we have a mediator, right, this thing would work with MVVM. It would work with MVVU. I just say MVVU. Wow. Get another coffee, dude. It'll work with MVU. It'll work with pretty much anything where dependency injection applies. Hell, this thing could still be a singleton for all you people that like singletons, but out of the hood, guess what? It's still DI. Jon (49:16.89) Yeah. Allan Ritchie (49:28.11) but you could go mediator dot current or dot default and, and send and publish and all that cool stuff and it'll just work. but it'll work with all those patterns. I think it'll help clean up some of the MVV, MVVM rot that I tend to see. I think, I think there's potential here. Jon (49:28.281) Mm -hmm. Jon (49:49.882) Yeah, the one I was looking back some episodes and I think the one that I was remembering and I don't know how related or not it is was flux. I think that was sort of a bit different of a pattern altogether. Allan Ritchie (50:00.974) That's slightly, that's more UI oriented. You're right. I think that was their attempt to make React like, what's that stupid React pattern that everyone used and now no one uses. Jon (50:06.042) Yeah. Jon (50:11.386) Kinda, yeah. Allan Ritchie (50:19.566) I need another coffee. There's a, there. yeah. Jon (50:20.954) Yeah, it's basically it's it's almost kind of immutable state stuff, right? It's kind of like everything moves kind of one direction. I think Allan Ritchie (50:27.694) I can't remember that React had when you used React apps back in the day and I know you hate web dev and HTML. So this is. Jon (50:33.242) Yeah, I never did react stuff. The back of the day that I did web dev was whatever the form was that you could like got the post back or view state. Yeah. You wrapped everything you wanted, the update panel, I think, right? You wrapped whatever you wanted in that. And yeah. Yeah. Allan Ritchie (50:36.846) And I did. Web forms, web forms, view state. Allan Ritchie (50:48.974) Yep. Well, that was even newer web forms. So React had this thing and everybody that did React, if they wanted to make it enterprise worthy, they brought in this other pattern. And I think that's what Flux was attempting to do. It never caught on. And I think it's just because it was a UI state and because Microsoft wasn't recommending it officially, a lot of people didn't jump on it. Jon (51:09.914) Yeah. Yeah, no, for sure. Allan Ritchie (51:16.27) So if we apply these patterns and they, they, they, they, they kind of carry everywhere where they're needed. Like they get to the view model, they get to, you know, even a code behind and they still get to your backend services and they cause a separation. I think there's value in that. I think, I think, I think there's value in it. I'm not seeing the cons yet, unless this turns out to be an over -engineered mess or slow or. Jon (51:34.842) Mm -hmm. Allan Ritchie (51:43.214) You know, it, I just think that I've been thinking about this one for a couple of weeks now. Jon (51:48.026) Yeah, I think, I think, you know, my kind of take on it without having thought about it too much is, you know, one you're, we're, we're trying to kind of help people from themselves in terms of subscribing and unsubscribing from things, to, you know, you're kind of segmenting the, the services up more appropriately in terms of like what the actual logic is doing, which I like that. Yeah. Slice slice them up vertically. Allan Ritchie (52:13.198) vertical slicing. Jon (52:17.818) And then, you know, that kind of is saving the code kind of pollution of inject all these things you might not use. And even like I said, cleaning up the code stink of like a service of services, which is fine, but it's just, you know, doing that felt just like, I don't love this. Yeah. Yeah. Exactly. Allan Ritchie (52:33.088) It's not a stink, it's good. real nice. It's real nice. But I think also it makes that those smaller separated focus because now when you get into teams where there's like, I, you know, I've worked with teams that are like, I think right now the one I'm working with is about 80 people somewhere between 60 to 80 people. And it's just frigging chaos, man. Messages be flying everywhere. Jon (52:52.506) Yeah. Jon (52:56.858) I was going to say like, that's the other thing, right? As the, the working across bigger teams is probably nicer. Now I would be curious to see like how that pattern ages in terms of, you know, eventually you're going to be like, I need to do this kind of slightly different thing with an order. There's a command here already, or maybe there's two, two commands defined, two requests defined, and maybe they kind of both. would do what I need together, but I'm just going to go make this new one, right? Which is kind of what I see in the messenger service thing too is like, I don't know if that's the one I exactly want. Let me make a new one. Allan Ritchie (53:35.36) Messenger service seems to, I don't know if it's just because of the nature of how it works, but it seems to be. Jon (53:41.338) Well, cause it's very non -descriptive, right? It's like, it's just pretty much the name of the type of event. Whereas at least with commands or requests, right? You're like, you have a type and you can kind of see what are the values that it's expecting you to get supply it with and what are the, I guess you look at the typed response for it potentially, or you look at what, yeah, that's maybe another question. It's like, how do I... Allan Ritchie (53:44.192) unfocused. Jon (54:09.274) How are those kind of, how is the request and response coupled? I like, do they have a link to each other? Okay. Allan Ritchie (54:14.208) Yep. The, the, the, if you, if you look at mediator, mediator is the good one by Jimmy Bogard. I think everybody uses it. It's his replacement for, well, no, it's not his replacement. It's another library. He's the guy that made automapper that everybody hates now. even though everybody uses it inappropriately. So, the same thing with meteor. Now I have not seen mediator go too far off the rails, at least in server side. Jon (54:20.122) Okay. Jon (54:30.33) yeah. Allan Ritchie (54:42.816) But the way the command ties to the response, right? So you have a command that says it needs this kind of response and it forces that on the interface with some generic tricks. And it forces it when the mediator says send and you give it a command. It says, well, this command says it's going to give me this type of response. So it's enforced. Jon (55:00.122) Now, what about kind of like unsolicited notifications back, right? Like say like the idea of a notification that the order changed. Can I do that without issuing a command? Allan Ritchie (55:11.616) No, because well, yes, in mediator you can in service bus, you're not supposed to. And most of them try to find a way to say like an event, right? In C sharp, if you have an event or delegate, who's the only one that can fire that technically speaking, who's the only person that can fire that event, the class that owns the delegate, right? So sorry, not the delegate, the event. Jon (55:16.538) Right. Jon (55:25.338) Mm -hmm. Jon (55:29.402) Yep, yep. Which is why you add a public method that says fire this event so everything else can. Allan Ritchie (55:33.44) Well, and that's what ends up happening, right? So Mediator allows you to do a publish right there because you get the Mediator service. So you can do a publish or ascend, which is ascend as a command. Jon (55:38.746) Yeah. Jon (55:46.266) Well, I'm thinking more of just the, like the receiving of it, right? Like I want, I don't, I'm on a page that maybe has order information. I don't necessarily want to publish anything, but I want to know if something else publishes that the order was updated. Allan Ritchie (55:57.6) So that's the place where you'd say, I handle notification of this message, right? And so it'd be an interface you attach to your view model. Jon (56:03.61) Mm -hmm. Okay. Allan Ritchie (56:08.608) and that view model would go or that that would get picked up by DI and say you're interested in these messages. Okay, you've implemented that interface. So you're going to have a handle of this message type. It's probably going to be async because everything's async nowadays. And I give it to you and you do what you're going to do. Right. Jon (56:22.65) Mm -hmm. Jon (56:26.938) Yeah. So that, that kind of, you know, there, there's some cases there where like in that sense you have to know, Hey, I want to know when this thing happens, you know, maybe it's not immediately clear, like which one of these, notification types is the one that I'm looking for, but at least like, again, compared to the, the messenger thing, it's, it's a little bit more strongly typed in the sense that like, okay, I can see this interface, like what's on it. And I can, probably discern by looking through these notification types that this is the one that I want to get. Allan Ritchie (56:58.688) Yep. And, and because of it, you can, you can focus in on, on the things that you're going to get. Now the chances are, if you're the one publishing a command, sorry, publishing a notification, you don't care about the, there's no response on a publication, right? Because there's going to be 10 different or multiple different receivers, right? In a command, you know, if I publish an order and I want to get back, say an order number, or I send a command to, to, to push the order. Jon (57:16.698) Mm -hmm. Allan Ritchie (57:24.672) I'm probably going to want the order number back right away. I'm not going to want to listen to an event because I'm the guy that's pushing the command in the first place. Jon (57:31.866) Right. Yeah. You want to write the code that's just like, wait, public, you know, push order and then get my result back. Allan Ritchie (57:36.032) Yep. Get the result back, display it on the screen. Your order ID is 123. Yay. But maybe you've got another service that's also now going to say, look, we've received the order, right? Maybe the backend wants to start, you know, you've got a background service that maybe wants to start pulling that. I don't know why you do that, but, or you've got a single R connection that's listening and it's like, okay, we see this published came in and now that's going to publish an event. Jon (57:54.042) Mm -hmm. Yeah. Allan Ritchie (58:02.784) say this disorder has been shipped and then maybe you put some sort of stupid toast up. I don't know. Right. These are some of the things that, that I think matter. now for anybody thinking, Hey, I'm just going to go try mediator in my .net Maui app. Don't do that. It's not ready. It's not built for that. And you really have to know your, your life cycle of dependency injection to get that to work. You're Jon (58:08.378) Yeah. Jon (58:18.906) Yeah, that was my next question. Jon (58:28.698) Yeah. Well, and I'm seeing stuff like, you know, register services from assembly. It's just like, there's a lot, it looks like there's some reflection going on there. Allan Ritchie (58:34.528) Yeah, you don't want to do it. Now reflection, I'm not as scared of on a one time basis, but if you have like 400 services and you're in a Maui app, it's going to take time, right? So, so don't go using. Jon (58:40.986) Well, no. It's a wild card at best. Yeah. And for trim ability and stuff like that, the area that the direction we're trying to move mobile in, especially in .net does not lend itself well to things like reflecting. Allan Ritchie (59:03.136) Well, and here's the thing, right? This is my thinking pattern is for the bigger apps, right? So bigger enterprise scale apps, and this is going to sound scary. They don't care about the trim, right? Jon (59:08.794) Mm -hmm. Jon (59:15.162) I know, I know, but... Allan Ritchie (59:16.416) No, no, I get this from, from small apps. This may be over engineered. I know a lot of people are like, shiny does this. Okay. I, dude, I apply to multiple platforms. It's got a, it's got a bit of girth underneath. You don't have to use it. It's meant for the big boys. If you're only using it for notifications, you probably should have just used a smaller thing that does lesser stuff. Jon (59:27.802) Mm -hmm. Allan Ritchie (59:38.368) Right? The same case would be applied to mediator or any of that stuff is this is meant for the big boy apps, not the ones that say hello world. You can, you just have to be willing to know what you're getting into. And, and the thing is, is that if you apply this to, if you could just go and take mediator out of the box and you try and push it on your Maui app, Jon (59:45.178) Yeah, but I want it all and we can have it all. So. Allan Ritchie (01:00:01.056) First of all, you're going to think, my view models, I want to hook them up to that, that, that messaging pattern, right? Here's the problem is it's going to recreate the view model. You're not in the same instance, right? That meteor is going to spin up a view model or this, this message handler. It doesn't know it's a view model. It doesn't care. That's not what we're looking for. Jon (01:00:10.906) Hmm. Jon (01:00:17.306) And that's not, you know, so it's not, it's not the binding context for your page and all that fun stuff. Allan Ritchie (01:00:21.216) Exactly. So you're out of context. So you're going to be like, Hey, it's not refreshing my UI. I guess one must be a bug in Maui. It's not. You've got the wrong instance, the wrong binding context. It's a fresh new instance. So these are the things is that I'd like to see something where I can apply this to those areas that matter, right? Our binding context, our background services, and still have this command publisher. Jon (01:00:27.514) Mm -hmm. Jon (01:00:40.058) Yeah. Jon (01:00:45.114) Now it doesn't seem like that complex of a thing to build. I know that the devil's always in the details, but you know, for like the basic pattern of it, it seems like that's not so bad. Allan Ritchie (01:00:57.12) No, very easy. But when we get now there's a couple things, right? Is you need to be able to register services with multiple interfaces, which isn't something you get out of the box with Microsoft. There's some trickery you have to do there. Still not hard. What is hard is again, I want this messaging pattern to work on existing binding context that have already been resolved. So that's where things start to get a little interesting. So I'm working on it. I've got some ideas. Jon (01:01:08.826) Mm -hmm. Allan Ritchie (01:01:27.52) I'll find a way to, I will find a way to make this work, but I I'm curious. What do people think about this? John has bought in unlike RX. John is genuinely interested in this. You can usually tell. so he's interested to see how this is going to work. mind you, because he hates probably hates the messenger service to do all the memory leaks and crap. We've seen. Jon (01:01:46.17) Well, I don't use the messenger service either myself. I've moved away from that, but I am interested in every time I there's something new and shiny and can make my code look nicer and smell better. I like that. So, and doesn't have a lot of weight to it, right? Cause like, cause this doesn't have to be a heavy thing when it's implemented. Allan Ritchie (01:02:00.224) That's why I chose that banner to brand under. Allan Ritchie (01:02:07.936) It doesn't have to be. I'm not sure if it will be. I know you won't use it anyways. You're going to spin up your own. Jon (01:02:09.594) Don't don't if you make it heavy, I'm not using it. No, I will if it's if it's light and airy and you know, bouncy and youthful and vibrant, I will I will put it in my app. I'll take the dependency. Allan Ritchie (01:02:23.424) John is a good friend of mine. He does not use shiny. He will not use it. He had to make his own background jobs for Cranow - Jon (01:02:27.034) I don't use Shiny, but I use your localization source gen. Allan Ritchie (01:02:33.984) Yeah, but I made that only so you would do your localization properly. Yeah, but it's sort of, yeah, okay. You shiny, background jobs. Jon (01:02:37.914) And I use it, see? I appreciate it. All right, well, that's probably it. Somehow we turned an architecture conversation into a long one again, so. Allan Ritchie (01:02:49.952) It's how we do, but I see when I wrote these notes up, I had a good idea because this is something I've been toying with. And because of where I, what I'm working on right now, this is how open source spawns, right? Is you start, you're like, okay, this sucks. What's the pattern that where this works? that does. How can I bring this over? Jon (01:02:55.01) Mm -hmm. Jon (01:03:03.13) Yeah, how can I improve it? And do I have to go build it myself because I can't find what I'm looking for? yeah, that's fun. Allan Ritchie (01:03:09.792) And I love building stuff. So this will be open source and there'll be something, there'll be something to share there in the future, but it is not. Jon (01:03:16.346) Just don't make it use our X. Don't depend on our X. No, no, don't do it. Exactly. Allan Ritchie (01:03:20.608) John get with the program. Okay, fine. I don't need, I don't need RX for this anyway, so it's all right. but because there's nothing to share for this yet, obviously I put mediator up on the server because people should use it. It is good. Don't hate on it. You use it properly. It's fantastic. Just like automapper. If you do service bus, which is what automapper was originally meant for, it's fantastic and it works. Just use it for what it works. Don't go outside of the box. You've been given. Jon (01:03:31.162) Mm -hmm. Allan Ritchie (01:03:49.728) But kind of going back to kind of some of the stuff I have seen this week and kind of to the MVVM, you know, when we're talking about set state and, and MVU and stuff, there was two I've, I've been looking at. So one is, ADO space reactor UI, which I know David, or now seems to really like that one because it's, it's a, it's a fantastic thought pattern that he's got there. Jon (01:03:50.906) within the lines. Jon (01:03:58.042) Mm -hmm. Jon (01:04:07.738) Mm -hmm. Jon (01:04:16.218) Yeah, I've never used it, but I've had my eye on it. It looks pretty cool. Allan Ritchie (01:04:19.872) There's another one that's kind of being worked on right now. It's, we're going to have to put this one up because the name is fun, but it's like rearch .net. Rearch. Rearch. Rearch. Jon (01:04:28.41) I like that. What? Yeah, I clicked on the link and it's just like coming soon. I'm like, what is this? Allan Ritchie (01:04:38.144) It's an interesting pattern. It's kind of on top of React, this Maui Reactor. And it kind of brings some of those MVU patterns like the React style. And again, if you've done React, I don't like React Native as much. Jon (01:04:51.194) Okay. Allan Ritchie (01:05:01.6) but I do like React as a general purpose mechanism that they do. It's quite neat. So this Rearch or whatever the, somebody correct me on the name. It looks interesting. I think this will be an interesting topic on top of Reactor UI that people should be checking out, but we'll post those links because neither John or I were successful, I think, in saying it. And the guys... Jon (01:05:05.53) Yeah. Jon (01:05:13.05) Heh. Jon (01:05:22.458) Cool. Yeah, you're not gonna. Jon (01:05:28.426) yeah, and we'll have to remember to post the links. I'm terrible at remembering to put the action. I'm like, yeah, we'll put a link to this in the show notes and then I don't do it. So. Allan Ritchie (01:05:34.688) Well, people can leave feedback for you and say you suck at posting links, leave feedback. And also if your GitHub name contains numbers on it, don't expect me to say it, right? You got to come up with an, with an interesting name. So this guy's name has numbers in it. So sorry, sorry, Nibond two five one. I said it, but nobody remembered it. Jon (01:05:38.394) That's true. I mean, it's nothing I don't know, but sure. Jon (01:05:53.402) Yeah, he did. I think that's correct. Yeah, well, it's fine. All right. So yeah, that, that, I think is a nice set of, I don't know, packages, plugins, products, whatever you'd call them, which is why that's the title of that section of the show. So I think that'll do it. you know, I'm going to ask again, I would heal a lot faster from my injury. If y 'all would just go get on Apple podcasts and leave that five star review. that would, that would. help me immensely in my recovery. So please do that. No, no, goodness, no. I mean, I'm sure I will just not on purpose. Allan Ritchie (01:06:25.312) Does that mean you'll hurt yourself again if we stop getting reviews? Okay. Cause that would be funny. We could post those as tick talks. Jon (01:06:34.106) Yeah, this isn't going to turn into, you know, a nineties show. goodness. Yeah. But if you do have feedback, if you want to tell me how bad I am at putting links up on the show notes, you could do that. You'd have to go to the website to do it where the links would be missing from. So gonemobile .io. So you get there and you can from that website also find other ways to contact us and including email. And there's a thing called speakpike .com. that I don't know if anyone's actually used yet, but it's there. You can record a voice message. We could even play it back on the show unless you don't want that. But yeah, drop us a line. Allan Ritchie (01:07:09.879) Let us know what you think about the mediator idea. I'm interested. Jon (01:07:12.094) Yeah, that will be fun to get some feedback on. We could do a follow -up episode at some point once we get all that feedback after people have left those five star reviews. Allan Ritchie (01:07:21.527) Relentless. Jon (01:07:23.962) Yeah. All right, everyone. We'll see you next time. Bye. Allan Ritchie (01:07:26.679) Ciao for now.