In this episode we dig into a few technologies that can be used together to great effect. We have discussed Backend for Frontend (BFF) before but in this episode the focus is a bit different. As it turns out, an awesome acronym like BFF gets reused. Setting up a BFF works well with the new minimal APIs that were included in .NET 6. Then we tie everything together with Darker, which is similar to MediatR, but with minimal configuration and features built for BFFs. We had a lot of fun discussing this tech stack with Jonny Olliff-Lee and hope you have just as much fun listening to it. In the episode we ask our listeners to help us with the best way to say BFF. Listen to the episode and let us know on Twitter at @dotnet_Podcast.

Hello and welcome to another episode of Adventures in.NET. I'm Shawn Claybo your host and today with your co-host Caleb Wells. Hey Caleb.

 

I think I'm still a co-host, maybe?

 

Yeah.

 

Possible? Hey, how are you, Sean?

 

Good, good. Did you hurt

 

Good.

 

yourself? I see you're wearing a brace on your wrist.

 

Just no, I know just being a developer right and Sometimes my wrist

 

Yeah.

 

just you know, I aggravated or it's irritated

 

Carpal

 

And

 

tunnel.

 

so I just wear this to yeah, I don't know that I quite have carpal tunnel. I think I just overextended some my wife actually had to get the like injection in her wrist

 

Oh.

 

like a month ago Because it was really bothering her but you know, we both we both sit at a desk and keyboard all day, right? So, you know, right? The price you pay.

 

Hahaha

 

It's all good, though.

 

typing is so strenuous on your body, I know.

 

I am telling you man, by the end of the day I'm just worn out. I just need a nap.

 

Okay, let's welcome our guest today. Welcome, Johnny Olafly.

 

Hi guys, yeah!

 

Yeah.

 

Yeah.

 

Evening guys, or evening for me, morning for you guys.

 

Yeah, it's...

 

Yes, so you're in England, right?

 

Yeah,

 

Or Great Britain, or... Yeah.

 

yeah we've, yeah, England, Great Britain, different things,

 

Yeah.

 

but yeah, in both of them at the moment.

 

Yeah. Yes. Yes. Cool. Yeah,

 

Yeah,

 

we

 

so

 

were

 

Johnny.

 

actually talking a little bit. Go ahead.

 

Yeah, so Johnny, why don't you get us started. Why don't you tell us a little bit about yourself, how you got into development, how you got into.NET, what kind of things you work on.

 

Yeah sure, so I started getting into development back at school, so when I was about 16, because we have different things here, so I think that's high school, all right,

 

Yep,

 

Mm-hmm.

 

yep.

 

Yeah.

 

and started doing computer science and computing at school, started learning VB6, really enjoyed it, went on to do computer science at university and then ended up being a developer full-time, so about 15 years ago. I started off with Java, thought it was great. Didn't understand why people did.NET. Then started dabbling

 

Ha ha.

 

a little bit of.NET at work. Understood why people did.NET, didn't understand why

 

Hehehehe

 

people stuck with Java.

 

I'm right there with you. I had the same experience. Yeah. Yep.

 

Yeah, especially those early days of Java that just really

 

Yeah.

 

struggled with all the virtual machine things that you had to install to get

 

Yeah.

 

things working there. Yeah.

 

beans

 

Yeah,

 

and like

 

I reminisce

 

12

 

of like

 

template

 

Node.

 

levels down. Yeah,

 

Yeah.

 

no.

 

I get flashbacks

 

Anyway.

 

now with anything to do with Node and like coming like Node virtual machines, I'm like, no, what's going on? But yeah, no, I then switched to.NET about 10 years ago, so full time and stuck with it ever since. Yeah.

 

What kind of things you typically build in.NET?

 

So more recently mostly APIs and microservices or backend services, pure backend dev for the last five years or so. Before that was a bit more full stack and I never really enjoyed doing front end and so I took a backend job and was like, oh yeah, this feels much more natural until Blazor came along and then I went, now I can get back to the front end.

 

Yeah.

 

Um

 

But you know, us front-end people, we're a little weird. I'll openly admit that.

 

I said

 

Yeah,

 

we would smite

 

I think.

 

my... oh it's okay, sure.

 

Oh no, I was just going to say, I think a lot of people that started out early in the NET days were full stack developers.

 

Mm-hmm.

 

You know, there really wasn't

 

Yes.

 

too much, you know, people that could specialize in front end and back end and things like that. So you kind of had to know everything.

 

year. Yeah, especially those early ASP.NET days or classic ASP days, especially as well, like, you know, actually minimal JavaScript and mostly still just writing C JAR code inside HTML. And now we've got a full circle

 

