Shawn_Clabough:
Hello and welcome to another episode of Adventures in.NET. I'm Sean Clayberg, your host, and with me to co-host Caleb Wells. Hey, God, Caleb. And Way-Loo. Hey, Way.
Wai_Liu:
Sean, Caleb, how's everyone?
Shawn_Clabough:
Doing good, doing good.
Wai_Liu:
I'm good, I'm good. So, glad to
Shawn_Clabough:
Good.
Wai_Liu:
be on the show.
Shawn_Clabough:
How's life as a Microsofty? You know, you've got a little bit of time under your belt now,
Wai_Liu:
Yeah,
Shawn_Clabough:
so.
Wai_Liu:
it's been fun. Yeah, I'm starting to almost finish my onboarding now. So hopefully I'll be in with clients soon, I guess. But yeah, it's been great. We had a big conference in Sydney recently. I got to actually meet my team. So that was good. Lot of drinking, lot of sessions and stuff like that. So yeah,
Shawn_Clabough:
A lot
Wai_Liu:
learning.
Shawn_Clabough:
of drinking.
Wai_Liu:
So yeah,
Shawn_Clabough:
Wow.
Wai_Liu:
you know, just. Nothing like bonding, a bit of bonding other than over some drinks, right? So yeah.
Shawn_Clabough:
It reminds me of the time that I was at a show when Comdex was in Las Vegas, an old tech show, and Microsoft had a private party at one of the local bars.
Wai_Liu:
Oh. Yeah!
Shawn_Clabough:
My niece lived in Vegas, and so she was very good at sweet-talking the doorman and got us into this
Wai_Liu:
Hahaha
Shawn_Clabough:
private Microsoft party and just got drinks and drinks and everything. And I ended up on the front page of abcnews.com because there was somebody there, some reporter taking a picture and happened to catch me and my niece and a bunch of Microsoft people. Yeah, right there. So
Wai_Liu:
Nice.
Shawn_Clabough:
front page, yep.
Wai_Liu:
I hope
Shawn_Clabough:
And
Wai_Liu:
you
Shawn_Clabough:
they
Wai_Liu:
kept
Shawn_Clabough:
were trash.
Wai_Liu:
it.
Shawn_Clabough:
Yep, they were trashing Microsoft Bob and things like that. So that tells you how long ago that was, but yep,
Wai_Liu:
Ha ha ha ha
Shawn_Clabough:
that's my claim to fame with Microsoft.
Wai_Liu:
Hehehe
Shawn_Clabough:
All right. Let's welcome back to the show Chris Hainte. Welcome back, Chris.
Chris_Sainty:
Hey, thanks for having me back. It's nice to be
Shawn_Clabough:
Yeah,
Chris_Sainty:
back. How are we all doing?
Shawn_Clabough:
good. Oh, a lot. We last had you on, uh, May of 2021, episode 70.
Chris_Sainty:
Yeah,
Shawn_Clabough:
So it's
Chris_Sainty:
that
Shawn_Clabough:
been
Chris_Sainty:
sounds
Shawn_Clabough:
a little
Chris_Sainty:
rough.
Shawn_Clabough:
while.
Chris_Sainty:
Yeah, yeah, time flies, doesn't it? Yeah, yeah, at least we're sort of, hopefully coming past the pandemic stuff now, which is good.
Shawn_Clabough:
Yeah. What's changed for you since then?
Chris_Sainty:
Oh, so let me think. So mainly finishing my book, that's the biggest change in my life. That was such a huge drain on my time and resources when that finally finished. It was a bit like the sun coming up at dawn and the darkness sort of disappearing
Wai_Liu:
Hahaha.
Chris_Sainty:
near the end there. It was getting quite brutal. But yeah, so that's great. So that's all finished. And then I've
Shawn_Clabough:
So the book
Chris_Sainty:
just.
Shawn_Clabough:
is Blazer in Action, right?
Chris_Sainty:
That's it,
Shawn_Clabough:
Blazer,
Chris_Sainty:
yes.
Shawn_Clabough:
yep.
Chris_Sainty:
Yeah, so that's great. So that's out and it's physical copies are printed and it's all real, which is lovely. And then to be honest with you, I've been really enjoying not writing. So I've been doing loads of conference talks. So I've been making up for sort of the two years lost in the pandemic and I've been lucky enough to been all over the place actually this year. So I've been, yeah, I've been in Copenhagen, I've been in Denmark. So Denmark, where else? Belgium and I'm going to the Netherlands and Oslo. I've been to Portugal and stuff and probably some others that I'm forgetting now but yeah so it's been really nice to just be interacting with human beings and sort of talking and getting
Wai_Liu:
So the
Chris_Sainty:
responses
Wai_Liu:
conference is the
Chris_Sainty:
from
Wai_Liu:
back,
Chris_Sainty:
real.
Wai_Liu:
are they? The physical
Chris_Sainty:
Yeah
Wai_Liu:
ones?
Chris_Sainty:
yeah I mean over here in the UK and in Europe and stuff like Yeah, this year, so I've been talking at a lot of the NDC conferences. So I've been there a lot, which is, and doing their circuit, which has been lovely. That's a great conference. And Techorama as well, which is another pretty big one over here. So yeah, it's just been a nice change of pace. Like after being sort of stuck in a room for two years, sort of tapping away on a keyboard to sort of, yeah, get. interaction with people and sort of be able to speak to them directly and that has been yeah it's just been a real welcome change of pace and yeah it's been really good really good.
Shawn_Clabough:
kind of doing the book tour and giving out autographs and things like that, right?
Chris_Sainty:
Yeah, exactly. Yeah, like I did have like my first like little weird thing where I did the toolkit Tecarama, which is in Antwerp. And yeah, I did the tool and that is really cool at Tecarama. So they do it in a cinema. So you give your talk and your talk is being projected onto like a cinema screen. Like it's the coolest thing ever. And in the main room, someone gets to do it on an iMac. So if you're like the likes of Richard Campbell,
Shawn_Clabough:
I'm gonna go.
Chris_Sainty:
you get to do it on the iMac screen. So I'm not there yet, but yeah, normal cinema screen was more than enough for me. But anyway, finished the talk and everything. And yeah, someone come up to me and said, can I have a picture with you? And I was just like, are you sure I'm the right person? Like, you're not mistaking me for someone more important. More interesting. So that was a very flattering experience and stuff. So yeah, that was quite cool. But yeah.
Shawn_Clabough:
Yeah, I was at Microsoft Ignite with Richard Campbell doing some of the podcasts and things like that there. Yeah. People come up and say, yeah, can I have a picture or whatever? It's like, oh, me? Really? Oh, no, you mean Richard. OK.
Chris_Sainty:
Yeah, it's kind of like that with Richard. Yeah, I've been at a few conferences with Richard now and yeah, yeah, he's just a phenomenally intelligent guy. It's so scary speaking to it sometimes, but he's brilliant.
Shawn_Clabough:
Yeah, great guy, great guy. So, uh, I guess we're going to go a little bit more into blazer than what we did in the past, you know, especially since your book is done. Uh, you know, what's kind of changed and what's, what's the big news about blazer in the past year.
Chris_Sainty:
So I think the easily the big one for Blazor has been its integration with Maui. So Maui was GA'd I think it was about build time. So that would have been May, wasn't it, around then. And yeah, along with that came Blazor Hybrid, which is the version of Blazor that can run inside Maui apps. So it was... Kind of a big deal, because then you've now got Blazor where you can write your rich interactive web apps and all of that, but you can now also use it to write desktop and mobile apps as well. So you've got like the full, almost like pretty much the full gambit of things to target with it, which is brilliant. And the other thing is because of the way that the Blazor, hybrid model is still using, it's still based on sort of HTML and web tech. So that means that the components you're using in your Blazor websites can also be shared and run as is inside Maui apps. Now, obviously there's still considerations in there because you probably know if you've got services talking to backends, you... might need to change them around a bit or stuff like that, but the actual UI components themselves don't need to change. They run inside of a web view. So it's kind of like, you could think of it a bit like Electron in that way, but hopefully a bit more, I think a little bit more efficient than what you get with Electron.
Shawn_Clabough:
Is it lighter
Chris_Sainty:
So that's,
Shawn_Clabough:
weight than electron is?
Chris_Sainty:
yeah, well, I think, so I mean, I do want to caveat that I'm not really a desktop developer. So I've done some, a very little bit of playing around with Maui, but Unfortunately, I've not had a huge amount of time to get into it. But obviously the thing with Electron is it's bundling Node.js and the renderer, the web rendering tech as well, or engine. So that's where you get a lot of this bloat from that people often talk about, I think, with Electron apps and stuff. Whereas with Maui, they sort of, you've got... it's written obviously on.NET Core. So, you know, if you've got that, you're good anyway and stuff, or there's bundle, it's bundle with it. But the rendering part of it is delegated to the OS's renderer, to my understanding. So if you're on Windows, it's gonna be WebView 2, I think it is. And then if you're on like iOS or Mac OS, it's gonna be WebKit. and that one. So that means it hasn't got to be bundled in with the app. So a little bit more efficient and stuff like that. So yeah, so I think that's probably the big news from Blazor for this year. Obviously we've got.NET 7 coming in November. So there's going to be a few more bits and bobs in there. and later in the year. So one of those, I think the highlights is going to be threading, I think. So that should be quite cool for WebAssembly. So the browsers have kind of got to a point now where threading can be supported with WebAssembly. I think they could have done this before. And I think if memory serves, there was a security issue that was found with it. And they were going to put this in, I think maybe for.NET 6, and then they had to back it out because of this threat was found. So I've been waiting for the browsers to patch that and waiting for that cycle to complete and everyone to get updated. And I think as being a little bit of the case at the moment, Safari was the last holdout to get things done. I keep hearing
Wai_Liu:
Get
Chris_Sainty:
more
Wai_Liu:
a
Chris_Sainty:
and
Wai_Liu:
new
Chris_Sainty:
more
Wai_Liu:
IE
Chris_Sainty:
people.
Wai_Liu:
now, right? So...
Chris_Sainty:
Yeah, I just keep hearing that all the time. Everyone's going like they're the new IE6. Like they're just not adhering to standards, but they're popular enough to then cause a problem. So yeah, but that's all been done now. So I think they'll be able to support sort of threading, true multi-threading in Blades of WebAssembly.
Wai_Liu:
So what would be the actual use case? Would it be, you'd be able to support like get more games and all that stuff on the browser?
Chris_Sainty:
Yeah, I mean, anything that would, you know, you would normally take advantage of threads for in your applications, it would now be possible in the browser, which is something that's never been possible in a browser because browsers have always been single threaded. So it's always been a single threaded model and you've just always had to work around that and stuff, whereas that's not gonna be a limitation anymore going forward. So yeah, hopefully it'll open up some more performance stuff
Shawn_Clabough:
Yeah,
Chris_Sainty:
and,
Shawn_Clabough:
definitely
Chris_Sainty:
you
Shawn_Clabough:
seems
Chris_Sainty:
know.
Shawn_Clabough:
like there could be security concerns.
Chris_Sainty:
Yeah, absolutely. Yeah. Yeah. So, um, so yeah, so that's a, that's another big one. So that's cool. And there's a few other bits and bobs that are coming, um, with.NET 7, like some quality of life improvements and, um, little weird things like if you've been using Blazor a lot, you, you know, you, it's little things like, um, there's some changes coming to like the navigation manager service where it's, it's got to be one of the longest running requests, which has been, uh, some kind of event, uh, to hook onto before navigation happens. Because I think back to when I was writing Angular apps and stuff, and it's like, we'd always put in a check to if the form hadn't been saved that was being filled out. you'd put a check in, you know, I think they called it interceptors in Angular, I think if I remember correctly, and you'd have an interceptor that would stop the navigation process if the form data hadn't been saved, so you could pop open a thing or, you know, tell the user that they needed to save or if they wanted to discard whatever. You can't, you haven't been able to do that in Blazor using any of Blazor's native APIs, you can do workarounds with JavaScript interop calls to do stuff like that, but it's very much something you had to roll yourself. and it's gotta be one of the highest requested things that I've seen. So that's coming in.NET 7, which I think will be quite cool. I mean, I'm doing all this judging obviously by what's in the GitHub repo. I don't, I'm obviously not on the team, but like, so yeah, so that's gonna be cool. I think that will sort of satisfy a lot of people who have been sort of building more and more sort of
Shawn_Clabough:
So
Chris_Sainty:
more important
Shawn_Clabough:
if you're building
Chris_Sainty:
apps.
Shawn_Clabough:
for Maui, if you're building for Maui, do you still choose between WebAssembly and server-side? Do you still have that choice or is it just...
Chris_Sainty:
No, it's not relevant in Maui, because in Maui you've got.NET Core, so the components run directly on.NET. They don't need any of the intermediary stuff or any of the extra stuff that the other hosting models have. So if you think about the Blazor server model, it needs to have the signal arc connection to stream the changes down to the client. Obviously, the Maui app is the client, therefore, you don't need that. There's no need to run WebAssembly because you've got access to.NET Core. WebAssembly is not needed. Yeah, so it's actually like a really lean hosting model because it's just running on with all the performance of.NET
Shawn_Clabough:
So
Chris_Sainty:
Core, which
Shawn_Clabough:
even
Caleb_Wells:
It's
Chris_Sainty:
is
Shawn_Clabough:
though
Chris_Sainty:
great.
Shawn_Clabough:
it's using
Caleb_Wells:
interesting.
Shawn_Clabough:
WebView, it's just using
Caleb_Wells:
Yeah.
Shawn_Clabough:
that for just the render.
Chris_Sainty:
Just the render, yeah. Yeah.
Shawn_Clabough:
Yep.
Caleb_Wells:
You know, I, uh, I watched one of, uh, Sanderson talks and he said they debated on whether to name Blazor server and Blazor WebAssembly completely different things because they really are complete different things and Maui is an extension of that, right? It's really the underpinnings, maybe Blazor, but the way that it's actually used is, is very different, right? So yeah. Cool.
Chris_Sainty:
Yeah, yeah, well, there's all kinds of fun with naming. I mean, in the very early days of
Caleb_Wells:
Thanks for watching. Bye.
Chris_Sainty:
Blazor, we went through the dark age of renaming, as I've called it a few times, where for a period, Blazor server became, was named, Razor components. So you had Razor components, which was the server hosting model, and then you had Blazor, which was Blazor WebAssembly. But the community had been using Blazor client or Blazor WebAssembly and Blazor server for a long time. And it was one of those things that the change was sort of done and stuff. And the feedback was kind of like this waterfall of people that this is not working. Like this is really difficult. And I remember I was writing blog posts like every week at the time. And I'm like writing blog posts going, if you're using Razor components or Blazor components. And everything I did had a bracket saying, or razor components, or blazing, depending on what the scenario was I'd come by. And I mean, if you go on my blog, you'll see in older blog posts, they're still there. All these brackets going, all this, all this, depending on which one. And I'm like, also thinking about like SEO as well. I'm like, if this rename sticks long term, I need both phrases in here, because otherwise like, it's not gonna work. And then after a few months, it then got changed back to Blazor Server and Blazor WebAssembly. And I think everyone was like, okay, this makes sense. This kind of works. And then at the end of the day, the programming model is the thing that you're interacting with. And that's the thing that's the same. It's just the rendering that's different. Like, is it rendering via SignalR? Is it rendering via WebAssembly calls? Is it rendering via, you know, Maui in the WebView? So, yeah. Yeah.
Caleb_Wells:
Now that your book is out, when are you going to start on version 2?
Chris_Sainty:
Oh, yeah, yeah, that's the question, isn't it? Yeah, a friend of mine, he likes to rip me on that. It's like, when you're gonna start version two, he's gonna say, now, I think it would take a lot for me to do another one. I think it was a very, it was a very good experience. I love the fact that I can now go, I'm a published author, I've got a book, it's lovely, but like, I can't under emphasize the amount of time it takes. Like it was two years in my life and it was two years every day, but I probably had one day off a week for like two years. It's just relentless. Because not only are you obviously trying to, you know, you want to write good. you know, write good, engaging chapters and you're constantly weighing up, you know, what you can include and what you can't. Cause like, so one of the things I kind of learned along the way was like writing a good book is about, just as much about choosing what you don't put in it as what you do. Cause obviously there's a huge amount you could talk about about any part of any... any area of development really any framework or anything like that and like but what's relevant to the person who's reading the book like you can flood them with information but then you're just going to confuse them and you know and there's things like oh I could explain that in real detail but actually that you don't need to know that detail. But at this point of like where you'd be on your journey, like that will probably just hurt your head rather than get the concept across. And it's more important you understand the concept now and you can worry about the internals later and like making all those choices and rewrites and then the edits and you know, all that. And it, for me personally, it definitely by the end was, it was, it was. very draining. Like I was like, you know, I was getting up at sort of five, six o'clock in the morning doing three, three, sometimes four hours of writing, then doing an eight hour, nine hour work day. And then, you know, I'm maybe going to be, you know, I was maybe doing a few tweaks as well in the evening sometimes. I think I mentioned this last time, my wife and I had our first child as well while I was
Caleb_Wells:
Right.
Chris_Sainty:
halfway through this process. So that admittedly probably made it feel a lot worse than what it would have been otherwise. So yeah, so certainly right now I'm in no rush to start another version and things. And I think as well with where Blaze is at, I think I don't know what I would put in a second edition anyway. Like it's... at
Wai_Liu:
Well,
Chris_Sainty:
the moment.
Wai_Liu:
how much has kind of already been like outdated, I guess, or superseded by new features and things like that?
Chris_Sainty:
Well, right now, nothing, because the book's targeting.NET
Wai_Liu:
Yeah, it's
Chris_Sainty:
6.
Wai_Liu:
a salad.
Chris_Sainty:
So that's great. And the changes that are coming in.NET 7, looking at them, doesn't look like there's going to be anything that invalidates what's in the book, which means that buys me another year, which I think
Wai_Liu:
Hahaha
Shawn_Clabough:
Hehehe
Chris_Sainty:
in print terms is like a massive deal nowadays that if you could get like 18 months of relevance out of a book, that's actually... NET 6 quite impressive like
Wai_Liu:
Hmm.
Chris_Sainty:
for normally like writing books on Microsoft tech or especially dotnet has been I think a bit of a safe bet because like if we were on framework you're like talking like four five year cycles and like you know you can write a book and it's good because it's going to be like another four years before the next major version of framework came out and things but dotnet core obviously improved the pace and now you know with it going back to I keep saying NET now and the yearly cadence. You know, now I think as a book writer, it's even more challenging because you're almost writing a book and it's all about the timing of it. You almost want your book to be finished during the last sort of previews of the next release so that it can be published and land just after the release. And then you're gonna... get a year and then you kind of hope that nothing major changes in between. I mean, the great thing is I think that with Microsoft's approach nowadays is that the breaking changes are, I think it's probably fair, and Caleb you could probably comment on this as well. Like I think it's fair to say for Blazor especially, like over the last few releases, there's just been nothing that's really broken like between versions. Like from, I can't think of anything from five to six that was a breaking change.
Caleb_Wells:
Yeah, it's
Chris_Sainty:
And
Caleb_Wells:
all
Chris_Sainty:
I
Caleb_Wells:
been
Chris_Sainty:
don't
Caleb_Wells:
additive.
Chris_Sainty:
think there was a huge amount.
Caleb_Wells:
Yeah.
Chris_Sainty:
Yeah, it's all been additive stuff,
Caleb_Wells:
Or performance
Chris_Sainty:
which is
Caleb_Wells:
improvements. Yeah.
Chris_Sainty:
all performance
Caleb_Wells:
Yeah.
Chris_Sainty:
improvements exactly.
Caleb_Wells:
Yeah.
Chris_Sainty:
So that's actually been really good, both as a consumer and user of Blazor and also being someone who's written a book on it. It's like, oh, if they keep that trend up through.NET 7 and.NET 8, then this is going to be okay. So, and looking like what they're planning, it doesn't look like, again, even looking at what could potentially be in.NET 8 wouldn't necessarily be. hugely breaking or anything. I think there's just the stuff like, you know, with multi-threading coming in to WebAssembly, like would that bring about some different approaches to programming apps? But that's, again, I think when you're looking at a book like Blazer in Action, that's kind of targeted at kind of people who are new to the framework, that's maybe not something they care about right there. And then they're trying to understand the fundamentals of how does the framework work and things like that. And those are things that probably aren't gonna change a huge amount. you know, over time, because that isn't really the way that Microsoft do things generally
Shawn_Clabough:
Yeah,
Chris_Sainty:
most
Shawn_Clabough:
my
Chris_Sainty:
of the
Shawn_Clabough:
boss
Chris_Sainty:
time.
Shawn_Clabough:
writes books on C sharp and it's been changing so fast lately. He's gone to an every other version type of release for his book. So
Chris_Sainty:
Yeah, yeah,
Shawn_Clabough:
yeah.
Chris_Sainty:
I can understand that. Yeah, we were like, when it was coming up to the point of like, at one point we thought we were gonna end up being in a position where the book could be published before last November. So we were like. don't want to do that, don't want to have the book published like a month or two before November, because then that will all be.NET 5 and then.NET 6 comes out almost immediately. And like, there might be new APIs that we could have talked about or whatever. And as it turned out after, you know, as is the way, you're like, you know, a few edits take longer than you think and some feedback and you change it and you rework it before you know it, two more months of your life has gone by and you know, it's no longer an issue, but yeah, the timing now is quite, I think, important for writing books. But again, it all depends very much on how the book's written and what it's targeting. If you're targeting more concepts and... that kind of thing, then you're probably gonna get much more longevity than if you're maybe doing a very literal book that's more, maybe more like a cookbook style book where it's giving you literally answers to questions and then they could change, you know, stuff like that. So, I think Blazor in Action sits more towards that concept style end than it does towards the literal, though it is designed to give you a working app that's based on real world, you know. design choices and architectures and things like that. So,
Wai_Liu:
I wonder
Chris_Sainty:
yeah.
Wai_Liu:
if it's better
Caleb_Wells:
say this.
Wai_Liu:
to have like a more of a, oh sorry, you
Caleb_Wells:
Go ahead.
Wai_Liu:
go. Oh, okay. I was gonna say, I wonder if it's better to have more of a kind of like, you know, like the concept of a book that goes from start to finish kind of thing. And that kind of gets updated slowly. Instead of that, maybe having more of like an evergreen type thing where like maybe a user kind of buys a subscription to your book and it's an ebook and you, And over the course of a year, you just gradually update it as new features come in. Do you reckon that would probably be a better model?
Chris_Sainty:
Yeah I think that's an interesting one. So I think like in terms of being able to keep things more relevant then yes, I guess. There's some stuff there that I think is interesting. So it would depend, I guess, how. How do I put this? What the compensation scheme looks like, because that's a long, because you're essentially taking potentially almost like an endless commitment. Like normally, like with a print book, you're effectively, you sign a contract to do that book. You know, you create a proposal, you sign a contract, you agree a delivery time with the publisher, and then you work with the publisher, deliver that book, and that's it, you're then done. And then, you know, if you're... if your book does well or whatever, they might engage you to do a second edition or whatever. And then again, you will have a new contract and you do that and it's done. And I think the only thing with the model that you've suggested is that, how do you kind of contain that?
Wai_Liu:
End. Right?
Chris_Sainty:
Yeah, because
Wai_Liu:
Hahaha.
Chris_Sainty:
I love Blazer to bits, but there's probably gonna be a day where I'm gonna get like, okay, I've had enough now. I want to... look at something new or do something else or you know try something else and things like that and could you be in this kind of almost endless commitment like that's going on and on and on I mean Manning are really good like the publisher I work with in that there is an ebook version of it and then there's a print version and they will do updates to ebook the ebook version I don't know how regularly that happens and So I can make some tweaks if we find some mistakes and the ebook version can potentially be updated. We haven't really discussed about when or if that will happen in the current process. So there is kind of a little bit of that going on with this version, but I think for everyone concerned in this, there needs to kind of still be a bit of a definition between start and end rather than just kind of this constant ongoing. There's not a thing. I think also, I think like almost then, are we not just kind of maybe just talking about blogs at that point? Like, could you not just write a blog that's just,
Caleb_Wells:
You know,
Chris_Sainty:
you know, and keep
Caleb_Wells:
I find
Chris_Sainty:
updating
Caleb_Wells:
it interesting
Chris_Sainty:
the posts? It's...
Caleb_Wells:
because I've run into, like I bought a PDF, any book on Angular 6, right? Years ago. And I still get emails saying, we've updated it to whatever the current version is, right? And some of these are bigger changes than others. And I only paid once, right? So that's a huge benefit. for me. But if you look at it from their perspective, for instance, you're going to have stuff that's pirated. It's going to happen. And so maybe you have a pirated version of Angular 6 and 7, but they're now on Angular 13. And so the pirated version is no longer valid. So that's an interesting subject.
Chris_Sainty:
Yeah,
Caleb_Wells:
That would be
Chris_Sainty:
well, it's almost like the same
Caleb_Wells:
difficult.
Chris_Sainty:
as like with, yeah, but it's like with buying software, isn't it? It's like, you know, the industry has been taken over by subscription models because it, you know, if you think of it, you know, we all know the amount of effort it takes to, you know, to write a really good piece of software that's sellable and to get paid for that once and then, you know, potentially have to provide updates to that version for a while. That's a lot of resource and unless you sell a lot of copies and then you sell them again when you go to the next version, I mean, ultimately that's why subscription models have become more popular, isn't it, with software houses? Because every time the version increases, if people are paying monthly, they're gonna upgrade to that new version, which is good. You don't have to put lots of legacy stuff over long periods of time, hopefully. But you're kind of almost got a bit of a predictable income with what you're doing versus, you put all this effort, maybe a year or more effort into creating a new version of something. I'm thinking like the older dope, I mean, who didn't have
Caleb_Wells:
Yes.
Chris_Sainty:
a pirated copy of a dope Photoshop at some point? Like, it was kind of like a thing, wasn't it? But like, you get that and you just hang on to it. Because like, if you weren't a graphic designer or something and you were just using it to... create some stuff for your own fun websites. Like you can happily run with like a three or four year old version of it and not care. And like, you know, there's no motivation to upgrade it. And even if you did buy a copy, then again, like you've probably spent three, 400, 500 pounds on the license back then. And again, why would you then in a year's time go and pay that again for the next version when you're like, well, it's
Caleb_Wells:
Right. Yeah.
Chris_Sainty:
only a few features and like, you know, whatever. So yeah, this, I think there's the whole, that's a similar, like I said, the thing isn't it?
Shawn_Clabough:
I just
Caleb_Wells:
You
Shawn_Clabough:
thought
Caleb_Wells:
know,
Shawn_Clabough:
of a new
Caleb_Wells:
I actually
Shawn_Clabough:
business.
Caleb_Wells:
own...
Shawn_Clabough:
I just thought of a new
Caleb_Wells:
Go
Shawn_Clabough:
business.
Caleb_Wells:
ahead, Sean.
Shawn_Clabough:
I have have YouTube for books. So you're reading, you're reading a book, average for so many page, you get an ad. So, and then as you read something, you get an ad, but then also along with it, you get, there's a chat channel. So people can leave feedback or chat about a certain section of the book, so on and so forth and keep that live. And then as you make revisions. people have to come back and read those revisions again and they see more ads. Somebody steal
Caleb_Wells:
There
Shawn_Clabough:
that
Caleb_Wells:
you
Shawn_Clabough:
from
Caleb_Wells:
go.
Shawn_Clabough:
me.
Chris_Sainty:
Hehehe
Wai_Liu:
I think the forum
Caleb_Wells:
I mean,
Wai_Liu:
for your
Caleb_Wells:
I was.
Wai_Liu:
book would definitely be good actually. Alright Chris, do you
Chris_Sainty:
So
Wai_Liu:
have that for one of them?
Chris_Sainty:
yeah, there is one, yeah. So Manning provider, it's called the Live Book Forum. So you can, if you've got a copy of the book, you can go on there, you can read the book, and then at any point you can sort of highlight section and go like, you know, oh, Chris, that's just wrong. You know, that's not true. Or that's that code. As many people have pointed out, that code doesn't run. Because one of the things I found, like when you're writing a book over two years, you do a lot of refactoring along the way. and oh my god trying to keep those ducks in a row is, that's a serious job. Like the refactors we went through, just the architecture of the example app that's used through the book, it went through some pretty big changes. And like, you know, if you're sort of four, five, six chapters in, you've now got to go back and retrofit the chapters you've written to match the new design. and you've got to make sure that all holds through. And then there's a companion GitHub repo as well, which is, you know, you can go and download like each chapter and the final finished code base. And so you're updating that and updating the code samples in the book and the wording in the book and like. Yeah, I mean, I think towards the end, that was the biggest bulk of the edits was just going back through the Livebook forum and just finding everywhere where someone would say, like, this doesn't make sense, or this namespace doesn't exist anymore, or this file you're referring to, where is it? And then you're like, oh, that doesn't exist anymore. We don't want to refer to that. Yeah, it's like a bit of a, yeah, that was just a nice. But having that live book forum was really useful because the people who fed back on that, it was invaluable for that kind of stuff. And even now, I'm not sure we caught every little thing, but hopefully we have. But yeah.
Shawn_Clabough:
I think you should narrate the audio version.
Chris_Sainty:
Yeah, I think I'd need to sell a lot more copies before I think they commissioned me
Shawn_Clabough:
Hehehehe
Chris_Sainty:
to sit in a room and talk about it for that amount of time. But yeah,
Wai_Liu:
you do the code examples in the audio version.
Chris_Sainty:
that would be interesting wouldn't it? Yeah, that could be good. So yeah, keyword namespace, something
Shawn_Clabough:
Hehehehe
Chris_Sainty:
dot something dot something, curly bracket. Oh yeah,
Caleb_Wells:
Mmm.
Chris_Sainty:
that wouldn't work very well would it?
Caleb_Wells:
So I've actually read the book, Chris, and if you are one and done, I think you did good. You did good by your readers and by Manning. But you know, now that I'm much more familiar with Blazer and I've read your book, I actually did have some questions about some of the things you did in the book and why you took the approach that you took. Um, so I was wondering if we could pick your brain a little bit.
Chris_Sainty:
Absolutely yeah yeah and thank you for the kind words it's nice to know that at least one person is happy that's good
Caleb_Wells:
Yeah.
Chris_Sainty:
hopefully a lot more but like it's good to hear that.
Caleb_Wells:
Yeah. So I believe we've actually gone over WebAssembly versus server versions and the benefits and drawbacks of each, right?
Chris_Sainty:
Mm-hmm.
Caleb_Wells:
And I think we both lean WebAssembly for the most part. One of the things, though, that I've dug into more now is hosted versus standalone for WebAssembly. What's your preference or approach when it comes to those two options or templates?
Chris_Sainty:
Yeah, okay cool. So it really depends whether I'm building a new API or if I'm talking to an existing one. So the WebAssembly hosted template essentially is giving you a solution that includes a Web API project and a Blazor WebAssembly project. and it's configured in a way that the API project serves the Blazor WebAssembly app. So, and I think if I remember listening to one of the shows recently, you kind of discussed this there as well. So you have the start project as the API project, which can sometimes throw people, because I've seen people do this as well, where they say they think it should be both or something, and you get weird errors and stuff like that, but yeah. you just have the API project and stuff. And the goal of that is kind of more to give you a starting point for a full stack app. So you've got your API where you can do all your server stuff, you've got a shared project that shares models between the two, and then you've got your WebAssembly project for doing your UI layer. And yeah, and it's basically all ready to go. It's all the basic plumbing done for you, and you can just get on the start building stuff. Standalone is just WebAssembly, no backing API, and it's expected you either have an app that doesn't need it, or that you're going to talk to one that already exists, and you know what that is, therefore you can work out what you need to call where, and what have you. So yeah, so basically with those two, it is that simple for me. If I'm building the API along with the front end, then I will use the host template. If I'm... talking to an API that already exists or building like, I don't know, say like I'm doing like a prototype or a proof of concept where I'm like, I can mock the data from the API, I don't need a real API, well, I'll just use a standard, I'll use a standalone app and then just fake the data or load it from a local JSON file like the standard project, like the default project template does or those types of things. So that's where I would choose one over the other.
Caleb_Wells:
So another question and Sean and Wei feel free to interrupt me because I will go and go and go right? There seem to be two camps that are coming out when it comes to Blazor and that's whether you have your code block in your razor file or in a code behind right in its own class. Which direction do you lean? Hehehehe
Chris_Sainty:
Oh yeah, I know what you mean. This is like a tab versus faces for Blazor, isn't it?
Caleb_Wells:
Yeah, it is.
Chris_Sainty:
So my general preference would be the code block in the razor file. That's my starting point is probably the way to phrase it. Then depending on what happens with that component, I'm... you know, I might make a decision at some point down the line to create a code behind file. Now, so far at Deploy where I work, the app that we've been building, we haven't got anywhere that we separate the code and the markup, they're all in razor files. The only place I've got examples of separating the two, that are mine is in some of my Blazor libraries where I've got components that are just very, very big. They're ones that I either want to refactor or they just have a lot of stuff in them. And I just, no matter how I approach it, I just can't really think of a good way to make them smaller. So they're kind of sitting there. And to mitigate that, I've moved the logic into a code behind file to just help. you know, ease things out a bit. I think what I, the thing I'd say here is, it doesn't matter, like what you choose, choose what makes you happy, to quote Scott Hansen, like do what
Caleb_Wells:
That's
Chris_Sainty:
makes
Caleb_Wells:
perfect,
Chris_Sainty:
you happy,
Caleb_Wells:
yeah.
Chris_Sainty:
like it really doesn't matter, like there is no performance benefits, there's nothing. At the end of the day, components in Blazor get compiled, so they all get compiled back into one class. So whether you choose to write a razor file and a backing class, or you write them in one file, they all end up in one file anyway. So it's purely whatever makes you more productive, whatever you prefer. Me and my team at work, we're all happy with the single file approach for a few reasons. One is that we find that otherwise you're flitting between two files to do, to make any changes. So that's one thing, that's a pain. The second thing is that... we don't want components to be too big. So we use the size of them as a bit of a flag. So if we start finding ourselves excessively scrolling on a component, it's like a trigger to us to go, maybe this needs a redesign, maybe this needs some stuff broken out of it and things like that. So that's sort of another reason for doing it that way. There is, and then for me personally, the other reason is that it's just a constant reminder It's not business logic going in here. Like it's UI logic. Like I. There's been a lot of times when I've spoken to people who are very pro the code behind approach. They've, you know, they've either come from like, maybe like a web forms background where you, you know, you had that explicit separation there, or they're looking at it from like, I don't know, maybe they've been using patterns like MVVM, where again, it's very much encourages you to decouple your markup from your, you know, your. your model and your view logic there.
Wai_Liu:
It's very much that kind of philosophical debate between, I guess, Angular and React, isn't it? You know, like where
Chris_Sainty:
Yeah.
Wai_Liu:
the code should fit. But yeah, at the end of the day, it is a matter of preference, I think.
Chris_Sainty:
It is absolutely a matter of preference. And like I say, there is just no right or wrong. Just do whatever you're happy with. And you know, some people just do not like the fact that ultimately, even though Razor is just, it's a markup language that gets compiled, well, in Blazor specifically, the Razor code gets compiled to C sharp instructions. And it's just there as syntactic sugar to make your... life more pleasurable as a developer because writing out those instructions by hand is just not particularly pleasant. But because it looks different and it does look like HTML, there is just people who balk at the idea of mixing two code, two different languages in one file even though it's not because Razor is a mixture of C sharp and stuff. I think the interesting thing for me on this is I don't know if anyone's looked at the grid. that the Blazor team have built for.NET 7 as a preview. Quick grid, I think it's called. And it's been built as a best practice for high performance grids. And it's the Blazor team giving you sort of, you know, their view on like how this should be written in a way that would be the most performant and everything like that. And I'll be honest, I've scoured that code, God knows how many times and it still hurts my head. I'm just like, you know, there's some clever people. And I look at it and I'm like, the way they've done it is very interesting. So they actually use both. So they have a razor file that has a code block and has a code behind, which is a very interesting approach. And the way they do it is they have chunks of the UI, that they have moved into methods in the code block that are just render fragments. So all they do is return a render fragment, so it's more markup essentially, but it takes it out of the main block of markup at the top. And then all of the methods that perform actions are then put in the code behind. So if you've got a click event on a button, that will be in the code behind. but for rendering out a repeated piece of UI, that might sit in one of these render fragment methods. So it was an interesting approach that I, I'd not seen that from anyone before, before I saw that. And that was an interesting take for me, because that was like, okay, well here's the logic that does stuff, and that sits in code behind, and here's the logic that is. 100% UI focus, like it just is logic that creates more markup and that sits in the code block. So yeah, I thought that was an interesting take. And it also is quite sort of a good one because again, it shows you can just write HTML markup into methods in code blocks, same as you can write C-sharp code into the markup area because it's all razor and that's how razor works. So similar to how B units testing. option works with the razor syntax as well. But yeah, that was a very interesting one. So that was like a third approach really. You've got code behind, code in there, or both. Just to like, mix the pot even further for people. So, yeah.
Caleb_Wells:
I agree with you on having it all in one file. At least that's my personal preference. The funny thing is, back when I was doing Angular React, I prefer Angular's approach. I don't like the way React did it. And I flip-flopped with Blazor. But you know, I've had people on my team ask, you know, why are we doing it this way? You know, wanting to have the discussion, and I've given them some of the same points you did. And luckily I'm the architect of my company, so I get to decide. So,
Chris_Sainty:
Ha ha ha.
Caleb_Wells:
um, yeah, but I can see the, the benefits from both approaches, depending on your team and what you're trying to get out of it. But one of my biggest things was it's obvious, like you said, when you're scrolling to plus pages, it's too big. Right. And you really need to rethink it. So.
Chris_Sainty:
Yeah. Yeah.
Caleb_Wells:
Another question I have, and this has actually sparked some debate in my company, has to do around mediator. And it's on paper, it's an awesome pattern, and you can see how it really simplifies things and kind of silos stuff right, but if you don't do it right, it can leave you in a world of hurt, so to speak.
Shawn_Clabough:
I'm telling Jimmy.
Caleb_Wells:
How did you choose... Yeah... Well, it's not his fault, right? How did you choose Mediator for Blazer in Action?
Chris_Sainty:
So I've used MediaTor for a while now. So when I was architecting apps at the previous company I worked at, we used MediaTor there and I enjoyed working with it. I liked the, I liked it. Basically what happened was I discovered CQRS. what happened with it. So I've been building apps using onion architectures and clean architectures and things like that. And then one night I was reading up about CQRS and like this idea of just everything you do in your app is separated either into a read or a write. And I don't know why, but that really resonated with me in a way where I was like, yes, that's correct. I've seen apps built that have got these kind of calls that are doing all kinds of things. They're writing some new data and then they query some more data and then depending on what you sent, they send back this data or some other data and all this kind of thing. And this idea of just separating this out and saying, right, in this call, I'm going to write something and in this call, I'm going to get something. And just having that clarity, I don't know, just... worked my head I think it's just because like I'm not that brainy so like I just like simple things work for me. So that was basically the start point. So once I got into that, Mediator sort of is sort of
Caleb_Wells:
made sense.
Chris_Sainty:
something you stumble on quite quickly when you then start Googling about CQRS and.NET and what have you. And I think. Like as well, like just as a slight aside as well, as like with CQRS, I think I'd heard of it previously, but I've been put off because I think CQRS often gets linked directly with event sourcing. And I was always like, that's scary and complex. And like, I don't need to be doing like, you know, writing events constantly and then having to like replay all these events to know what's where and like blah, blah, blah, blah. And then I was watching some stuff on YouTube and it was making very clear that no, these things are not things that have to work together. They're just things that can work together. And there's certain scenarios where we work very well together, but they're two separate patterns and they don't, you don't have to do that. So like, yeah, that opened up. And then I've been a big fan of domain-driven design for a long time as well. And then... because of Mediator, I also sort of then ended up looking at vertical slice architecture. And then that was like the kind of the whole thing then just like pinged together for me. Cause I was like, you know, the major in design is brilliant. And like, it gives you the place to add your, you know, your share, like your, you know, your. Because often with people when they're using mediator or using like CQRS and like, then you start looking at vertical slice, you often get the thing of like, right, well, what do you do with... like shared code or what do you do with repeated code, like, you know, things like that. And like when you're doing vertical slice and things like this, you're like, you tend to lean on the side of duplication because that way you keep things isolated and what have you. But then DDD and having a domain gives you that opportunity to centralize any common code. So you can put those into aggregates and entities, have that all down in that lower layer and then just have your verticals coming off of it. And when I first, architecting this old company I was at, Mediator was the way of getting around controllers for me. So I've never liked controllers from the perspective of nowhere else in programming would we be happy with putting a bunch of methods that are not related to each other in one class. Like it just would never happen. yet controllers have always just been this dumping ground where you can just stick all these arbitrary methods that never interact with each other in a class and somehow it's okay. Like it's always been a bugbear, but it's like, but it's a thing. So you just do it, don't you? And then I was like, mediator was a way of clearing that up because basically, okay, I'd have my method in my controller but it would just. call them, it would just create a mediator request and fire it off. And it was like every single method in my controller could be like two lines. And it just meant that I could negate it. It was there, but it was a thin layer. It was purely responsible for collecting the request, you know, deserializing, you know, whatever's data has been sent up, chucking off to the mediator and then, you know, constructing the response and sending it back, which is probably what most people would agree is what. a controller endpoint should be doing. It should literally
Shawn_Clabough:
And
Chris_Sainty:
just
Shawn_Clabough:
now
Chris_Sainty:
be
Shawn_Clabough:
we
Chris_Sainty:
that
Shawn_Clabough:
have
Chris_Sainty:
middle map.
Shawn_Clabough:
minimal APIs to do just that. So it makes it even easier to do, yeah.
Chris_Sainty:
Yeah, and then you've got middle APIs, which is kind of like embracing that more, which is good. But that was where Mediator first came in for me. And it was just a way of being able to just really, not but obviously, you can't obviously, I'm not bypassing controls, but just dealing with them as least as possible and then forward it on. Then you just have a handler in, but. Back then it would have been the application layer in your Onion architecture and that would have done whatever it was doing. It would call on domain services or persistence, you know, infrastructure stuff to save data or get data, wherever. And it was just a lovely clean pattern. And like I sort of got my team at the time, we walked through it and after it, after like we had this like two hour session where we just went through all of this. And I was like, so what do you all think? And everyone was just like. Yeah, that makes total sense. It's really clean. And obviously as well, the nice thing with Mediator is you can use it for doing domain event stuff as well. So you can, Mediator's got like... you can do like media.send and just send off a request and that can have a handler that can deal with it. But it's also got an option to like send off an event that you can like multiple handlers can subscribe to. And then so you can kind of, so if you've got domain aggregates, you can sort of create these domain event. sort of have a list of domain events on it on an aggregate and then like you can put stuff into like say like a db context that will when you're saving an entity will you know intercept it pull those things out dispatch those off using mediator and then this other stuff these sort of side effects can happen and all of that so it gave us like all of these bits and bobs in a simple way because like the apps didn't need like whole messaging queues to deal with all that. It wasn't that kind of stuff. And like that would just end, added so much complexity and like media just let's do all this stuff. And it was performant enough for what we needed. It was simple and it kept the code clean and easy to maintain. And yeah, so it all worked well. And then, and then then it deployed like. moving one step further, because we're a startup and we've been going through the product market fit stage and there's been a lot of iterations and stuff like this. And I was like, when I had to architect the platform, my number one sort of concern was the volume of change. So it's like, well, we're a small development team. We're a startup that's trying to make an impact here. and we're gonna have to change stuff a lot. So I was like, when I was considering the architecture, I was like, I need an architecture that can change really rapidly, very often, and not break things. So then that was when the final bit of the puzzle came in where I ditched onion architecture and moved to vertical slice, because then we built. all of the features in our application in vertical slices, which meant that when we discovered some new information and realized there was a better way to do it, whatever, we could just rip out a vertical and just replace it. And it didn't have any dependencies on others. So we could do this and not break other bits of the app. And we've rewritten our... platform like probably three or four times in total, but in small chunks over time because we've been able to do that with our architecture. And again, Mediator has been a key point of that. So, you know, we use Mediator in Blazor to sort of dispatch all of our requests. And so whether we're getting data when a component loads or saving data when you submit a form, that all happens through Mediator. And then on the API end, we've actually been, we've moved towards, we've moved onto a package. We actually have written our own implementation of this, but in the book, we use API endpoints. So that's a package from our Dallas, Steve Smith.
Shawn_Clabough:
Steve.
Caleb_Wells:
Yeah.
Chris_Sainty:
Yeah. And that is kind of like, it's almost, I guess, a bit of a precursor to like a bit like minimal APIs in that it's just a single endpoint in one file, in one class. And that kind of... gives us the sort of similar pattern to what we were using the old company with the controllers with endpoints that just had mediator calls in them, except now we just have a class with an endpoint and that's it. And that is all in a vertical as well on the server that matches the vertical on the client. So it all just kind of ties together really nicely. And like the admin portion of our... our platform is actually now blazes server and we use mediator that can then do the whole thing. We can keep the whole thing in one file, which is really cool. So we can have the razor file and then we have another C sharp class that just contains the request, the handler, and it's just all in one file, which means it's like ridiculously productive, like scarily productive, because you just don't have to go to all these different files and do all these different things. Everything's just there. And yeah, I mean, that's been a real meandering waffle I made like, but like that's kind of been the journey through mediator and stuff. And that, you know, for these various reasons it's just worked and it's been, you know, yeah, just been a really useful tool for me and the teams I've been in. So, yeah.
Shawn_Clabough:
The current project that I'm working on is my first experience with actually using Mediator and having something that's really a full domain driven design architecture. And it took some adjustment to me from my mental model. You know, I was trying to I was trying to trace through the requests that I'm used to it, going to a controller and then to a database layer or entity, something like that. And then, you know, going out from there. And it's like I couldn't. fine, where's it going? What's listening to this? And so that took some work there, but once you get it, it just, it makes sense.
Chris_Sainty:
Yeah, oh, absolutely. Like I think with the, I think especially with like some of the team members where I'm at now at Deployed, like initially when we talked about vertical slice architecture and like introduced it, it's like there is a bit of an initial friction where you're like, but layers, like the- we have a database layer and then we have application layers and then we have controllers and we have this structure and it's all this. And I was like, and the way I often put it to people is I'm like, right, cool. So when was the last time you changed your controller layer? And I don't mean like a bit, I mean like the layer. When did you ever operate horizontally? And like, it doesn't happen. I mean, even if you think about a traditional team set up with a front end team and a back end team, right? When does either one of those team ever work horizontally? They don't.
Shawn_Clabough:
Yeah, yeah, because changing your controller layers is scary. You know?
Chris_Sainty:
Yeah,
Shawn_Clabough:
That's
Chris_Sainty:
exactly.
Shawn_Clabough:
it.
Chris_Sainty:
And like, why would you, you know, when does the last time your product owner came along and went, you know what, we need to change the API control layer. Like, that's not the request you get from the business and like, it's not how it works. They come in and say, we need a, you know, we need a new feature that allows the user to add a profile picture, right? And that's going to involve. changing a bit of UI, it's gonna have probably, it's gonna have an endpoint that's gonna, or at least a couple of endpoints probably to get the picture and save the picture. It's gonna then have something in there to actually retrieve the picture from wherever it is or save it to wherever it's gonna be on that server side. So actually, if you think about how apps are built, they're always built vertically pretty much. It's just that we then go through this dance of putting layers in and... There's a brilliant diagram on, it might be on one of Jimmy's sites or on Headspring's site about vertical slice architecture where it says, you start off with this lovely design where you've got your layers and every layer is talking down really well. And I know people who are listening to this is not, I'm doing nice vertical lines here. And then what happens is, oh, but that cool. is basically very similar to this one, but if I just give an extra parameter, that will do that, and I won't have to create a new service or a new method on that service. So I'll just add that in, and now I've got a line going sort of 45
Caleb_Wells:
Diagonal,
Chris_Sainty:
degrees over to here.
Caleb_Wells:
yeah. All
Chris_Sainty:
And
Caleb_Wells:
right.
Chris_Sainty:
then this happens again and again and again and again. And after a few years of development, what you end up with is a giant spider web of calls, and this leads to scenarios that I'm sure we're all aware of, where you end up with a bit of... the application that everyone goes, oh, there's dragons over there, you don't touch that. It talks to things we don't know what it talks to. John wrote it, John's been gone a year and a half, so we just don't touch that. That's a black box. And that's because all these kind of cross-calls are happening and no one has got the time to sit there and try and like, you know, forensically trace each one to work out what the side effects would be of refactoring and things like this. So if you adjust that vertical model and you know, the pain kind of goes away, because it's not like you can't have structure within those verticals, but you don't need, I think the way that I think about it is you don't have a necessary structure. Like if I'm building a feature that like would be best talking to, I don't know, storage queue. in Azure, for example, right? I can have my API endpoint, right? Just directly call off to the storage queue APIs, right? And just ping that over there because why do I wanna then just delegate that off to a service that will then do it itself when I could just do it there and then? Like what's the benefit of doing that, right? So I could do that. But then... if I've got a crud bit of my application that needs to just write data to my database, well, then I've got an endpoint that can talk to a DB context and can update that, and that can do that there as well. And then I get something else somewhere else that deals with a, I don't know, I've got like, I don't know, say some local queue running or something. So now I've got an endpoint that is writing to a local queue that... has something handling it or it's, I don't know, maybe it's got a signal R hub in it because we're gonna do some real time stuff for that feature and bits like this. And the point is each vertical can have a micro architecture that suits that vertical perfectly. In an onion architecture or clean architecture app, an architect, you know, your layers get set when the design first happens and then that's it, you live with that for the life of that application. And that might never be optimal for like, chunks of that app and you're then just dancing through hoops trying to traverse layers because you have to because you know this layer can't talk to this layer because you know we've put dependency references in that stop that happening and stuff so you have to jump through hoops of doing all this stuff and you end up writing a load of code that you don't need because you just have to hook these layers together in the way it was originally designed and all that just feels so inefficient to me and like um it's Like I say, it's the proofs in the pudding. And then certainly for deploy, we've been able to iterate and build a phenomenal rate with a very high level of quality because we just don't ever build anything we don't need to. And if anything becomes ugly and difficult, we just rewrite it because it's cheap to do it and it's easy to do it. And there's a very high confidence of doing that because of these verticals being isolated and not having... like side effects because something else might depend on them. You know, and the trade off for that is that every now and then we'd have some small amounts of duplication here and there, but that's an easy price to pay for the efficiency you get everywhere else. And for true shared code, like I mentioned earlier, we can push that down into our domain objects and you get all the reuse that you need. And it's genuine reuse, you know, this is not, you know. you know, the classic example, oh, I've got two classes that are named the same that have got the same properties apart from one property that's different. And it's like, they're the same. No, they're not, because there's a property over there that isn't over there. However you
Caleb_Wells:
the
Chris_Sainty:
cut that, that means that they're not the same. It might only be a micro difference, but the point is they're different. And you're going to make a trade-off at some point if you decide to make them one class, because there's a reason they would, you know, there was different property in there in the first place. And I think the... I think in our industry, the whole dry principle has been. responsible for a lot of negative design choices at times because we get drummed into us, I think, as developers. I mean, I know I did. Repeated code is like the root of all evil. And you almost then you over hype that to the point that you get to the point where you're like, even if code looks similar, that's repeated code, so I need to refactor it. And it needs to be the same because repeated code is bad. And that, I mean, don't be wrong, like truly repeated code is bad, but often in most cases I've found at the various places I've been at, very, very few occasions are genuine repetition. They're things that just look similar and that is not the same. And that's a very key difference to understand. And that... choice then to bring those things together creates a coupling between things that probably should have stayed separate and then this is when maintenance problems come in longer term and what have you. Anyway,
Shawn_Clabough:
Yeah, yeah,
Chris_Sainty:
I'll go and on one about
Shawn_Clabough:
I get
Chris_Sainty:
this.
Shawn_Clabough:
it.
Caleb_Wells:
Ha
Shawn_Clabough:
I
Caleb_Wells:
ha
Shawn_Clabough:
totally
Caleb_Wells:
ha.
Shawn_Clabough:
get it. Because for years and years and years, they could separation of concerns, separation of concerns. But then they thought controllers, well, those are all the same concern. They're handling an HTTP request from something. So that's all the same concern. So put them all in the same layer and do it that way. And then have your database layer. Well, that's all the concern of the database. So that's all the same. So put that together.
Chris_Sainty:
Yeah, and there's skill sets. I mean, if you think as well, and I think back to my early years, my career, you didn't touch database stuff, because DBAs did that. So there was also some physical reasons for these layerings to happen, because they just were physically dealt with by people with a different specialization. One of the first places I worked as a developer, you might write some SQL scripts, really they were kind of almost like... almost like pseudo-coding type thing because you gave them to the DBA to write the real one and they would apply that to the database and whatever. So you weren't really responsible for much of the data stuff. All you ever did was call that stored procedure and dealt with what came back, but you were never, not like we do now where you've got EF Core and you're physically creating entities and that represent database tables and like that just... that just didn't happen back then. That was all behind a walled garden over there that you didn't get access to. So certainly some of this is just historical stuff as well, but yeah, anyway.
Caleb_Wells:
You know, I do wonder if you took a brand new developer and started them out on vertical slice architecture and mediator, if they would crack things faster or it would make more sense.
Chris_Sainty:
Well,
Caleb_Wells:
But you know, because.
Chris_Sainty:
I have a graduate in my team hired directly out of
Caleb_Wells:
Yeah.
Chris_Sainty:
university. So I would, his name's Blake, I would put, I'm not gonna put Merge's mouth, but I would say that he is, like he, it was interesting. Talking to him when he joined and explaining the architecture through to him, his response was, that makes sense. Literally, he didn't, no questioning, no nothing. He's like, yeah, that makes perfect sense, of course. Yeah, we're building verticals, don't we? So why would you not organise things that way? and versus someone in the industry who's been around for a while.
Shawn_Clabough:
Like Kilbyn myself.
Chris_Sainty:
Yeah, and then you're
Caleb_Wells:
Yeah.
Chris_Sainty:
dealing with, you're dealing with historical behavior patterns. Like,
Caleb_Wells:
Right, absolutely.
Chris_Sainty:
I mean, it took me quite a while to justify to myself that it would be the right thing to do because I've, I mean, I've been. a developer of 17 years, I mean I've had
Shawn_Clabough:
Yeah,
Chris_Sainty:
it
Shawn_Clabough:
because
Chris_Sainty:
drilled
Shawn_Clabough:
you're always
Chris_Sainty:
into
Shawn_Clabough:
comparing.
Chris_Sainty:
me that separation
Shawn_Clabough:
You're always
Chris_Sainty:
and concern.
Shawn_Clabough:
comparing. This
Chris_Sainty:
Exactly.
Shawn_Clabough:
new way, I'm doing it this way, this way. OK, well,
Chris_Sainty:
Yeah.
Shawn_Clabough:
how did I do it the other way? Was that better or was this better?
Chris_Sainty:
Yeah,
Shawn_Clabough:
And so, yeah, always
Chris_Sainty:
yeah,
Shawn_Clabough:
comparing.
Chris_Sainty:
yeah, absolutely. So, yeah, it's...
Caleb_Wells:
longer you've been doing this the more friction you have making a big change like vertical slice architecture right yep yeah cool so I have another question for you it's not mediator related
Chris_Sainty:
Thanks for watching!
Caleb_Wells:
or not I guess it could be vertical slice architecture so right with blazer the whole point or one of the big points is componentizing, right? And so you can break things up, make them reusable, push some of this logic further down. What is your limit for how far down you will build a component, right? So you have your parent component that has a child component that has a child component that has a child component, and these are all valid, right? You're not doing it just because you want to componentize. I'm using air quotes. How far are you comfortable? How many levels would you go down typically when building out something like that?
Chris_Sainty:
Yeah, so the way, so just terminology wise, I would look at that as features and sub-features. So
Caleb_Wells:
OK, yep.
Chris_Sainty:
all the UIs, like, the way, like I say, I've built UIs, it's feature-based, which is, you know, similar like feature folders, like, you know, has been in Angular and, you know, other front-end frameworks for a long time. I've always liked that when I did Angular apps. I was like, again, it's one of those things I saw it and I was like, that makes perfect sense. So when I started working with Blazor, I just started doing the same thing. And again, it works really well with vertical slice because my feature is my vertical slice. So we organize and we do this at Deploy. We organize that way. So I know we talked about this a little bit beforehand. So. I checked and so far we have, we do have features that go as low as eight levels deep at the moment. We don't have a hard limit. And the reason for that is that when you're, well, at least in my opinion, when you're building in features in this way, the depth of the feature is kind of irrelevant because it's sitting logically where it sits in the UI. it's where you expect it to be. So if it's eight levels down, you don't care because you know it's eight levels down because in the UI you go here and here and here and here to get to it, therefore you go in the feature folder structure and you go here and here and here and
Caleb_Wells:
Here,
Chris_Sainty:
here,
Caleb_Wells:
here, here.
Chris_Sainty:
and it's where you expect it to be.
Caleb_Wells:
It makes sense. Yeah.
Chris_Sainty:
Yeah, so if that's eight levels or 20 levels, well, it... yeah okay you might get a little bit annoyed having to expand everything in in Rider or Visual Studio but it as a developer it's where you expect it and that to me like much like yourself because you know you're an architect my I look at it as my job there's a lot of this stuff is I need to I'm looking to have architectures that just make sense to the developers that are using them like it does what they expect it to do. So that's where that kind of kicks in really. So like the devs just, they don't even think twice. They're like, well, yeah, of course. Like that feature sits under those features in the UI. So therefore it sits under those features in the feature folder. So it's in that folder where I, like I don't need to tell, like they could probably tell you the folder structure without. actually having it in front of them. So like, well, yeah, we'd go into clients and this and this and this. So it would be in the clients folder and the things we've found in the thing. So probably there. And they'll be close enough, even if they don't get it exactly right. So, and like, you know, we've all got wide screen monitors now. So it doesn't matter when your folder tree starts expanding. Hopefully.
Caleb_Wells:
Well, hopefully, hopefully, we all have widescreen.
Chris_Sainty:
Yeah.
Caleb_Wells:
Yeah, right. Yeah. If you're listening to this and you don't have a widescreen, send me a Twitter message, and I'll see if
Chris_Sainty:
Yeah.
Caleb_Wells:
I can help you out, because that ain't cool.
Chris_Sainty:
I must say that I can't, I couldn't go back. I couldn't go back, but yeah.
Caleb_Wells:
Yeah.
Chris_Sainty:
But like
Caleb_Wells:
Yeah.
Chris_Sainty:
I say, like, it probably, if it got really, really crazy, you'd be mainly, but like, I think if you subscribe to that feature, to that feature folder design, like, then you just kind of take it as it comes, really.
Shawn_Clabough:
Alright Chris, so since you have so much free time now, since you're not writing a book, what's next for you? More conferences?
Chris_Sainty:
Yeah, well, I'm so what we're recording is we're recording this in August, aren't we? So like I'm going to so I'm off to NDC Oslo in September. So that would be lovely. I'm then going to Techarama's other conference, which is in just outside Amsterdam, I think. So that's going to be in October. So that's all good. And then I actually don't have anything else in the diary, I don't think, after that, which is kind of, I'll be honest, it's kind of nice. Like, it's got to the point now where I was like, these things will, like, the diary will fill up. It's just like,
Shawn_Clabough:
Well,
Chris_Sainty:
so I enjoy a bit of free time when I can.
Shawn_Clabough:
you're probably spending a lot of time raising a child. I think that's probably
Chris_Sainty:
Yeah,
Shawn_Clabough:
a good
Chris_Sainty:
I mean,
Shawn_Clabough:
thing there, too. Yeah.
Chris_Sainty:
in all honesty, I'm actually taking a lot of time away from the computer, in all honesty. I've been, after sort of just giving two years of my life to just work and side project outside of work, like to be completely real, and I think it's important because I don't think we often talk about this enough, like I honestly have just burnt out. I've just been... I just like, I put everything into all of that stuff. And like you said, John, I've, you know, my little boy's coming up to two now. And, you know, I'm really enjoying spending time with him. And I'm actually, to be honest, doing a lot of physical stuff by myself. Like I've always been a very active person. I used to play a lot of like football, so like soccer for Americans. at a pretty high standard. So I've always been very fit. I've always been like pretty trim and like, you know, active and what have you. And like, I just lost all of that over the period of writing the book. I mean, obviously that was through a lockdown as well. So that didn't help matters, but I put on a bit of weight and just like, it wasn't great. And like now I'm just spending, I've really got into CrossFit. So I'm like, I'm just like going to CrossFit. spending time with my wife and my son, and I'm just not touching the computer outside of work at the moment. And I'm kind of happy with that at the moment. And it will, you know, I'll get back to it all. Like, I'm not, like, it's not like I'm like, okay, I've written a book, I'm done now, goodbye. Like, I'm off. But I think like, you know, I think in our industry, like, most people who do this job are very, you know, they enjoy... it as a hobby as well as a job. And like, there's a slight danger to that that you can never kind of recoup sometimes because it's kind of just a constant onslaught and things. And like I say, for me personally, I was like, yeah, I have hit a point and I was like, some people close to me were like, you need to take a break. Like you're like. just at that point now where like it's a little worrying, you just need to take a break. And like they were right and I'm glad I listened and I'm not taking that time. And the conferences are lovely because they're spaced out enough that it's not a big drain. And I find conferences quite natural. So like I don't worry too much. Like they don't fill me with dread. I mean, I get the little flutter of butterflies like most people do before they go on stage and stuff, but it doesn't like, I don't get massive anxiety over it, which is... good for me because then I can go there, I get, I'm in a fresh, you know, fresh scenery. The people there are always, you know, really great to talk to. There's, you know, the speakers at these events are always amazing. You know, people far cleverer than me that I can listen to and gleam information from. People who attend are always enthusiastic and they've got great questions and are great to talk to and stuff like that. So I find it quite, yeah, quite kind of... like refreshing and like
Caleb_Wells:
recharges
Chris_Sainty:
recharging
Caleb_Wells:
your batteries.
Chris_Sainty:
for me.
Caleb_Wells:
Yeah.
Chris_Sainty:
Exactly,
Shawn_Clabough:
Yeah.
Chris_Sainty:
yeah,
Shawn_Clabough:
Yep.
Chris_Sainty:
I mean, I am quite an introvert. So like I do find like long periods of time people to be quite draining, but short periods I'm all right with. And like conferences are great. It's like, what are they like three days like, and it's just, it's great. And then I mean, by day three, I'm like starting to get a bit fried and I'm like looking forward to a quiet time on the plane on the way home on my own or whatever, but you know, in between it's that and it's just enough of a... of a hit of the programming world to like keep me going, if you know what I mean, like, and stuff like that. And then, but yeah, I mean, things like blogging and stuff like the moment I just, you know, the amount of effort that goes into having to write blog posts and stuff, and I just, I can't bring myself to do it at the moment. So I'm just like sitting back from it a bit and like, I've got like loads of stuff. I've got so many ideas and so many like potential blog posts written down in like my Notion board. Like it's like. I'm not gonna have a problem filling the blog up when I'm ready to start again. But yeah, I mean after two
Caleb_Wells:
You
Chris_Sainty:
years
Caleb_Wells:
know.
Chris_Sainty:
of solid writing, it's just like, I need to do something different for a few months, like at least.
Caleb_Wells:
think that's good. Right? You have you have different seasons in life. And I think we even taught the last time you were like, how do you make time for all this? Right? And that was a season in your life where you were juggling a lot of stuff and it was important and you were, you know, building a book and a reputation and open source library. And now you can reap some of those benefits and take some time to recharge. Right? Yeah, absolutely.
Chris_Sainty:
Yeah, definitely. And then hopefully come back even stronger again, you know, and it, you know, like I say, I will get back to my blog and like, you know, there's, there are a couple of my open source packages that desperately need some love and I'm well aware of it. And as soon as I'm, you know, I'm able to kind of face it, I will definitely sort those bits out, but. I think you've got to look after yourself as well and know when, like you said, Caleb, it's seasons and you've got to know when's the time to put in the work and when's the time to just recharge the batteries for a bit and then come back and definitely going through that phase at the moment and stuff. And work with Deploy is very demanding as well, so that's the other thing. So yeah, so it's like I said, I'm happy with doing the conferences at the moment. That's the perfect interaction with the community and being able to still give stuff back and produce content and things, but not at the same level as having to do a blog post every week and that commitment and stuff. So yeah.
Shawn_Clabough:
Yeah, I really, I really get what you're saying there, you know, but, uh, you know, we do appreciate the time you put in, you know, writing the book and doing that. And also the time you spent with us today, you know, that's some time out of your busy schedule. So we appreciate it
Chris_Sainty:
Oh,
Shawn_Clabough:
and,
Chris_Sainty:
it's my
Shawn_Clabough:
uh,
Chris_Sainty:
pleasure.
Shawn_Clabough:
coming
Chris_Sainty:
Like,
Shawn_Clabough:
on here. Yeah.
Chris_Sainty:
at the moment, to be fair, if I'm not writing something, I'm happy. Like,
Shawn_Clabough:
Ha ha ha ha!
Caleb_Wells:
Ha
Chris_Sainty:
I'm
Caleb_Wells:
ha.
Chris_Sainty:
all out of keystrokes at the moment. So if I'm talking, I'm absolutely fine. I'll do that till the cows come home. But yeah, let's just start. I'm avoiding typing at the moment as much as possible. Outside
Shawn_Clabough:
All right.
Chris_Sainty:
of code, of course.
Shawn_Clabough:
Okay. So I think I'm gonna move us into picks now and we can wrap up. So Caleb, what's your pick?
Caleb_Wells:
Yeah, so my pick is Switch game. Now, surprise, surprise, right? That's one of my mainstays. So my son has gotten big into Minecraft lately, which is not the Switch game I'm gonna pick actually. But in Minecraft, you know, you have mods. Those mods are dependent on the operating system, and there are a lot more for PC than there are for... Switch or Xbox or whatever And he's gotten to one called pixelmon. He watches it on YouTube and it's Pokemon in Minecraft He's like I really want to play that well We ain't got it. So he and I actually started playing the latest Pokemon game Pokemon Legends Arceus And it is a lot of fun to play with your kid I mean switch games in general a lot of people play with your kid Chris You're gonna love it when your when your son gets older
Chris_Sainty:
Hahaha!
Caleb_Wells:
But that's my pick today. Well, if you're like me, if you're anything like me, you're gonna love it. Is the latest Pokemon game on this web.
Shawn_Clabough:
Okay. So my pick this week is gonna be temporary email services. I've been trying out
Caleb_Wells:
Ah!
Shawn_Clabough:
various different software services and things like that, and I'm tired of giving out my own email address for all these things, so I found out that there are services out there where you can say, I just need an email service just for 10 minutes or a couple days or something like that. And so these really were... work well for these trial offers or things like that that you want to sign up for. The one that I was using was tempmail.org, temp-mail.org. But there's other ones like 10 minute mail or e-forward or something like that. So all these, so, you know, can I give you an address that you can just use it and then throw it away? So that works for me. So my pick is temporary email services. Yep. All right, Chris. Do you have a pick?
Chris_Sainty:
I do, yeah. I was saying before the show about how much I was fretting about this, because I couldn't think of anything. And literally, as Caleb was saying here, something popped into my head. So as I mentioned, I've been doing a lot of CrossFit recently. And one thing that's highlighted to me, as I think it's probably the same for most programmers, is because of the amount of time I spend sitting in a chair, how inflexible I am and stuff like that. So there's an app called GoWod, which is a app to help you stretch. that I'm using, which is fantastic. So you sign up for the app and everything, and then it gives you a load of stretches to do to test your flexibility. You record everything in the app, and then it gives you a rating for all the various parts of your body about how flexible you are and where you need to work and all this kind of stuff. And then every day you can do a stretching routine. You pick a time amount of time, like, you know, depending on what. how much time you've got that day. So five minutes, I think it's like five minutes, 11 minutes or 20 minutes or something like that. And you can, it will then give you a set of exercises, stretches to do that are tailored to your weak points. And then after like six weeks or something, it prompts you to test again and then you can, you know, see how much improvement you've had. And if you are someone who then also does CrossFit, you can tell it like, oh, I'm now going to go do a CrossFit session and it will give you like the warmup stretches to do. And if you can type in the things you did in that CrossFit session and it will tell you the cool down stretches to do and stuff like that. So that will be my pick. That's been a real good one for me. And like, yeah, sorting out my tight hamstrings and stuff. So that's really good.
Caleb_Wells:
Very cool. I'm gonna check that one out because I'm definitely inflexible. Ha ha.
Shawn_Clabough:
Okay, Chris, if our listeners have questions, what's the best way to get in touch with you?
Chris_Sainty:
Yeah, so you can reach out to me on Twitter. I apologize. I'll apologize again right now that I've like not tweeted for ages because I've just like been so like not involved in social media for a while. But yeah, definitely Twitter also is chris underscore sainty. But if like there's various ways you can get hold of me and if you're unsure about anything, then probably the easiest thing to do is go to my blog, which is chrissainty.com. And then from there, you can get to like my GitHub, you can get to my LinkedIn, you can get to my. Twitter, there's a contact form on my blog as well. So like you can get hold of me through one of those ways through those things. So yeah, that's probably what I'd suggest.
Shawn_Clabough:
Okay, great, great. If our listeners have questions or feedback for the show, we'd love to hear from you. They can get me on Twitter, Iamat.net, superhero.
Caleb_Wells:
and I'm at Caleb Wells Kits.
Shawn_Clabough:
Thanks everybody and thanks Chris. It was great to have you back on the
Caleb_Wells:
Yeah.
Shawn_Clabough:
show. Love to do it again.
Chris_Sainty:
Yeah, my pleasure. Yeah, I'd happily make it a hat trick.
Shawn_Clabough:
All right.
Chris_Sainty:
So yeah, that's cool.
Caleb_Wells:
Yeah.
Chris_Sainty:
Thank you.
Shawn_Clabough:
Awesome. Thanks everybody. We'll catch everybody else on the next episode of AdventuresIn.net.