Yep.

 

to Blazor.

 

Right. It's a beautiful

 

But

 

thing.

 

yeah, so yeah, it is Blazor. I was listening to your episodes with Chris Sainty. And I was

 

Oh yeah.

 

just like, I actually ended up going to buy his book. Because like yeah, I need to find all the things I don't know about Blazer that he's clearly spent a lot of time writing

 

It's a really good book. Yeah, I have it myself and have used it to spend some of my lunch and learn at work. So yeah, it's good

 

Nice.

 

stuff. Yeah,

 

Yeah. Yeah.

 

yeah.

 

Cool.

 

So I think

 

Okay.

 

today we're going to talk about minimal APIs and BFFs.

 

Mm-hmm.

 

And I'm assuming

 

Mm-hmm.

 

this is not your best friend forever BFF, right? Right?

 

No, but there are a few BFFs when talking about BFFs. Mostly.NET

 

There you go.

 

Minimal APIs and

 

Yeah, so let's start off with what BFF is, or I've also referred to it

 

Yeah.

 

as BEFE.

 

Yeah, yeah, yeah. Yeah, so it seems to have a few different acronyms. So yeah, BFF or backend for frontend is basically a little application or sit in front of several APIs or a single API and gives you a sort of an interface for your frontend to talk to it for several reasons. So you might have an old API that you're trying to retire. and you have a brand new API, and your BFF will mimic your old API, but actually be talking to your new API and do a sort of translation in between. But equally you could have the BFF being a GraphQL API, and that GraphQL API is actually just talking to a bunch of REST APIs, as they can sort of translate between different APIs. And I think something that when people start doing BFFs, they kind of go, oh, it's a backend thing. Like, oh, the backend developers need to build it. Get your front-end devs to build them. They know what they want. Back-end APIs are there. Your front-end devs know exactly what they want. They can build it for you, and they can build it in whatever technology they want. And then they've got full control over it. And it's for you, as a back-end developer, it's just another client to your API.

 

Is it kind of an adapter?

 

Yeah, in like hexagonal architecture terms, it would be kind of an adapter. It's possibly a little bit outside of that architecture though, so it's a little more sitting on the edge, on the boundary. And I would probably say that you'd normally deploy it separately and scale it as you need it, especially in sort of cloud terms. But you could equally have it as an adapter that just calls

 

Yeah.

 

into your system.

 

Or in microservice architecture, it kind of be, would be the API gateway.

 

Yeah, yeah, exactly. Yeah, yeah.

 

You know, and I think it's used to describe a number of things, because I know that the Dwinday also has BFF as part of identity server for like Blazor

 

Hmm.

 

or Spas that handles some

 

Mm-hmm.

 

of that, the security and have an abstraction or an adapter, right? To make sure they're more secure. So yeah, it's not a term I heard a lot before the last year or two. But now it seems

 

Mm-hmm.

 

to be much more ubiquitous, right? So.

 

Yeah, I started using them right at the start of my last job, actually, so late, no, sorry, early 2018. And they were already building

 

Okay.

 

some BFFs in Python. And that was an API transition style BFF. They had one service that had the old API, and they wanted to move the API to a new service. But updating their mobile clients, especially, was hard work. So I'll see. people actually need to physically go and update their app. So they could decommission the old API, they built BFF in front of the new one, and then allowed those people to update their apps in time. And as we saw the traffic drop off, going to the BFF, we can kind of go right now, we can get rid of it. We never actually got that to that point, we never got rid of it, it's still there. People don't update their apps. But yeah,

 

Mmm, yeah.

 

so that was my first usage of it.

 

And before we move on to minimal APIs, Sean got me thinking, if you're listening to this podcast, let us know on Twitter whether you prefer BFF or beefy. Because I kind of like beefy. I'm OK with that. Yeah, anyway.

 

I forgot about Bifi actually, I remember now when someone did like a lunch and learn on BFS at work and they kind of did like all the different acronyms and Bifi was in there, I completely forgot about Bifi and it has all the right letters as well which makes me happy.

 

So is the reason for having a back-end for front-end, is it just when you're trying to switch from an old version of something to a new version? Or is there a reason to have that for a greenfield application?

 

I think the Greenfield, I think it's limited usages for it. But it's something to just bear in mind. It's always something you've got there. And it might be that actually a Greenfield application needs to borrow from other applications. And you might be starting off and go, right, we've got one API out in our Greenfield, but actually to make this kind of workable and usable, we need to borrow something from somewhere else as well. So let's spin up a BFF and chuck it in there and until we actually expand out, maybe supplementing data from like a third party that you're kind of like, we will do this ourselves eventually, but right now let's actually just hand that off.

 

And it's best practice to have your back end for front end pretty lightweight. It's just basically kind of a pass through to something behind it, right?

 

Yeah, exactly. I mean realistically probably shouldn't have, I mean other than a cache, which obviously would be pretty useful for support formats, there shouldn't really be much data being stored in it. It should just be passing through requests and sometimes it might have to, as Caleb said earlier about authentication and stuff, it might have to do like something along those lines but certainly shouldn't be like a full-blown like application with lots of data being stored. It's going to be pretty lightweight.

 

OK, so then how does that fit into using minimal APIs? You know, minimal APIs are really new to.NET. So first, get us started with those that haven't been on the latest.NET versions to be able to take advantage of minimal APIs. What are those, and why are they better than controllers and other endpoints that we're used to?

 

Yeah, cool. So middle APIs are obviously new to.NET and came out in.NET 6. But they've actually been around in other languages for quite a while. And I always kind of get poked by that by my friends who do JavaScript. Because like, oh, nodes have this for ages. And I was like, yeah, OK, cool. But we did. We got it now. So we're now happy. And the same with Python. So like you got Node.js is the standard like routing. And in Python, you've got Flask and it's that kind of very lightweight. you have a single line that defines an endpoint and then a function that actually does something. In.NET 6, this was brought in at the same time as the really lightweight program.cs templates, which have nothing. There's no braces anywhere. It's like straight in, there's no public static void main args. It's just like you're straight into the code. So you can go straight in and you have to start host. NET, well from.NET Core onwards wasn't it, it was the host builder. You can just do app.get and then your URI, and then it takes a function, and that function is your code.

 

be honest, the minimal APIs in.NET, right? I haven't used them, but I've spun them up and looking at it. I'm like, this is just weird. It's all just in program.cs, and they're just one-liners. I'm like, how can you even use this, right? But of course, you know, I'm coming

 

So.

 

from the old school way, right? So. OK.

 

Yeah, and that's really a segue into why do this rather than controllers. And the one thing is you don't have all the ceremony around controllers, kind of like the root part of the controller, the attribute, the annotating controller, kind of like this is the root and then annotating, HTTP GET, and this is the thing. You don't have any of that ceremony. You don't have any additional classes. It's just you're just straight in. And it promotes the use of thin controllers. over fat controllers. You know, your controllers should have no logic. They should be on the outside of your application. They should be tested end to end, but not like you shouldn't be unit testing your controllers. They shouldn't be doing anything. And so.NET Minimal APIs is as soon as that sort of program.cs is getting too big, you probably, your Minimal API case is gone then. Let's start using controllers. You've gone past it. But if you can keep those like one liners of kind of like... get this, get users, and then you just kind of go lambda expression, query process, or which we'll get onto in a bit, query, get your execute query, get users, and then there's one line, and it just returns that straight back out, getting into a resource. And you can still inject things into it, so you still got all the dependency injection framework you've got there, but you've got no constructor, you've got no bulky methods, you've got no annotations. It's very clean and as the name suggests, lightweight. Hahaha

 

So when you're doing a minimal API using back-end for front-end, like you said, if your program CS is getting too long, then it's really not minimal anymore. But what is your, I guess, what's your max or where you're trying to do this adapter to your old stuff with a minimal set of APIs? when have you gone off the rails maybe isn't the right term but but it's no longer meeting those criteria from a from you know a production standpoint right you want to keep it simple.

 

So I think realistically there is actually no max. It's kind of like

 

Mm-hmm.

 

actually how you then divide up what APIs are in each one. So

 

Okay.

 

let's say that you're actually, you've got quite a wide API service that you need to cover with your BFF, or maybe actually certain subset of those APIs get used a lot more than others. So actually that might be a separate application that you can scale out horizontally. and the others kind of just sit there and maybe like one container, two containers, whereas the other might scale out

 

Bedankt.

 

to several containers. So actually it's kind of like maybe not that BFF is not appropriate, it's just how much you're putting into each BFF. It becomes your criteria and that's

 

Gotcha.

 

just down

 

Okay.

 

to you knowing your application.

 

So something you've used, and it seems like you use this a good bit, is called Darker.

 

Mm-hmm.

 

Can you tell us a little bit about it and its counterpart, Brighter? Darker and brighter,

 

Yeah,

 

there you

 

of

 

go.

 

course. Yeah, so.

 

That's very, that's genius.

 

So yeah, that's Ian Cooper's naming conventions there. So going back again to what Chris was saying about CQRS and he was saying that he's recently been looking at CQRS and Mediator. So brighter and darker are actually break that apart and brighter as the command side for CQRS and darker as the query side of CQRS. And if

 

Okay.

 

anyone hasn't listened to those episodes, CQRS is Command Query Responsibility Segregation. and breaking apart the things that do things from the things that fetch things. And that's the split between brighter and darker. Brighter does things and darker fetches things. Brighter is also actually a lot bigger. Brighter is the best described as mediator plus end service bus or mass transit or any of the other external bus style libraries. So it can be just used in process on its own. that's absolutely fine, but it also can be used to send out to Azure, AWS, SNS, SQS, Kafka, Rabbit, all those as well. So actually doing sort of event driven architectures as well. So it can be actually expanded. But Docker is very simple and it's very much like mediator in that you say, I have a query and I want to execute that query and I want to get something back. And essentially it does that. It does it in a pipeline so you can wrap. the handling of that query with like log extra logging or caching or anything else. And you basically build up a pipeline of things that execute as they go in and then they come back out again.

 

Could you give

 

So, it...

 

us without without giving you don't have to give away any trade secrets or any company stuff But what's in what's an example where you have done this for one of your projects?

 

So basically all of our microservices normally had a set of APIs in front of them. And you obviously have like put, post, delete APIs, and they would all trigger commands with brighter. And then darker would be then used to on all the get APIs. And they're basically darker. What got returned by darker would be what we call query models. So they'd be technically different from our actual entities. Whereas Bright would be dealing with actually fetching our entities, updating them, saving them, deleting them, et cetera. And so it's literally that sort of CQRS style of just changing data, fetching data.

 

With Docker, like you said, there definitely seem to be some similarities to Mediator. It's got an iQuery, iQuery handler.

 

Hmm

 

But something I noticed in your post is it's got some attributes, result converter.

 

Yes.

 

And that was different for me. What is the intent of that, or what does it give you when using Docker?

 

So yeah, so I haven't used mediator that much, so I may be wrong here, but I'm fairly sure that when you configure stuff in mediator in that sort of pipeline, every single call you do in mediator goes through that same pipeline. The attributes that we use in Docker are actually per handler. So it is a choice for you to put it in there. And so like in the example in my post about the result converter, I'm using it as a... concept of the old API just returned 200, everything was a 200. In the new API it was 200, 201, 202, depending on what the circumstance was. So that result converter was kind of going rather than every single query handler kind of going, right, now I need to convert my 2xx response to 200, I'm just going to have an attribute on the top that basically kind of goes, taking the output from my handler. and do the correct conversion. And then it's just a one-line annotation on your method rather than having to duplicate that code over and over and over again. But equally, if you don't want to do that somewhere, you just leave it off rather than having to create an entirely new pipeline for that purpose.

 

Yep. One of the projects I worked on recently was using Mediator and it was already there when I first came into the project and had some familiarity with it, but never used it. And it took me, it was just so confusing

 

Yeah.

 

when I first started trying to figure out where is the flow of data? Where's the processing going from here to here to here? Because the request came in and it's like, okay, where did it go? It's like, because you're trying to trace down references and things like that. It's like, no, it's. You can't just do it that way. You know, it's it hands off through the pipelines and so on and so forth. So because I'm so old school on on my mental processing, I still have a four eighty six for a brain or something like that. It took me a little while to take to get the grasp of, you know, how that thing was working. But it is cool, you know, once you get that kind of structure down, it's it is very handy. So it was good that Jimmy

 

Don,

 

Bogard came out with that.

 

Hmm.

 

you're not the only one,

 

Yeah

 

right? Because I think we've talked about this in a previous episode, and I said, media is great if you're disciplined and using it the right way. But if you don't, it can

 

Yes.

 

really bite you

 

Yes.

 

in the ass, for lack of a better

 

Hehehehe

 

term, right? And you're like, don't let Jimmy hear that. It won't, right? It's

 

Yeah

 

not Jimmy, it's how you're using it. And we're using it at my work on some of our APIs, but it wasn't used the right way. And so on top of the complexity or the confusion with media in general, not using it in the right way makes it worse. So I ended up having to do a lunch and learn where I brought everybody in and said, okay, you want to get to this, right? You want to start from the beginning and find out the date you're returning and how it's, and I had to step them through. Okay, here's your filter query and then here's your result head and here's your query handler and here's, and after an hour they're like, oh, okay. So now we know how to get what. what we need to. Alright, without that, yeah, you're kind of fumbling around the dark. So, yep.

 

And I think Jimmy, from blog posts I've seen and Reddit posts I've seen of his, he'd be the first one to admit that he'd be like, Yeah, if you do it wrong, then yeah, you're going to cause yourself a world of pain. I can't help that. All I can do is explain how you

 

Yeah,

 

should

 

totally.

 

do it.

 

Yep. Right. Yep. So with your result converter, I notice you're doing, and you mentioned this, right? You may want to return something other than 200. You're doing created responses and accepted responses and an OK response or result. And you're using a switch, which I find, honestly, it's smart. So with that, with your result converter, You're then using a switch to determine which result type to return, right? Okay. Okay. Gotcha. Cool. Yeah.

 

Yeah, I mean,

 

That,

 

Hehehe

 

that

 

that's largely

 

allows

 

also

 

you a lot

 

thanks.

 

more flexibility.

 

Thanks. Yeah, and

 

Yeah.

 

it's the new style switch as well. Like the new style switch gives you so much flexibility in that because you don't have to put in every case. It is a lot more terse in the amount of code you have to write.

 

Yes.

 

And you can just do wild cards and discards and kind of go, actually, they're what I only care about the two XX ones. Anything else, just just pass it straight through. So it gives you a really I kind of went for a bit more in-depth ones for the demonstration. But like Newstyle switch gives you so much flexibility with that

 

Yep.

 

and

 

Yeah.

 

I end up using them a lot.

 

It's something I haven't used a whole lot up to this point, but like you said, yeah, you look at one and they're like, man, that's clean. So yeah.

 

So how do we put it all together? We start out with minimal APIs, we've got backend for frontend, we've got brighter and darker, all that kind of stuff. What's kind of the use case? The simple, this is how you use it, put it all together to come up with something.

 

Yes, I think actually one of the easiest ways of playing around with this is something like a third party API, like a weather API or something like that.

 

Mm.

 

You want to bring in your own sort of thing into a blaze replication. And so you don't need that many endpoints for it. It's basically going to be probably a few gets to get whether for a city or whether for an area or something like that. So you write out your minimum APIs, and then you write your darker query handlers to actually then go off and call that third party API, and then bring back the data, form it into a response type that you want for your application. Maybe, especially like weather APIs, they're really detailed, there's a lot of information in there, and you just wanna cut it down to like, I want the temperature, not wind speed and. Humidity and I just want temperature and then so you just in that query handler you use an HTTP client You make call out third party API bring it back and then you just turn convert that into response Your darker handler returns takes in one type of object returns another so you create your return type which would be like, you know Temperature or just a property called temperature you set the value kick it back out and then in the back in the middle of API You just go return Okay, and then the result of your query and then you're done and then dotnet handle the rest

 

Yeah, looking at your program.cs. So I've read your article, right? And some of it made sense to me and some of it didn't, because I haven't really dealt with this. But now looking at your old API, and I'm using quotes, right? Because you're using a new and old. Because like you said, you're using open weather as kind of a test.

 

Yes.

 

But I get it now. You've got the app.mapget, which is your mental API. You're doing the route of weather. You're passing in information from the query, but then you also have a from services, which

 

Yes.

 

is, I'm assuming it's the dependency injection, to inject

 

Yes.

 

your iQuery processor, which allows Darker to pick it up and then process it based on whether it's the old or the new, right, how it needs to handle

 

Exactly,

 

it. Very

 

exactly.

 

cool, okay, very cool.

 

Yeah, so

 

See,

 

that's

 

I learn something new every day. Yeah, go ahead.

 

the front services bit is the weird one. That's the one that normally catches people out with mineral APIs

 

Yeah.

 

because you have no constructor, you have no way of injecting

 

Right?

 

things per thing. So yeah, they provided a little parameter attribute for you to actually inject things into each call. So it's not even everything one, you can change that could be a different one per mineral API.

 

Very cool, yeah. I can see how this would be really useful. Maybe not while I'm working. Because we've got a lot of old stuff and very little new. But no, I like it, yeah, very cool.

 

It's definitely a tool to have in the toolbox. Like you kind of go,

 

Yes.

 

oh, actually, like, especially Alton U is actually a really good one as well. It's like, if you've got an old monolith

 

Mm-hmm.

 

and you want to break, and you've

 

Hmm.

 

got to the point where you've got to go, right, we need to break this up now. We've got teams expanding, the number of features expanding. This is not working anymore. Let's break it up. You can still, you can use that sort of BFF to kind of go, right, well, we'll put BFF out. And then as we move new APIs out to their services, the old, the BFF is still there and it'll either direct us back to the monolith or direct to our new services. And then once everything's sorted and the monolith has been broken apart completely, we can then remove the BFF and our new APIs will handle it. But until then, we don't really want to start routing stuff either like at the infrastructure level, which I've seen some like, especially if you're running on older stuff, you're running actually in IIS and having to do rewrite rules with like my

 

Yes.

 

new services, like This API goes to this new service, this API stays here, this one goes to this new service, and your rewrite rules is going, da, da, da, da, da, da, da, da, da, da, da, da, da, da, da, grow and grow and grow. Having a single

 

It's.

 

service where you can kind of go in and look at that and go, oh, that's where.

 

It's interesting you mentioned IIS, because I know Sean still deals with that some with web forms in his still

 

Yay,

 

side job.

 

web forms.

 

We're not sure

 

Uh.

 

what to call it.

 

Hehehehe.

 

But we deal with it a lot still too. We actually just got the OK to start moving towards the cloud. And when we heard that, we started talking. Oh, so what are we going to do first? Or we could do blob storage? Or we're going to look at functions? Oh, we need to do some logic apps. Oh, Key Vault's an easy one. We only need to, you know, right? We're. We're going down that, but now we're in the position we have to pick one and all agree and determine how we're going to do it, right? But yeah,

 

Yeah.

 

IS, oh my goodness, it's

 

I'm

 

a piece

 

sorry.

 

of work.

 

So I started a new job back at the end of June. So I've only been there for five months

 

Yeah.

 

now. And I came from

 

Yeah.

 

an AWS world where we had EC2 instances running Windows,

 

Okay.

 

running IIS, change job, Azure or Azure

 

Yeah,

 

depending on whether

 

yeah,

 

you're British or American

 

right, right.

 

and running app services, which if you deep, deep, deep down, it is a Windows VM somewhere in. an update center running IIS, but you don't see any of that. You just have a console. And jumping from those two, it's like,

 

Hehehe

 

what happened

 

Ha ha!

 

here? Why can't I just go and restart my app pool? Oh, I can, I just need

 

All

 

to

 

right.

 

do it at the right level in the console. And it's quite weird, it's like, oh, how do I get my logs? Oh, they're in application

 

Yep.

 

insights over there. And like,

 

Thanks.

 

oh,

 

Yeah.

 

it is a huge, huge leap. But once you do make it, it's like, This is really, really nice.

 

Yeah right it definitely simplifies a lot of things until you get to the point where you don't need that simplification. You've got an edge case or a weird buck and it's not being caught in logging like you said you can't and then you got to figure out how to dig in but for right 98 99% of the time it's like oh thank goodness yeah yep.

 

Yeah, I've been there recently with a function app.

 

Yeah. Oh, yeah.

 

It was so painful. But yeah, got there in the end. But yeah, but they do, they've got a lot of tools that you can actually fire up a PowerShell terminal that's running on that box. And you can actually then actually use PowerShell to go and actually run things or debug things from within the app service itself, which is an absolute lifesaver. But yeah, 100% you can get into those issues.

 

So is.NET 7 going to change anything that we've talked about today? It's going to stay the same.

 

Not as far as I've seen. I've not had time to really swat up on.NET 7. Starting a new job is just like information.

 

Us either.

 

Yeah, I've recently started a new job too, so I totally relate.

 

Yeah, but I don't see being non a non LTF non long term support version of dotnet. I don't think they were going huge on the new feature branch, new features and stuff. I know performance is improved, especially in around JSON parsing. The system text JSON now just outstrips Newton soft by seven times or something in serialization, deserialization. I that's I. Yeah. But yeah, not for minimal APIs as far as where they've not done anything groundbreaking. I think they're still waiting for people to adopt it a bit more and actually give their feedback on it. I mean my feedback is just two thumbs up.

 

Yeah.

 

Nice one Microsoft.

 

Yeah.

 

A little bit well done for catching up, but well done.

 

Well, you know, as far as I'm concerned, they've been on a roll for like the what, the past three or four or five years. They just,

 

Yeah.

 

once they made the decision to move away from.NET Framework, been like, yeah. Right,

 

Yeah. Yeah.

 

so, yeah.

 

And there's that slight iffy period around.NET

 

Mm-hmm.

 

Core

 

Mm-hmm.

 

2 and.NET between 1.1, it's

 

Yeah.

 

like, are they gonna stick with this? Are they actually gonna put their support behind

 

Right.

 

it? And then they did. It was like, we're good,

 

Right.

 

we're good.

 

Yep.

 

Well,.NET 5 is kind of like the third release to me in my mind, it's always Microsoft, the third

 

Hmm.

 

release is usually the best. You had.NET Core 2,.NET

 

Yep.

 

Core 3,

 

Yep.

 

and then now.NET 5, that's where,

 

Yeah.

 

okay, now I can use

 

Yeah.

 

it.

 

Yes. Yeah. I feel they kind of just wanted to get to the point where they got past four, so they could drop the core and like, we just need to get there. We just need to get there and call it.net. Ha ha ha.

 

Do you know what's so funny is this is two jobs ago, but we actually started developing a new application with.NET Core 1 release candidate and Angular release candidate. Because

 

AngularJS.

 

we were like,

 

Oh.

 

we're, yeah, we're, no, yeah, the replacement

 

or Angular

 

for

 

2.

 

AngularJS.

 

The original.

 

It was Angular

 

Oh.

 

1, right? Yeah. And, or Angular 2 version 1, or whatever, right?

 

Yeah, yeah.

 

But yeah, we were like, we're right there. We don't want to all use old stuff. So yeah, we started and it worked, but yeah, it's come a long way.

 

Yeah, yeah. And the Microsoft documentation, I think, has also massively improved

 

Mm.

 

along with all this stuff as well. Like it's less and less I'm having to go to other places to learn things. I can go and read their documentation, especially learn.microsoft. That is huge. There's so much information there now. That's vastly improved from when I started learning.NET and kind of just learn everything off stack over.

 

Okay, Johnny, so what haven't we talked about that would be good for what we're discussing?

 

Errrr... Question! I guess I mean to be honest, really just like if people are interested, just go and play if you're using Mediator give brighter and darker a shot

 

Yeah

 

and see if we can lure you away from Jimmy's world but yeah, I think with especially minimal APIs I think we're so ingrained in the controller way of doing things just take that leap of faith and go, do I actually need a whole class to do? Not very much.

 

Right.

 

And especially if you're looking to get

 

Gotcha.

 

away from your fat controllers and go to thin controllers, take a look at.NET Mineral APIs and enjoy.

 

I mean, this has been a good discussion. We're gonna learn all kinds of fun things today. Ha ha ha.

 

I think as I was listening to this, when Michaela sent me an email originally, I was like, I should go and listen

 

Yeah.

 

to a few episodes first. And I saw Chris saying to you ones about Blazer, I was like, right, listen to those ones first for sure.

 

Thank you.

 

And then I was listening to them and just kind of going, yeah, this is really good. I'm learning a lot here. And I haven't even bought his book yet. I'm learning stuff. This is great.

 

Awesome,

 

So yeah.

 

good. Now, hey, we're glad to hear that, right? We have a lot of fun doing this, but we want to be fun and educational. So that's great.

 

Yeah. Nah, keep up the good work, it's awesome.

 

Thank

 

All right,

 

you.

 

Johnny, so far listeners have questions and they wanna get in touch with you. What's the best way to do that?

 

If you can get me on Twitter at DevJohnny, so D-E-V-J-O-M-M-Y. I don't tweet a lot, but I will respond to messages and stuff I do check in. Equally, I'm on GitHub at the exact same username. Brighter and Darker Forums, so I'm a contributor on Brighter. So in there, we try to use the discussion boards and everything on Brighter. Again, you can tag me on there and get hold of me. Yeah, that's all on Medium. Yeah, on my Medium posts as well. Again, I don't post much on Medium. It's when something comes to me and I go like, I should really write this down, which is what happened with this one. So yeah, any of those. But I'm Dev Jonny on most things. It's usually me.

 

All right, cool.

 

Cool. Very cool.

 

If our listeners want to get in touch with the show, they can get in touch with me. I am on Twitter, I am at.NET Superhero. Give us some feedback. Let

 

Dun dun dun dun!

 

us know what you want to cover. And yeah, wherever she go. If you've got something to talk about on the show, you want to be a guest, let us know.

 

Yeah.

 

And Caleb, where are you?

 

Oh yeah, um, um, at Caleb was codes and it feels like forever. It's just, I've been able to do Dun Dun Dun. Dun. So I had to get it in there. Right.

 

hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahah

 

Yeah, Halloween's just over, you know. Had my cape

 

Yes?

 

out,

 

I

 

you know, it was that.NET superhero

 

don't know.

 

costume. Nobody knew who it was. So. Yeah.

 

You know, it's funny because, right, I was taking my son to school on Halloween, and he was dressed up and everything. When you get out of the car, he's like, Dad, I really wish you had dressed up. And I'm like, well, son, I am dressed up as a software architect.

 

hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahah

 

So, yeah. Yeah. There you

 

Excellent.

 

go.

 

Yeah, because

 

Alright.

 

obviously tonight over here is fireworks night. Or, so we run from Halloween straight into fireworks night, which is celebration of the

 

Oh,

 

Gunpowder

 

yeah.

 

plot. I have no idea if anyone actually outside the UK knows what that is.

 

That's cool.

 

But

 

Okay, now.

 

yeah.

 

Okay.

 

Yeah,

 

So we have

 

well,

 

a

 

Very

 

we've

 

cool.

 

got

 

celebration.

 

we've over here. We've got our US elections here coming in a couple of days. So

 

Oh yeah, you've got your midterms. Yeah.

 

I wish I could look into the future. You know, this show will come out after the elections are over. So I wish I could, you know, let everybody know

 

Yeah.

 

how it went. But I can't do that. But I do know

 

the

 

that I'm going to win one point six billion dollars tonight. So in the lottery, so it's powerball.

 

Sean, if that happens, can I get a million or two?

 

Hehehehe

 

Can you hook

 

Ha ha ha

 

a brother up? Ha ha ha. Hmm, good deal.

 

Okay, let's move into picks. Caleb,

 

Yep.

 

what's your pick?

 

So my pick is one of the new, fairly new shows on Amazon. It is called The Peripheral. And I was aware of the book, never read it, but you know I saw the trailers. And you know don't don't go into this thinking too much, right? It's an action, adventure type thing, right? I mean yeah there's there's some interesting stuff there but I think it's well done and it's got a good cast and it's, I'm enjoying it. So the peripheral.

 

All

 

Thanks.

 

right, cool. Johnny, what do you want to have for your pick? More picks.

 

I was going to do one of my favorite bands which is Sabaton which is a Swedish heavy metal band that sing songs about history. All their songs are sort of based in history. Mostly it's of like their last two albums were both about World War One and they find amazing stories that like loads of people just don't know about and make songs about them. They basically talk about them. Last year they released a song about the Christmas Truce. in World War One, which is an amazing, amazing

 

Ah,

 

song.

 

yeah.

 

Yeah,

 

Cool.

 

so yeah, that's Saviton would definitely be my pick.

 

All right, cool. I got a couple of picks today, but they're kind of related. So it's kind of like one and a half picks. So they're also Visual Studio Extensions. So Mads Christiansen, a past guest on the show, came out with a recent extension called Rainbow Braces. And you think, you know, I don't really need that. I've got. bracket colorizer or you know when I select a certain bracket it's going to highlight the matching one but it is so handy to have every matching pair be different colors of the rainbow that you can pick that this this extension is really handy and related to this one and kind of where he got the idea is an extension called VSFora and it VSFora has the rainbow braces in it but it also does other keyword highlighting, XML improvements, and even telemetry type stuff. So if you just want rainbow braces, check out MAD's extension for that. But if you want something that's a little bit more, check out VS4. And they're both in the VideoStudio Marketplace for extensions. So they're all easy to find. So check those out.

 

Awesome.

 

Alright.

 

I say I'm a Rider user.

 

Yeah, yeah,

 

Yep.

 

I tried it.

 

Hahaha

 

I tried. I've been trying to come up to speed with it, and I just haven't had enough time to to go in there.

 

You know,

 

It felt like coming

 

I'm just

 

home,

 

being cheap.

 

coming from Java. HAHAHAHA

 

Ah.

 

Yeah, yeah.

 

All right, I'm like, I just don't want to pay for the subscription. Ha ha

 

Hehehehe

 

ha ha.

 

I've had my subscription for so many years now it gets goes a bit lower each year it doesn't go up it goes down because like the longer you have

 

Oh,

 

it

 

okay.

 

the cheaper it is

 

Yeah, right, right, yeah.

 

and I've had it for so long now yeah

 

Yeah, I've used ReSharper forever and ever. And that's kind of one of the reasons why I wanted to go to writer so I can get ReSharper, let's out of process and a little more performant and things like that. But yeah, once I started, you know, messing around with it and setting up. the material design and trying to get everything set the way I wanted. It's like, I still wasn't as fast and so I had to go back to Visual Studio because that's just where my mind is right now. And

 

Yeah.

 

so to get some projects done, I had to stay there. So, but I will give

 

Yeah.

 

it a try again. All right. Well, thanks Johnny for coming on the show. It was great to have you. Good

 

Yeah.

 

discussion. Hopefully our listeners

 

Yeah, thanks for

 

got

 

having

 

a lot

 

me.

 

of good stuff out of it just like we did.

 

Thanks for having me, it's been a pleasure to be on.

 

Great. And we'll catch the listeners on the next episode of AdventuresIn.net. Bye.

 

Bye y'all.

 

Bye.