Rob Rich offers a sharp reality check on the tension between developer convenience and long-term architectural flexibility. His insights remind us that the best templates serve as adaptable foundations rather than rigid, one-size-fits-all solutions.
Install our extension to search inside any video instantly.
AspiriFridays: Rob Rich Roasts UsAdded:
Heat. Heat.
Heat. Heat. N.
Heat. Heat. N.
Heat. Heat.
Heat. Heat.
Heat.
Heat.
Heat.
Heat.
Heat.
Heat.
Yay! Happy Friday.
I'm so excited.
>> Commercial where like the guy's on hold for forever and he's just so frustrated because he's out in the middle of the desert and then and then there's this really cool song that comes on the on hold music and then gets interrupted and then he's like, "Can you put me back on hold? That music was awesome."
>> Yeah. Yeah.
>> Yeah. No, it's kind of a kind of a >> I spent a lot of time going through like Adobe samples trying to figure out the best music for the pre-show and that's that's where we ended up. So, um, as you all can notice, Damian is not here yet because he's Damian and he's I don't know if he's like showed up on time maybe ever. Um, but usually he makes it during the countdown, so this is kind of good today. Um, and Fowler is chaperoning a school field trip, which can you imagine going on a school field trip and Fowler is the chaperon that I think they're going to the zoo. So, that's fun. But he is going to be on his phone like this turning his agents into crazy things all day. So anyways, we have Seb from the team here um because he's he's going to be the subject of quite a bit of feedback, polite polite roasting today.
Um and I think some some of the other folks on the team will pop in too and obviously Damian will show up at some point. Um but we have a very special guest. We have the Rob Rich of rob.org and a variety of other things here. Uh, and Rob has been giving us feedback for Aspire stuff for a long time. Um, and my favorite Rob story is a couple years ago at MVP Summit when we started building out the JavaScript support for Aspire at the very very early days, we locked Rob in a conference room and we're like, tell us all the ways this sucks. And he did. And then we fixed some of it and we listened to him sort of. Uh, but Rob is also like big with, you know, Kubernetes and teaches and and does a whole bunch of stuff in inn net land and JavaScript and TypeScript land and cloudnative land. And so Rob's been a really good source of feedback for us. Um, and so a couple couple weeks ago we were at Teorama Belgium and uh Rob was like, "Oh yeah, I have some feedback on the new stuff, blah blah blah." And I was like, "You know what? We're just going to put you in the hot seat and we're just we're just going to go." Uh, and it's ironic that I called this a roast because Rob is incredibly polite and will preface all of his feedback with like I might be I could have been updated. I I might be this, I might be that. Um, so it's not really going to be a roast, but it's going to be a roast in spirit, and that's what I want. Um, anyways, that's your introduction, Rob. How'd you like that?
>> That was awesome.
>> Amazing. Thank you. Um, >> yeah, my goal is to focus on kindness because if we can all just be kind, then everything else is easier. So, yeah, even in the midst of feedback, it's like the reason I'm here is because Aspire is so amazing and it's it just has a really great startup experience and it has a really great runtime. Uh, the fact that it harvests logs, metrics, and traces into a dashboard, even if developers don't get what open telemetry is, it's just a really fun product. And so it's so fun to be able to poke at the sharp edges because there aren't very many of them because it's just so cool and it deploys so quickly and it's it's a really fun product. It's fun to be here.
>> Sweet. That's it's a good thing Fowler's not here because kindness is not part of me and Fowler's stickick. So Damian is kind. Seb is Seb.
>> Where am I?
>> I'm wondering too.
you. We need to buy you a microphone.
Every time you join the stream, it makes me so angry.
>> I My headset is at work because they forced us to go back to work. I I took my headset and >> we got to get you. I'm going to bring you one. I have one that's really cute.
It's pink. It'll match your shirt.
>> Hang out next time I'm in town.
>> Should I go on the other computer?
>> No, it's fine.
>> I can't wait to see Sebastian with this really big pink headset. That'll be awesome.
>> Yeah.
>> Um Okay. As always, bingo. It's up and running. Um, oh, I have to turn back on all the Damian ones because Damian's here today. So, refresh your board in like a minute. Um, do I even know the password? Yes. I'm so good. I'm so good.
I know how to use my own thing.
>> Now, I'm curious. I haven't seen the board. What words do I get to jump through? Or is that part of the game?
Oh, you we try not to to um fix it, but it's pretty hard. So, okay, there everything's back. All the Damian ones are back. Okay, I'll call them out as we hit them. But there is I think Yeah, I think Rob your small echo might be back. You might need to turn your volume back down because I know you turn it up. So, you might want to just knock the volume down a little bit. Um, >> yeah, I did turn my volume way up.
>> Yeah. So, we'll knock that down and then >> better.
>> Where where is Damian? I need to make fun of his templates.
>> I'll figure it out. Let's start. Let's start there. You ready for me to share your screen? Ready to go?
>> Oh, and I just realized I did not turn down my volume. I turned down my brightness.
Let's turn down my volume.
I watched you type a Docker file by hand last week and you just turned down your brightness instead of your volume. So that's the type of nerd you are.
>> Oh, of course.
>> I was so mad. I was sitting in the audience and I was like, why is he typing a Docker file by hand? Like with his fingers, every letter. I understand that that makes sense and that's how you teach people things, but I was like, I have never in my life. You also typed the gate ignore by hand, which I found fascinating.
I don't >> Yeah, it's like if you can understand the methodology behind it, then you can start to use tools that make it more powerful. The analogy is a calculator.
If you don't know how to add, then the calculator will just get you to the wrong answer faster.
>> A git ignore. A git ignore. A get >> a git ignore.
>> It It was It was pretty impressive, I will say. Um, >> thank you. It was a fun presentation.
>> Yeah. Yeah. It that was you had a really good talk. I like that a lot. I actually learned a little bit about I mean I don't know much about Kubernetes so that's not saying much but I learned a little bit and I was I was pretty happy about that. So okay I'm putting up your screen. Let's start >> with the template which you have found >> a ridiculous typo which I'm very for you to call out.
>> Really cool.
>> Aspire update d- self. Let me make sure I'm on the latest. We could have deployed, you know, five seconds ago.
>> Yep.
>> And then I'll net new install Aspire project templates. Make sure I'm on the latest there.
>> That you shouldn't have to do that any more, right, Seb?
>> Does Aspire update also update the templates?
>> It should, Seb, right?
>> Why do you ask me? I do JavaScript sometimes.
>> Don't say that.
It should. Where's Jose? Are you here?
Are you watching?
>> It depends on the templates. I assume at least some templates will be updated for sure because they are part of the CLI.
The ones from the packages probably >> they should be. I thought we fixed that.
Ah, >> well, now we know.
>> Okay.
>> Okay. So, I'm going to pick the Express and TypeScript app host one because that's the one we wanted to poke at first. Um, enter the project name. I'm going to say TypeScript app host project. That sounds fine. That's the name of my directory. Where do I want to put it? In the current directory. U, should I use dev localhost URLs? Nah, they are cool. Oh, and I just hit enter, so it's going to pick the next option for me. Um, >> no. Will it?
>> Dev local host URLs are phenomenally cool, but um, I just won't use them in this case.
>> Yeah.
>> Yeah. They just make the links longer, you know, too much text.
>> And since my font size is big, then that may not work. Since all of these ones require me to hit enter at the end, and then this one doesn't, then it's like, oh, would you like to configure AI environments? That's the one that I clicked yes to.
>> Yeah, sure. I'll do that.
>> Aspy.
Um, Inspire MCP server. Eh, I'll just leave him off.
>> Okay, >> cool.
>> So, the Aspire MCP, we're going to we're removing that option because really you should just use the skill.
>> Um, the MCP was pre-skll MD's existence.
>> Yeah, >> we are going to keep the MCP as a thing.
You can set that up manually if you want, but it's just confusing people now. Um, and if we say we don't have an MCP, people are going to be like, you don't have an MCP. Even though that's like not what you need to use it for anymore. So, fun fun fact. Peak behind the curtain. 136 that oper 13 134 that option is going to go away.
>> I just love that you set up the agents and all the things. It's like to build that up is just really cool. I love that it scaffolds that.
>> Yeah.
>> Okay. So, I have my backend API and we'll come back to that. It's an express app. And I have my front-end React app and we'll come back to that one and that's pretty cool. But I want to poke at the um app host. The app host is right here. And I always like to name my front end app and instead of front end and so that's easy enough but my first bit of feedback is um you named the backend also app. So now I have to rename this to API and um so I don't know it feels like uh because it's in the API folder it's a natural map to call it API >> and so all else being equal I would prefer that.
>> Should we put it in app folder?
>> Yeah.
>> Should it be in the app folder?
>> I mean if you play games I can play.
>> Yeah. Yeah. Let's rename this folder to app >> and then the app app.
>> Oh my god.
>> The app app. I like it.
>> I do think if we're going to call if we're going to put it in the API folder, we should call it API. That is a that is a good piece of feedback.
>> It doesn't matter to me that you'd rather call your frontend app or your backend app. It does matter to me that the folder we put it in is the thing we call it. So it considering we do that for the front end. So >> right >> fun little bug not bug typo choice. I don't know that do you have feelings on that on why we did that?
>> On why we called it app?
>> No. Seb do you have feelings on why we had a app as the API?
>> Um no ID.
>> Okay.
>> Someone thing one day and I I I was not there.
And to me it doesn't matter but you know I'm deep inside the thing. So >> Oh my god. All right. That's that's >> I just want it to be consistent between these two.
>> Yeah. I need to what what I should be doing is taking filing bugs as we do this. So >> Oh, >> let me >> I was looking for this template to go try and do a pull request for it. And so I found in the Aspire repo on GitHub.
>> Yeah. Inside there, there's Aspire project templates.
>> Yep.
>> And I didn't see the TypeScript one.
Here's the TypeScript front end and C backend. Where's the TypeScript appost one? Is it in here or is that the one that's in the API folder? Nope, that's not it.
>> What's your question? Which which one?
Where's the template? Where is the template?
>> A template? This one?
>> Yeah.
>> Yeah. The TypeScript app host one.
>> The TypeScript app host. You mean the empty app host?
>> No, the one that he just created that was >> Yeah, the one that I just used right here.
>> Where's the source for it?
in the is it in >> I don't know.
>> Let's find out.
>> I don't touch. Did I touch it?
>> Okay, let's come back to that. Not a big deal.
>> Damian will know once he wakes up.
>> He knows.
>> Yeah.
>> Yeah.
>> Oh, this is mad because I didn't npm install yet. So, um, type slreact will get it to be a little bit gentler and then I don't have to npm install everything.
>> Yeah, that's that's fair.
>> Okay. So, um I don't know what changes were in it, but Oh, it called it app.
So, let me create a new API. And so I'll say new folder other API.
And in other API I will create a new file. I don't know index.js.
And I'll say import um I don't know. Let's come back into this API and import express from express. That works.
Hello from the other API. And so now I have my index.js. Now what I forgot to do was create a package JSON in this folder.
So >> Oh, I'm going to say npm install express.
and it's going to go, "Sure, I can do that."
And it did. But I still don't have a package json in this folder. Where did it install it? It installed it in the app hosts package JSON because the app host is here in the root folder instead of in a separate folder. And so I would argue that is not a good idea. I'm going to do something different. I'm going to say let's go into this project and I'm going to say new folder app host and I'm going to go grab all of the files associated with that app host and move them into that app host folder.
And so I would argue that's probably what we need to do with this template is create an app host folder so that we don't run into that problem. Now if I come in here and I did delete the um reference in this package JSON, it no longer says um it depends on express.
So now I'm going to come in here and I'm going to say npm install express. and it's going to go hey you don't have a project here and um create me the package JSON.
So that's my first fe piece of feedback is well I guess my second with the name put the app host in a folder so that we don't injure ourselves.
So this is a this is a whole thing because where do I even start with this? So yes, I we have gone back and forth on this.
Um I I mostly agree where we got tripped up originally is if there is if you are a top level package JSON person like and you're not doing the monor repo thing where each thing has its own package JSON, you just have one package JSON, then you trip over yourself. But a lot of people do the monor repo thing where they have three different package jsons in three different folders.
>> So it is like >> we're not quite sure what the right thing to do is. I I think >> a folder is probably the move for the template, right? Because the template we want you to not trip over yourself, >> right?
>> Damian just texted me. I'd be there sooner, but American kettles suck. So he's trying to make a copy right now. So um >> I would argue because there's a package JSON in the API folder and a package JSON in the app folder. We've already kind of grabbed the monor repo paradigm.
And so let's grab the package JSON inside an app host folder too.
>> Yep. Yep.
>> Oh, I also need to update my Aspire config to say um Nope. myaspire that Aspire config probably needs to go in the app host folder too.
>> Actually, Aspire config should stay at the root of wherever you want to be able to run Aspire from the CLI.
>> It will traverse up to look for Aspire config and then use Aspire config to look at where the the app host is.
>> So, >> oh, so I just need to say app host.ts right there.
>> Yes, exactly. So, >> cool.
>> Yeah. So that's how we make it so that you can run Aspire run from deep into your API source folder. Um >> it finds the config and then the config points to the app host file. So yeah, I think that is a reasonable thing request for the template that because there's package there's sub package JSONs the appost should act similarly.
>> Um >> yeah good good request. Hold on. So, what I have right now on my screen is I have a co-pilot session where I'm just going to type the things and then at the very end I'm gonna have a co-pilot go and see which ones are already filed, which ones aren't and file everything.
>> Um, I think the templates are in Oh, the echo back. It's my fault. I'm probably talking too loud. I think the templates are in the aspire.ci folder, by the way, if you want to go look there.
>> Inside the Aspire.ci folder.
>> Yeah, way up.
SPCL tempmplates >> templating >> templating >> yeah templates >> TypeScript starter template nice God this looks confusing yeah here's an app host.ts TS and where's the content from it?
>> Is it one folder deeper in the templates folder?
>> Templates. Ah yeah the templates are in the templates folder.
>> TS starter.
Yep. So I will pull request um app host. I will pull request this um name change in 8 seconds. Well, you know, after we're done. That is really cool. I am going to copy that link off and save it.
>> But I'm pretty sure someone will come and say, "No, front end is not the app. It's the front end. the actual app is >> at the very at the very least we should make it so that the folder where the code is matches the name of the resource. So it doesn't matter that it's API like I think API in front end and not using the word app at all is fine >> but >> I agree >> then the resource shouldn't be called app if it's in the API folder like we're totally splitting hairs but it is something that it's like yeah that's it's inconsistent. So, um, >> yeah.
>> Yeah, that's a >> Yeah, the fact that the app host did it one way. Um, let me actually flip to back to GitHub. Um, the fact that the app host said app here and API here, it's like if you're going to name it API, just name it API consistently.
>> Correct. I agree.
>> By means, whatever you do in your PR is not the way that they will want to do it.
>> No. No, no, no, no. Seb, no.
>> Did that mean that I need to move my modules folder into the outpost?
>> Oh, probably yeah.
>> Well, you can delete it. It will regenerate it. It's just generated code.
So, >> that's true.
>> That's where it should be.
>> So, I should add that to my get ignore.
>> Correct.
Nice.
>> Okay. Can I poke at something else?
>> Well, can I >> can I >> I will interject.
>> So, I like the idea of having app host in a custom folder to isolate everything, >> right?
>> Three stories here. there is these kind of templates that contain other apps and you want everything to be at the same level app host app API that's fine >> we have also the templates that start from scratch like Aspire new >> where there's nothing >> so when there is nothing would you suggest to also have a folder app host or app host TS at the root in this when you start >> I would always put it in a folder but that's because I like the monor repo approach with lots of package JSON and so I think if you're just going to create an empty thing you know um when it prompts in aspire new oh I've aspire new the first thing it does um in any of the templates it's going to get mad because well enter the project name and then it says where do you want to put it and so It's already putting it in a subfolder by default. I think that's not bad. You know, if we want to create another subfolder inside that, that could be okay.
So my question actually, I will rephrase. If you do Aspire new and you pick empty app host, the the last option, >> this one just creates app host, right?
>> Oh yeah. So in this case there is nothing to com to conflict with >> right >> which mean we could just have an app host and be done like why create a sub subfolder because maybe we just want to orchestrate docker containers or whatever that and there's nothing else.
So in this case today, >> yeah, >> that's a good idea to to only have app hosts >> because >> I would put it in a subfolder just because. But I I don't have strong feelings about that >> because if if you go and if you try to select the TypeScript for instance and if you can and see what's >> Well, I'm in a another folder. Let me get out of here.
Oh, okay. Um, empty app host TypeScript. Oh, is this one a um single file C# project?
>> Yes, same thing.
>> Or is there a way to pick between them?
You could try both just to see the to compare the the options and if we need to to everywhere.
This is cool.
Uh I really like the starter templates, the ones that aren't empty, because they kind of get me past the blank page really easily. Even if I have to go delete a bunch of stuff, I find value in that it having the content there. And so I would argue that um the empty app host is less valuable to me.
>> Well, so there's a third option also which is aspire and knit which is if you're going to aspireify an existing app an existing repo, right? So like >> right >> you have you have your app that already works today >> and aspire init does the same thing aspire new. Go away. Don't go away.
>> What?
>> Here. Don't converation like you are going to create another. No, this one.
So here you see there you you created a custom folder >> and empty TypeScript whatever.
>> Good morning Damian.
>> And you get the app post. Yes. And you say would you say let's create another subfolder or let's oh it's fine. It's like C single file app.
Sorry. Filebased app. Oh crap.
Um, and just have it there.
>> Yeah. Um, since the C# one puts it in the root folder, I say the TypeScript one putting into the root folder is fine.
>> I hope you didn't say because we want to put to create a folder for the TS1. Let's create a folder for the C# one.
Oh, >> like >> duality like I mean yes there you make things equal you can change one or the other which one is is better.
>> Yeah in the one that has the all of the other folders. That's the one that I'm super worried about. That one definitely needs to be in a an appost folder.
>> All right Damian, you ready for the recap?
>> Yeah.
one in the Aspire new appost Typescript appost express template we this I mean this is the edited one yeah go so we call the API folder resource app I don't know why we do this >> sorry wait what sorry there were lots of words I didn't follow we call the API folder resource app what >> yes so so we have a >> express template When we create the backend API and we say add nodeapp, it's in the API folder, but we call it app.
>> Yeah, I know why.
>> Let's be consistent. Let's call it API.
>> I know why.
>> And then >> I know why you're going to hate it. This is one of those things where it's complicated and no matter what you call it, it'll upset people. So, it's because when this is deployed, you get one thing deployed which has the front end and the back end in it. So if you called it API, you would have a thing deployed to Azure for example called API which has your front end in it. And so we were like that doesn't feel right. Like we're thinking about the end to end, right?
And so what they landed on when we were doing this was we'll just call the back end the app and that way that's what you land in. Now again, I'm not saying that's perfect at all. It's just if you name this for the runtime dev experience, you end up making a trade-off with what lands in the published experience. Does that make sense?
>> Yeah. And I'm going to come back to why I think this is a bad idea, too. But I agree.
>> Bad's a very strong word.
>> Deploy thing called my app makes sense.
>> If it all bundles into one thing, having the deployed thing called app makes sense. But what I typically do is I rename my front end to app >> and now I have two things called app.
>> And so then I have to come back and rename this as API and I'll deploy both of them as separate containers behind an ingress.
>> And so >> yeah, at that point I'm not bundling them into one thing, >> right? But I would argue at that point it's software. You can just change it, right? Like if you're making changes about how it's going to be deployed, you should be totally fine with changing what they're called as well. Like the reason these are variables and they're strings is so you can change them, right? Like we have to pick something as the starting point, but we shouldn't get too um >> yeah, >> you know, zealous about what they're called. Like it's just >> it didn't like the fact that it landed in API in the default publish mode.
>> So >> yeah, it just bugs me that they're different >> that they're different between this and C. So that's the other thing I kind of take contention with. Like that's totally fine to feel that we are not optimizing to make C# and TypeScript look the same. That is like actually the complete opposite of what we're trying to achieve.
>> Um we want to more lean towards >> let's meet >> Typescript folks and like idioms where they are and C where they are. Not try and introduce a new set of lowest common denominator idioms that show up so they look the same in both places.
>> I agree.
>> Yeah. But yeah, but also again like they're not the same between these two strings. Not that they're not the same between TypeScript and C#. They should not be the same between TypeScript and C#. I'll come back to that one, too.
>> Yeah.
>> Yep. That is a good point, Damian. I mean, I because I don't I look at this and I think of like the resources in the dashboard, not like what it's published as. So, um >> yeah, and templates are just another way of us to have opinions. And so in this case, our opinion is we think you should you should you could publish something this way. If you change it, yeah, you should change it appropriately.
>> Oh, trust me, someone who's worked on templates for 16 years, we will never get bored of arguing about templates. I love live for the day when >> aentic coding means we never have to write another template ever again.
The other thing was that in our starter template, we drop the TypeScript app host at the root, but we do have the mono repo setup where there's multiple package JSONs.
>> And we should probably be consistent and put the TypeScript and its package JSON in a subfolder as well.
>> Didn't we did we already came to that conclusion, didn't we, from the last one of the last streams, right?
>> I think we did, but we haven't actually done it yet. So >> Oh, yeah. Like that that caused us like three hours of heartache. Yeah, that was the rod disaster.
>> And yeah, unfortunately in a subfolder doesn't completely save you from that because you know settings get inherited and all that type of stuff and so yep, that was mostly with a nit versus new.
Um, but yeah.
>> Yeah.
>> Oh, that's a file.
>> Um, here's where this gets to be painful. I'm going to create a second API and I'm going to call this other API. And I'm going to create, you know, I could do all the TypeScripty goodness, but I'm not. I'm just going to say index.js.
And now let's come in here and do, I don't know, import express from express console.log.
Hello.
And so now I come into that um other API folder and I forgot to create a package JSON. Um, shame on me. But still npm install express.
And so when I npm install express here, I'm expecting that it's going to go create a package. JSON and do the right things. And it didn't. What it did was it put that in the app host package.
JSON.
Oops.
And so if we instead put the app host in its own folder, then when I go npm install that thing, it will correctly identify that I'm in a new API and it will create me that package JSON and put the express dependency in the right place. If appost is in the root, it's easier that's a foot gun and it's easier for me to do bad things.
>> Yep, I agree with that generally. I'm sure there's reasons to disagree with it, but I do think a folder kind of makes sense um for for that.
All right.
>> Okay. So, I put in another API. So, here's my >> other other API.
Thank you, GitHub Copilot.
Now I have two APIs and uh oh yeah reference that too. And so now where do I publish my static files? If I have multiple backend APIs, I probably want my front end to be a separate container as well. So I typically comment that out and say dot with external endpoints here.
No, with executable commands.
There we go.
No, there we go. And now I have three different containers. And then I'll put it behind Yarp or I'll put it behind Kubernetes ingress or something like that. And so this is great if there's only one microser. But if I add a second microser that gets fragile.
So I would argue that this was perfect for the single microser instance but it doesn't really set me up for success if I use multiple microservices.
>> I don't know how best to document that as a here's when you use this and not that. But I know that we put this in every template to say bake the front end as static files into the back end and that can be fragile.
>> Yeah.
>> Yeah. Again, there was a lot of deliberation about this and the ultimate I think the strongest feeling in the team was that having defaults in this template that resulted in more resources being deployed and thus more cost if someone was kicking the tires was seen as a bad thing. Um but again strong like good and bad are just too strong of words. These are all opinions. These are all trade-offs. And so we could >> choose like we talked about defaulting this experience to having a reverse proxy instead >> like y >> and that's complexity. Now if you walk up to a typescript person and they see this for the first time and they're like what's this y thing? I don't know what that is. Then we like well maybe we should default it to caddy then it's like well then you're going to get strong opinions from folks who don't use caddyy either. Like it's very difficult to pick winners in templates and so we often because of all >> yeah all those reasons and so we often do the suboptimal thing that in in the in the in the sense that it's suboptimal for anything quote unquote real. These are not enterprise ready production best practice templates. They're not intended to be that.
>> They're I've got five minutes. I want to try something and I want to like see it deployed. And that means the less moving parts, the more chances of success the person has of having getting to the end of that thing in five 10 minutes.
>> Create enterprise ready templates and regular template you know quick demo templates but now we have an explosion of templates.
>> Exactly.
>> So yeah, I can see that struggle >> and they and templates are actually really expensive to maintain.
>> Yep.
>> Because every template we have >> we have like two arms, right? Like we have templates and we have samples.
Templates are the ones that we give you in the box. So generally they they're like the simplest scenario. Samples are when you start to get a little bit more complicated and purpose-built for scenarios.
>> And my like one of my things a couple months ago was like >> I think we should get rid of Aspire new entirely because it is insane to me that you are going to start an app from the perspective of Aspire. You're going to start an app because you want a front end or a backend or whatever. you're going to start an app that has a website and then at some point you need an API and you add the API and that's when Aspire becomes useful. Like Aspire, and this is just like a a total soapbox I got on and I've never stepped off of, but like >> why would you start from the perspective of an Aspire app? Aspire is an orchestrator, not an app, right?
>> Yeah.
>> So my my whole thing was delete Aspire new. No more templates. We'll never argue about them again. Everyone has to use Aspire and Nit. But Evan, Evan, you just nailed it in the chat. The reason we kept it is because demos >> can easily >> makes demos amazing. And I love that where I can get on stage and I can say Aspire new and now I have an app that has a C# back end and a TypeScript front end, a React front end, and it's like >> that was just cake to build.
>> Yeah, exactly. So there's totally a purpose for it, but um I would say samples like we are overhauling our samples. We're in the middle of kind of like renov doing a little spring clean out of our sample situation. Um >> cool.
>> But samples do have a purpose. So enterprise deployment of multiple things with a proxy. So that's the kind of stuff I think that you're going to see them and have opinions about. And that kind of feedback is probably helpful there, too. Um, >> can I help you build a TypeScript and a C sample that includes multiple backends?
>> Yeah. I mean, I don't know where we're going to put them, but yeah, we really >> when we have samples like that, like make, you know, go and look at the samples that are in the repo. We just added a whole bunch more in the Aspire samples repo. Just a port of a bunch of stuff from some of Fowlers's um experiments.
>> We did. We we merged that.
>> It got merged. Yeah, pretty sure it got merged.
>> Let me look.
If it wasn't that, then it was the PRs on top of that that got merged. And then maybe I'm being a little uh eager, but I thought it got merged.
>> Yeah, the Microsoft Aspires samples repo.
>> Yeah, >> things yesterday merged a ton of bumps. Okay, cool.
>> Oh, a lot of dependabot merges yesterday. Yeah.
>> Yeah. Cool.
>> Yeah, that's one examples as well. Yeah, >> the template here is a single file template which looks a whole lot like a minimal API app.
>> It doesn't look like someone who would build an express app.
Um, if you do >> the express template, then you end up with a new folder here called routes.
And inside routes, I would end up with a file called, I don't know, weather forecast.ts.
ts and I would say import router from express router is router um and I would do my weather forecast route there. So let me go grab the rest of this method and put that here.
And we can argue about single quotes and double quotes and um >> yeah, >> everyone has opinions about those. Um I'll just leave whatever. Oh, it's inconsistent. Okay, let me make it consistent. Thank you, GitHub copilot.
So that's the router and that is actually at weather forecast, not API weather forecast. And then I would come in here and I would say import weather forecast router from routes weather forecast. And then I would say app use and hook API into the weather forecast router. And it might make sense for the health check. The health check is one of those that is kind of interesting because you know maybe I just maybe that's at the root. I would also probably have an error handler in here and things like that.
but this feels more Express like to me.
The other one felt more minimal API. And so that's where it's like as a as an Express developer approaching that template, it's like this doesn't feel like me.
So yeah, that's where I would say um create the weather forecast TypeScript file and then reference it from index.
>> Yeah.
>> Yeah. that that's basically the difference between what Express shows on their homepage and what Express generator emits. And so I think there's arguments again under all the same >> things that we said before for both sides of that. Like if you go to Express and look at getting started, look at the homepage. It's one file looks like minimal APIs. That's literally >> part of the reason minimal API looks the way it does is because that's what every other web stack does in their first five minutes >> is they show a single file and everything's there because it's all about simplicity. Then Express has an express generator >> and then the example they give in their docs when you're intro introduced to the express generator is let me scaffold out the skeleton of an app using express generator and then it like craps 25 files into your folder, right? And like we're not going to crap 25 files into your folder inspire new. It's just like a philosophical like we're just not going to do that. like we and so there's a there's an argument to be made here >> um based on your feedback that yeah but maybe we should have two files or three files for the express thing because that's closer >> but that's just the reason behind how >> express you know that's a pattern that they can replicate and expand on >> yeah that it is funny I'm looking at the express website I just posted it in the chat and and it says on the hello world example note embedded below is essentially the simplest express app you can create it's a single file app, not what you'd get if you use express generator, which creates a scaffolding, etc., etc. >> So, yeah, I think my personal opinion with templates is like I want to drop as little files as possible to make sure that the job still gets done. So, I lean towards the like really minimalist examples.
But this also goes back to my soap box of why are you creating your app from Aspire for anything besides a demo? So, >> yeah, >> I mean, that's the other part. argument for the React tab.
>> Okay, >> every web stack does this. Like Vit has a Vcreate and you could argue why on earth are you starting from the V create? Like V's just the tool that you use to like build and like but they have it on their homepage.
>> The Vcreate creates these wonderful things and I don't have to think about all those opinions.
>> So does Aspire.
>> Well, we're not giving you the opinions for JavaScript. we say those are not our opinions anymore. So >> I think I think the the the argument is like where should our opinions end?
>> Yeah.
>> And it is a good question but we have a lot of >> I open this React app and I kind of have a similar thing of where you know there aren't any components in here >> and okay you know there's a lot of stuff going on. This file isn't humongous but it's big enough. I would rather have this reference two or three or four components here in the components folder.
>> Yeah, >> that would make me feel more at home in this React sample.
>> H. So, it's funny again like this just gives me flashbacks to all of the feedback and arguments we've had over the years for the ASPET templates. And we had a very strong we used to have lots of files in a lot of the templates.
>> And then we had very strong push back >> at one point where people were just like stop making me delete all these files.
>> And like literally like we had so and so that the argument very sort of coalesed towards use as little as possible because people are just going to delete the stuff anyway. And so there's so I think there's a difference between what what you're saying what I'm getting from your feedback is there is a logical difference between a template designed to build a skeleton that you can then build on top of but is kind of if you run it doesn't really demonstrate anything like there's nothing in it like it's just skeleton files and stuff.
boiler plate, right? Versus >> an a sample app like Maddie said or a thing you can create quickly and run and use to spelunk and explore and like figure out and tweak to kind of as part of a learning exercise versus an actual starting point. And this is something we've struggled with for decades. Like literally in and and this is you know if you've been in our ecosystem for for a long time you've probably remember many many different efforts around trying to create that that split sort of decision tree and there's been different products targeted at those specific different things and but again often that results in more complexity and then we end up going through these cycles of bringing them together and splitting them apart.
Again >> I'm putting up a Twitter poll. I know that's not really scientific, but for fun.
>> Yeah, but if it's a Twitter poll, all you'll get is um uh I'm not going to go there. Twitter is not a safe place anymore.
>> No, it's not. But I'll I'll I'll post the same poll on Blue Sky. I use Twitter as the colonial uh place where you post from an account.
>> So, >> yeah.
>> Yeah. So, Oh, interesting. a template that tells you which files are actually needed.
Yeah, this is like the age-old debate, right? Like should templates be something you grow out of or something that are there for you to use and reference? Like I don't know. I um we did this with the Maui team too when we built all the Maui templates because there's with mobile it's like web times a hundred and like opinions times a thousand because not only do you have the opinions of the mobile stack but also of each operating system. So yeah you know and then the languages underlying the operating system. So you have to deal with the Swift and the Java and the Cotlin and the everything. Um, but yeah, I mean what Damian said when he joined is kind of the the hopeful silver bullet one day is that AI will figure it out for me if I need to scaffold out a a growable project, right? Like take this template and turn it into something that's actually architected correctly. Or in the Aspire case, my suggestion is scaffold out using express generator and npm vre create or whatever npx v create vit at latest, whatever the hell it is and then add fire after like that's kind of where I go in my brain. But I'm going to put up I'm I am definitely putting up >> my problem now.
>> Oh, hold on.
>> We're gonna get tilted.
>> Oh, what'd you find?
>> You want to get tilted, bro?
>> So, let's get to that. But I first want to react to something you said just to show where I am at in my software development career arc is I bristle when you say things like architecture correctly. I'm just like I like I went through that hump >> and was that zealot in the 2000s and I'm very much anti that whole thing now. And so like I get very especially as a product like as a platform owner and as a product designer like >> like as a dev in a team that's fine like you make a decision for your team about what the the right thing is.
>> But yeah I and I know you didn't mean it that way. It's just like I bristle when I hear those those words now. It's just like ah it's what's right for one thing is not right for other stuff. There's no correct thing.
>> Yeah. Maybe it's ar architected >> in in a way that our opinion is we're setting you up for success. Like more a more strongly opinionated architecture in the template.
>> Yeah, I get that. And but I I totally hear that. The challenge with that for me is it goes directly against what you wanted before, which is less content because to create more structure, you need more content >> and now that's more opinions and it's more things that could be wrong for the place that you landed it in. Right.
Yeah, the simplest possible thing to do is to have as little content as possible and then people can just delete it and do whatever the hell they want.
>> Yeah, that's that to be to be explicit that is the clear the TM I'm on is I don't want to give you anything in the template. I want you to use my freaking template not talking about them. But it is a super interesting just like >> because because when I come to learn something I I want to feel like I'm set up for success but once I know how it works I don't want any of that crap anymore because I know how it works right >> so yeah >> templates okay >> I know >> I mean and again like when we designed net new like what 12 years ago whatever it was now that was part of the original intent hint was that a template was literally just an app and you ran a command and you ended up with a a reusable thing. Um, and of course over time as you build out product and features and stuff it turns it's V is so far from that that it's basically unusable as that anymore. Um, because you know I think in the ideal world you would imagine and invent a thing where as you said it's very personal. you create what the thing is you want to create every time and it's extremely easy to tweak it so you get the benefit of it next time or to retroactively apply it to stuff and I think coding agents are the first time that that actually looks like that's feasible now like in the past we put so like literally millions and millions and millions of dollars of developer hours into trying to build deterministic systems that would look at a codebase and adjust it to whatever your thing was like think of editor config and analyzers and scaffolding and all those type of things and they all hit walls like pretty quickly. Um and so whereas now you know this year particularly with the coding agents we we now live in a world where you can walk up to most code bases and ask it to make crosscutting architectural slash opinion level changes and it typically does a really good job especially if you've already got good um sort of white box testing or blackbox testing in place. Um >> so we can just observe the outcome.
>> Yeah.
Here's next. Um, >> I love it >> because I want to deploy my app differently. Maybe I'm starting it from a different place. Maybe a completely different team is deploying it. Then I don't want to deploy my front end together with my backend. I just want to deploy my back end.
>> So I'll say if builder environment is development and then do all this stuff.
And in Typescript I end up with two awaits.
Copilot u stumbled over this too. it didn't want the 208s and it took me a while to find it. It's like why is environment async?
Why is is development async and C those are synchronous properties. Um I'm guessing it has something to do with the thing that shims back and forth between TypeScript and C that like every C call has to be async but it it this just that felt lumpy is >> why do I need to wait twice for >> this got improved right? So like you can see line six to nine >> that's all a single awake call now and like in the >> huh >> remove the >> yeah I think you can I think you can actually >> try it >> which one Seb >> I mean the 17 line 17 >> yeah line 17 I don't think you have to do that anymore I think Fowler fix this >> it like two month even 13 and as >> so on line 17 I don't think you only have to await the outermost expression Unless something complains but some nothing >> if not then we should fix that.
>> Why is it complaining?
>> Yeah, it's probably because it's not part of the builder, right? It only works with the builder, right? This is this is just property access across the RPC bridge.
>> So, I don't think that stuff's like this.
>> Some things don't implement that. Okay.
>> Yeah.
>> So sad.
>> Yeah. Maybe I mean let's we can see if we can't go and magically fix that one as well. But you're right, Rob. The reason that is is because >> you're not writing against a static model here like you have to like architecturally it's quite a well it's basically completely different to how it works in the C# stuff today.
>> I will disagree with what Rob said. I I understand why you say yes you're right Damian but no you're wrong. What you said is that it's because C# is async.
Nope that's not the issue. We have to await everything because Typescript forces us to send HTTP request in async.
That's it. It's not because C# is async.
It's because Typescript well NodeJS forces us to use >> No, that's right. That's I think I think we're all saying the same thing. The reason that we await here is because this operation is intrinsically async in Typescript. It is not in C because when you say builder environment, you just it's a property getter. it's an object model and you're just returning state.
It's not the case here because the architecture of an app host for C# is different to the architecture of an app host >> for TypeScript. We're talking about changing that in the future. There's a thing we call appost v2 where in the future it may be that all languages work the same way and it doesn't mean Rob necessarily that C will look like this.
be you know we we will continue to refine the experience to make it as um as good as we can but there are advantages in doing it this way.
>> I think actually maybe I misunderstood your comment but because I know how it works internally and maybe you don't know how it works internally. Do you realize that when you call add vit app it's actually invoking a car server when you import it in NodeJS the same way when you do wait for whatever it's not running in node it's running in in a net server actually so so we are the advid app here if you were to look into the source code of this thing you will see it's actually sending a an HTTP request to a service is it there is no logic in the in the TS or JavaScript.
>> It's just invoking >> the C advid app.
>> That's why we >> that is cool. I presume that it was running C in process in the TypeScript app or transpiling it to C.
>> That's brilliant that it's making a web request. That makes it a whole lot simpler.
>> But that means that anything it does is async.
>> It does. But it also means bringing other languages is practically free one like like architecturally the exact same model for every language. Um which is why this was the model like we prototyped like four different approaches three different approaches to this over the last 18 months. I say we FA did and Seb.
>> Yeah.
>> Um so this is the one we landed on >> because of that reason. Now the server Seb said server a couple of times in this model that's written in C#. So the server, but it it kind of it's it's hard to it can be yeah it's basically think of it like any client server scenario.
Um and think of these as like swagger generated clients. So like we have a an a server that is arrest restful basically and then we generate clients for it on the fly um for your guest language or your client language and then you're calling these methods are literally like client RPC calls.
>> Yeah, that's cool.
So here's next um with VDAP but also with node app um node developers JavaScript developers know their command line really well and so npm install is just muscle memory and so with build script they're going to say npm run build with runcript npm rundev and I realize that baked into the platform is the npm run prefix but I know that really Well, and so I want to be able to type the full command here. The added benefit is if I'm using bun or pnpm or something else, then I just say pnpm here and now we support other installers too. And I totally get that in C the um process run thing takes this as a different argument, but I would rather just be able to specify my full command here instead of having to figure out, oh wait, you meant the thing after npm run. And so now it's just dev. It's like that doesn't feel as natural to me.
I know we had this discussion previously and I lost before, so I'm pretty sure I'm going to lose again, but I really like having the full command here. Or maybe if I want to get really explicit on arguments that I can specify um each of the arguments in the command and now the um the way parameters work isn't delimited by spaces. If I happen to build commands raw, >> I mean, we could make this work. It would get pretty damn magical, though.
Like, I think >> we would have to pause what you're doing. Like, it there's more than just we run command here. We semantically understand. we semantically understand if you're running mpm or pmppm or and the reason we have that data is because it allows us to do other things like know that you need to have that a specific command available on the path and then check if it's there and then give you a good failure experience if you're not and we have plans eventually to enable acquisition and those type of things. If we just let you type any random shell command in there, now we have to pause that thing and then we have to extract that back into that metadata and then give a good failure experience if it doesn't map to something we can do. That is all doable like to an extent, right?
>> Yeah.
>> Um and there'd be nothing stopping you, right? There'd be nothing stopping you >> building your own overload of with build script that has that behavior. Like that would be really interesting exercise for you to do as an external. Could you build that experience and have it map well to our internal structures? Um, but that's interesting.
>> Yeah, that would be fun.
>> I think I couldn't call it with build script though because then we would have two overloads and we would have conflicting using.
>> Well, >> what do you mean by conflicting using?
>> Well, my extension method and your extension method would be the same name.
And so it's like well which one would I need to use? And so some using at the top that would tell me that my with build script is the one I'm about to run after we support like in obviously in C that just works because of method overloading right and you put them in the same in Typescript it gets a little more difficult because the there's logical overloading but there's not actually language overloading and so there are patterns you can employ and we try to employ them in certain places. So you can do what looks like overloading that gets projected as overloading into the dev experience. Um and so the good point I don't know if in the TypeScript you could build I think what we landed on if I recall Seb is that you can't really build extension methods in Typescript the same way we can in C for these. What you'd have is a static helper method and you call that instead.
Um which doesn't work for this really at all. So I don't think you could really do this in Typescript. Yeah, I did this se in one of my posts. TypeScript.post is like what >> if I did this npm rundev then you know um just as one string I have the same parameters as you you only have one string too.
>> Yeah. No, that's right. If it's one string I was thinking more of the the um array based.
>> The array of parameters is interesting.
And so I think that's kind of a cool overload for each of these is that you know one is one string and one is an array of parameters. And that can be kind of cool. Marshall has a good point though that like there is a difference between >> run script and run command >> and what and then like this is more like a with building. Yeah. I think the way that we that that that I think about it and this might be wrong again because we're just like we're in the weeds man.
We're we're reacting.
>> Oh yeah.
>> You know >> we're in the weeds. Um what I understand is that script is the name of the entry of the thing in package JSON.
>> Command is the fully qualified thing I would type.
>> So >> I like that distinction.
>> Yeah, that that's how I that's how my mental model is. So when I say with run script, I'm looking for the the word the key in the JSON. So build whatever.
>> Yeah, >> command is the fully qualified one. So >> that's right.
>> That that is the very Okay, Damian says that's right, which means I'm brilliant and I'm never gonna get anything wrong again. So, thank you. Now I have one.
>> Um, but just for those of you watching at home and like I don't know, Rob, if that makes sense to you, like that.
That's how I justify the syntax in my head.
>> Yeah, that's right. It's it's npm scripts, right? Is the is the foundational feature this is all built on. They were the one who started this.
And as you said, there's a node in your packages.json that lets you define a script with any name and then you can run npm like run that thing, right? Um, and then whatever you put in there will be will be executed. So I could totally you could we could follow that distinction.
It gets >> is that obvious? I don't know. Like do people hover over the methods to see the statement help to tell the signature help? Some people do, some people don't.
Some people like Maddie never read the docs. Like when we started these streams, Maddie was notorious for just like the method name is this, my mental model means it's that. It's like did you hover over it and look at what the arguments mean? No. Why would >> past tense as if I >> because Yeah. And and that's really difficult as a platform designer.
There's only limited words we can use, right? And a lot of them most of them are already overloaded and a lot of them have subtle meaning differences depending on what context you invoke that term. And so in this case, if we were to standardize on script versus command and add like a with build command, which means we're not going to run it through your package manager.
We're just going to run it like directly in the shell. Um, I could see that working. Um, I don't know if everyone would get that immediately by default, but maybe it it'd be okay for them to learn that distinction.
>> Yeah, >> I think that could be cool. Here's another um sharp edge.
>> Version 0.0.0.
>> Um that's not a thing. Um I like 0.0.1.
NPM in it makes it 1.0.0.
Um I don't care which one it is, but 0.0.0 is wrong.
>> Yeah, let's fix that. It's going now.
>> Yep. It's going in my list.
>> Yeah. Sweet.
Okay, >> that's all my TypeScripty things. Oh, actually, no. I've got one more TypeScripty thing. Let me flip over to this sample to talk through it, though, because it's really cool. Um, and a lot of the fun that we did today was I just live coded the everything.
and I'm going to get into um one that isn't that way.
One of the things that I think is phenomenally cool is that now Aspire's dashboard supports HTTP logging in the same way that it supports um gRPC logging for open telemetry.
Yep.
>> But there's a sharp edge.
Um, here in my frontend app, uh, I have the apps and it has the same import. Um, oh, so it pulls in open a We're losing.
>> We're losing you, man.
>> And >> so I took this, >> that's on the binger board.
>> Same tracing setup that you had before.
And and the login config just says I remember where I put it, but um here in app logging config and pass in those details. And I love that. But there's some sharp edges here. I love that it grabs traces and logs.
>> Oh jeez.
>> Variables because they have to have part of what V does is say I'm not going to expose any environ.
>> Oh, >> he didn't. He will come back. He will come back.
>> If only we'd had a warning that was going to happen.
I just was waiting for it to fix itself so I could interrupt him and be like, "All right, great. Start over."
>> Oh god.
>> This is when the session starts to be interesting.
>> Yeah. Oh, hold on.
>> He's back.
>> I have questions. I have questions for Rob also. I'm like, I'm waiting.
>> Yeah, >> Rob, your internet just really We We were just watching you and we had no idea what you were saying. So, like >> Damian was trash.
>> My internet was just like my audio was trash.
>> All of it.
>> It was you and Mr. Voice.
>> Yeah.
>> You're So, you're Today's the day where my internet is is garbage and it's been fine forever. Sorry.
>> No, that that is fine. I mean, Hanselman literally lost power on one of these, so like as long as you don't do that, you're still better. Um >> Oh, yeah. Stephen says, >> "Let me see if I can unplug my laptop."
No, I'm just kidding.
>> Yeah. Yeah. So, okay. So, we need you to go back and repeat that whole spiel though.
>> Yeah.
>> Oh, yeah. I'll repeat the whole spiel.
Um, logging in, um, open telemetry now supports HTTP in the Aspire dashboard, and I love that. That is amazing. It used to only support tracing and now that it supports logging as well. Then I've now built this sample app that allows me to do that logging and tracing. And so um here's the tracing thing that you know we've seen a hundred times where it just rigs up the tracing.
And I've done a similar thing for logging. Here's the logging one where it rigs up the logging in the same way. And then I have a log.ts ts that just shims into um window.on error so and also console logs console all the things so that all of those end up in Aspire as well which is phenomenally cool um oh and there's my log config the all the parameters that I pass in so here in app.txts txt ts I have to go harvest all of my environment variables and pass them in to the that initialize setup and I have to do that because environment variables in vit have to start with vit underscore um vit does this specifically so that you can't leak environment variables into your build unexpectedly and so I love that that's the case that they must prefix with ve but that means means that here in V config I have to go find all of the hotel environment variables and prefix them with V to get it to take effect and then here in app.tx I have to un v prefix them to get them into place and so that dance is a little awkward. I wish that um as part of the uh this is a C# app host. As part of the C app as part of the app host when I say add add frontend app I would hope that it would do that for me that it would v prefix open telemetry variables maybe v pre prefix every variable.
So, there's one sharp edge. Um, here's another sharp edge. To get the HTTP endpoint, I have to go get the Aspire dashboard LTP HTTP endpoint URL. Like all the rest of the hotel variables flow nicely. This one doesn't.
Oops. The process of turning on the um HTTP endpoint is not hard, but we don't document it super well. And so I added that. And then here in the app host, then I shim that environment variable.
And then here in um vit then I shim those to vit prefix. And then here in the app, I I go grab those V prefixed variables and shim them into place. And it's like there's kind of a lot of work to do there. And I wonder how we might make that simpler. You know, if we said here in the app host, I'm building a JavaScript a front-end app.
I wonder if we could v prefix all of them automatically.
So, this is one of the things we talked about when we locked you in a room a few years ago. Um, yeah, we've talked about this on and off a lot. The most most most the the most prevalent example of this is Vit, but there are a couple other things that do it too. Like I think Nex.js does it where there's like next underscore.
We have talked about >> Yeah, Webpack does.
>> Should there be a standard overload or something or like with prefix or something? We have not come to a conclusion. Um, and there's there's like there there's arguments both ways. Like one I mean I put in the chat like yeah it's a it's kind of a sharp edge. Like there could be a prefix field that's nullable obviously or optional but like you could really >> um I do experience this a lot with my samples because I almost always have to do like with environment v underscore whatever instead of with reference. Um but it is yeah it is it is an API design question for sure.
Um I don't know >> it's more than that in this specific scenario the end to end of hotel over HTTP isn't great. So like we kind of stopped we what happened was James added support to the dashboard for HTTP ingress of OTL um and you manually have to configure it as you're showing here. It's not done by default. And then we didn't even publish a sample that uses it because um Oh, hey Adam. We didn't even publish a sample because there is no really good end to end with regards to then when you deploy it, it works. Um >> right, >> by switching from the dashboard during dev to whatever APM you're using in production. Um, >> and the reason for that is environment variables get baked into the React at build time. You can't run.
>> I'm not even speaking about the VIT thing. Like even if you just ignore the whole Vit has this concept of there are environment variables that you can reference during build versus what's available to the app at runtime because typically the app is just a static app as after it's been output, >> right?
>> Just the general end to end of using OTEL from a browser over HTTP.
We haven't we kind of ejected from trying at the time it was a while ago trying to to push on it more. We made the dashboard support it and said okay we will unblock people who want to send browser telemetry effectively to the dashboard uh hotel over HTTP but getting a nice end to end that works with vit with any other build um and then after you deploy having it all kind of switch from using the dashboard to whatever APM you're using we we basically ejected we said yeah well then it's up to it's up to the user. It's an exercise for the user to do this manually and wire it all up because we didn't land on a single good experience um there. So others are saying like yeah you can deploy an hotel collector um like manually if you put an hotel collector in your app host which there's an integration for um and say hey yeah configure that to use HTTP probably HTTPS in production um and then change the config so that the that URL flows through the V build and then into the static app or you invent a runtime configuration retrieval which again like we have no primitive or turnkey solution for an Aspire for runtime config where when the app runs in the browser after you've deployed it, it hits some endpoint and says tell me what URL to send my um to my telemetry to for example. That's just not a thing. We don't have anything built in for that.
So there's a lot of moving parts here to land on as as nice a solution as I have a server app that speaks OTLP to some hotel endpoint and I can just easily switch from the dashboard to something else. we just haven't come up with it yet. So that's more like about the full end to end with regards to the actual V environment thing. Yeah, as Maddie said, this has come up numerous times. Fowler went down a big rabbit hole on this recently when he did all the deployment docs for JavaScript frontends. Yeah.
>> And >> even with that, he didn't land on, oh, there should be some boiler plate here that we hoist. So I'd be interested in hearing his opinion on this because he's the one with the who's looked at this the most recently in any kind of depth.
But yeah, this is acknowledged.
>> Yeah.
>> Yeah. And I grant it's hard especially from that end to end, you know, for development this with end prefix type of thing could be really cool.
>> Yeah.
>> But this that the fact that we don't pass the hotel HTTP endpoint URL >> Yeah.
>> to um to browsers that feels like a bug.
That feels like a really easy one. Just like go grab all of the hotel things and shim them off to everybody.
>> So if you call with OTL like we have a method, right, that is that you can put on any resource that supports environment and it will inject the stuff in. The problem is it doesn't prefix it like you're saying. So like we we could inject in all the standard hotel stuff to your V thing >> but >> and we inject all of them except for >> I see >> this one isn't injected.
>> Well, that one's not intended for you.
That one is intended only for the dashboard. This was pointed out in the chat. This one is not an OTEL standard environment variable. This is one that we use to tell our dashboard what the endpoint configuration is that it should start listening on. Whereas what you want is what do I need to send it to?
That's that's that's subtly different, right?
>> Well, this is what the um environment variable is to send the gRPC ones.
>> Yeah.
>> And this is the one to send the HTTP ones, >> right? And so whatever we need to name it, you know, I don't know what we need to name it, but if it's a client side app, then we should send the HTTP one instead of the one >> together that says use HTTP not.
>> What I'm curious about is if you call the method, we have a method that injects environment variables into resources.
>> Yeah.
>> What's that method? dot with open with hotel >> OTLT exporter.
>> Uh, no, that's not it. Is it? Is that what it is?
>> I thought that was it.
>> Okay. And then you do HTTP JSON.
>> Yeah, that might be it. That might be right. Yeah, inject the environment. So, if you hover over it, hover over the method. Hover over the method for me.
Hover over the method for me.
>> Line 14. Just hover over it with your >> in my notes, too.
hover over that method with >> yeah what does it say exorter >> what does it say >> I don't know Maddie wasn't reading it >> exactly so that injects the environment variables to allow the res so that's the method it's just that we don't call that by default on v apps and other javascripty browser apps we do call it for like lots of other resources um so it might be that the feedback here is that we should just call that by default >> with the appropriate protocol maybe only if we know you've configured the dashboard for HTTP because you know sending OTLP from the browser isn't going to work very well um gc so then that's why again it gets quite nuanced it's like would people know that like would they understand that the reason they're not having that injective is because they haven't manually configured the dashboard to listen on HTTP because we don't by default it it it gets a little but at least this method is here it's like the method is there you can call it it should do the right thing I'd be interested to know if you comment out your other methods there whether this if it still works.
>> And what's interesting is it only grabs the OTLP endpoint URL, not the OTLP HTTP endpoint URL. Does it grab the HTTP endpoint URL if I say HTTP JSON there?
>> That's what I'd love to the fact that you've configured the HTTP one in your launch settings is what I'm curious about.
Do we need to update this documentation to say that it pulls the other URL?
>> I don't know which it is. Like you'd have to try it and or we look at the code.
>> Okay. Yeah, I'll try it.
>> But that's definitely the intent of that. It's like, yeah, this is the thing you call to enable OTLP export configuration on the thing.
Yeah.
And then build me a in prefix doohickey because that would be really cool.
>> Yeah, we need to revisit that. Uh there was maybe we have some notes about all that somewhere because we like we went back and forth on that a lot.
>> Adam, did you join because you heard us talking about that and you had feelings or did you join because you saw the Streamyard link? Okay. Adam is Adam is our our resident Gen X. I mean Gen Z, not Gen X. Sorry.
and aged.
>> Adam is our resident Gen Z and also like our resident like cool JavaScript type script person and so >> cool Pine is like Pine is our millennial JavaScript TypeScriptor. Adam is our Gen Z JavaScript TypeScriptor, right? So >> yeah, you learn from different eras. So >> you mean Demian, right, Adam?
>> What?
>> No.
Anyways, Adam, we're talking about if we should build some kind of API or method or whatever that is specific for adding prefixes to environment variables for things like vit react or or um next I don't think I don't know if react does it might that might just be a pattern not a necessity though but like the prefix >> react doesn't do it but whatever host react does and so if you're using webpack then it must start with webpack underscore and if you're using vit it must start with v underscore If you're using next and next then it must start with those underscore. And so yeah my pitch is if the environment variable starts with oel underscore duplicate it into vit underscore. I had to do that manually right here in my vit not there in my vit config to say but I want all theel variables passed into my browser app.
>> Yeah, >> that does feel like something we should handle. Yeah, >> I'm just trying to figure out what layer it is. Like is it literally all the way down at the I resource with environment layer and there's a capability of just saying yeah I resource with environment you can set a prefix which means any environment variable added we will prefix like maybe it's is it's that low level and yeah >> we then we could choose to set that call that by default on advap right we would just set that by default and then everything would would flow through if it's add this environment variable so that's reasonable that's something that we should revisit I think >> cool >> I I think I'm putting those in my notes.
Add nix >> or something and we can >> one of the things that's really cool.
Um, Aspirenet.
Ah, did I spell it wrong? Oh, I'm already in Aspire.
>> Oh.
>> Um, sorry. Just one one more thought about that. There should be a filter or predicate though, right? Because you don't want your entire environment >> available.
>> Exactly.
>> And so that was my pitch was like here's my prefix and so any environment variable that matches that prefix also then additionally prefix it with this.
That seem that seems fair. I'm I'm just trying to think through the consequences of just providing a string versus an actual predicate.
>> Oh, I like that. If you passed me a lambda and I could just figure it out.
>> Yeah.
>> No, because then it doesn't work with all languages. I'm I'm >> it doesn't styize on the wire because >> C# centric thinking.
>> Oh, let's make a new language.
language.
>> No, >> one that you can express like expressions and query across HTTP.
Someone should have done that already.
>> Three times.
>> I did that like 20 times already.
>> Hear me out. Why don't we use like an extensible markdown language, so there's no types and everything's based on whites space.
>> Interesting.
>> Did you just invent YAML?
>> Did I just win bingo? Yeah, pretty much.
Yeah, Shane, that was for you. Don't you worry. My bingo. I haven't even been watching bingo. I've been watching I've been watching Damian space try not to just like flip the table over templates and now we're back. So, >> there you go.
>> Oh my god, >> I'm very >> I would love in the TypeScript project to have a similar thing like this to be able to create a test project.
>> And >> yeah, you know why we don't do that?
>> There's a very good reason we don't do that. We haven't figured out testing for for for for for anything other than C# yet. We have a lot of ideas and we haven't done it yet. So, if we did that, there would be no product truth. We'd be landing you in a place that does nothing because we haven't figured it out yet.
>> Okay. Can I can I build you one?
>> I mean, sure. Give us an example of what you'd like to see. That would be great.
>> Yeah.
Um, so I just created a C Blazer app.
Um, and in hindsight, I probably made it too complex.
>> Nah, >> I Oh, so for for those of you following along at home and also Rob, for you Fowler went down the rabbit hole over the weekend of performance of his fire.
project. I should have just clicked through it.
>> Oh, he's gone again. He's gone. Poor Rob. I've I've talked to him on the phone and he's like not had issues. But this happened last week, too, or two weeks ago. Whoever we had on had to restart Oh, Alex had to restart his router before he came on because it was like for some reason.
>> It's the Aspire Friday's curse. It's not you, Rob. Don't worry.
>> Oh, it's still pretty bad though.
Oh, Rob, I'm gonna suggest going to restart your router.
>> Look at how slow that blink was.
>> Eric told me he's bothered by um by Rob's domain. Robrich.org.
>> Oh, I wonder if I can fix that.
>> Probably can. Oh, >> of course. My internet is awful.
>> Rob, I think go restart your router.
Can you hear me?
>> The internet was a mistake.
>> It really was. We should never have done it.
If you want your router, go ahead. Now I'm trying to do this this the Streamyard chat.
We will kill sometime.
What kind of advice is it? Like restart your router.
>> Who does?
>> I don't do it anymore. I used to have to do it a lot.
>> I do it all. Yeah. I mean, I get to do it from an app.
>> Get a new router.
>> H >> I literally never have to do that.
>> Yeah.
>> What kind of router do you have to do that?
>> Yeah, I probably had to restart my router. Am I back now? Y >> you are. You are back. Go ahead and go ahead and restart it if you want and we'll kill some time. We have plenty to yap about.
So, >> or maybe there are clogged bites on the router and you need to flush them out.
That's why.
>> Oh my god. So, I need to get a new router, but I don't want >> Yeah, I have some extra, you know, >> don't ask Dian to make your network configuration. Okay.
>> I know.
>> Why? That's I want >> like with the people on the on the internal chat. I'm like, what are you talking about? And then Steve needs to reduce his network and it's it's like 10 grand of networking stuff.
>> Really was not. You are over over.
But just seeing >> Yeah. No, I need to become famous enough that like Ubiquiti will sponsor me to upgrade my rotor. Like that's what I >> The problem with that, Maddie, as I can speak from experience, is once they get you in, >> boom, >> then you pay for the rest of it. So they they they help they help you get the first piece if you if this happens to you and then you're like, "Oh, this is really good." And then it's just much easier to buy it after that. You just end up buying more and more and more.
>> That's fine.
>> We'll give you six months free and then take it away. Yeah, that's >> kind of Or you would just upgrade. Like they the thing now is they have a lot more like products levels now. So, like to Seb's point in the chat, when when I set up when I went to Ubiquity like five years ago, it was all about like getting in was a lot, right? But now you can buy one of their tiny little routers and an access point for a few hundred bucks and it's like no more than any other, you know, halfdecent consumer router, but you're on the you're on the plan then and then you can, you know, update and do stuff. So, >> yeah.
>> Yeah, >> they let me share my screen again. And um if I fall off again, I'll reboot. But >> you're already you're already crapping out again.
>> I am sharing my screen.
>> Yeah.
>> Is it on the stream yet?
>> I haven't put it up because uh you're already crapping out again.
>> Oh, boo.
>> Yeah.
>> Really?
>> Yeah. So, go restart. We'll kill some time cuz uh Yeah.
>> Okay.
I'll be back.
>> Yep. Take your time. Oh, good. Seb, are you gonna ask him about MTS when he's back?
>> Yeah, we can. We can talk about it because that's part of the conversation, right? He doesn't know. I'm sure he doesn't know, but it should be part of the conversation. Damian will Damian will manage the conversation with that.
He knows everything.
>> Yeah. Yeah. This is why we have Damian.
He's here to facilitate.
>> What are we talking about, >> dude?
>> The MTS.
>> Oh, you know what? And yes, I merged it 2.3 minutes ago.
>> Yeah, >> good.
>> Sometimes you just have to do things and then we'll see if it's better.
>> Yeah, the C didn't work for two days.
That's why.
>> Yeah, we've had a fun week. Um I was telling Rob before we started, if those of you who might have noticed, we um are on 13.3.5. I don't think we've ever gotten this high in servicing before. And all of these servicing releases has happened in like the last two weeks because we shipped like two weeks ago. We are shipping masters now.
We have whipped Jose over the head almost enough that there's almost one button we have to click to ship a servicing release. It breaks differently every time.
>> Every time.
>> But we're getting better.
>> Yes.
>> And so the new thing is everyone on the team has to ship. So I had to click the button Wednesday, Damen had to click the button Tuesday. like even if it's just a couple PRs until it is so foolproof that literally anyone on the team can ship a servicing release.
>> So if if you're getting frustrated with update notifications, you're welcome actually.
>> And of course, we're doing this at the same time that we're adding a whole bunch of other crap that we need to ship like new CLI installers in package managers and we're contemplating like so like it's not like it's a fixed target that we're trying to improve. like we're trying to improve it while adding a bunch of crap as we go like exactly the way you're not supposed to do it. So, >> and Adam is the only one I besides Jose who knows how to ship the VS Code extension. So, like that's the next thing.
>> Once Jose merges my PR, then it's also one click.
>> Obviously, >> and there's going to be a new there's a new workflow that will send a PR it will like generate a change log between the last release and this and then it will open a a PR to bump the version. Once that's merged, then you can then hit the the release button.
>> It is so incredibly satisfying.
>> Oh, go ahead.
>> I I was just going to say it's so incredibly satisfying working on this stuff these days like 15 like Gen X speaking like doing this back in the 2000s like in the beginning of extreme programming the very early and everyone was like CI is something you should have like dedicated a spare machine in your office and like have the monitor like go red when tests fail. like getting that working and then moving to an actual CI server and like using Team City or like what are the other other CI servers?
What did we used to run Seb? What was the one we had at?
>> I I was just about to say that Signalar was the first team I saw doing that like blaming people if they broke the build.
>> Yeah.
>> Was not working on Signal. I was seeing them in their office.
>> We had a build light. So we were like a team room. We had like we were I looked at buying a traffic light, but we had like a build light that would go that would go off when the build failed. But like building that out that was just doing like continuous building like getting to like full CD with release notes and like roll back and like the whole deal. And when you're not just shipping to one thing like a website, but you're shipping packages on three different package managers and all the rest of it, it's so satisfying getting that to work. But god, that used to be a lot of work. These days with coding agents, thankfully it is easier to slop out a whole bunch of stuff. It's still hard to do that full loop of knowing it's going to work, right? Especially when you get like self-updating like the exe can update itself after like, oh, getting all that stuff working with proper provenence and security and all that stuff is still >> a lot.
>> Yeah, that's pretty funny. Marshall says our CI is top tier, which is a great compliment because we constantly feel like our CI is like >> a hot mess, but >> yeah.
>> Um, oh my god, Stephen. Okay, sorry Rob before we go back. Stephen's platform team had to wrap Aspire CLI in Intune.
That is tough. So like there is a level of enterprise any tool. Um but the Intune team, fun fact, is in the same office I sit in in the Boston area. And so I've tried to get them to use Aspire for a few things before. Um they have yet to, but maybe maybe they will and then they'll just build up for us. I'm curious how what would have been easier like we don't have on window I'm assuming this is to install it on Windows having to wrap it in in tune. Um we have two installation mechanisms on Windows today. We have the.NET tool which is we're moving to to make it the same as the CLI. It's not quite the same today. And then we have the install script and then we're going to add wingget. So there'll be a third way but we don't have an installer. And frankly, we we're trying to avoid having an installer uh for Windows. So like, but it's interesting to know if if you need to do stuff like, you know, enterprise roll out through things like Intune, does that mean it's harder for you because we don't ship an MSI? Like I don't really know.
>> That is tough.
>> All right, Rob. We're also we're going back.
>> Is my connection better now?
>> Yeah.
>> Good. remains to be seen.
>> Yeah, you sound you sound great at the moment.
>> Oh, awesome. I also killed off a bunch of things on my machine and so hopefully my CPU isn't consuming the world.
>> Oh, okay. Sorry, Adam. I cut you off, too. What do you want to say? And then we'll >> I was just going to say we're also going through the process, the extremely long annoying process of getting permission to ship through npm the the Aspire CLI.
So, that will eventually be a crossplatform way. Uh, but that won't be for at least another week and a half.
>> I was gonna say at least another year.
>> Yeah, I know. I'd be amazed if we get it done in the in this next release. I think it's more of a release after that thing, but we'll see.
>> We'll see. All right. All right, Rob.
Where were we?
>> I just created a C project that uses Blazer.
>> Okay.
>> And this is really dumb, but this is one of my pet peeves. This looks like the minimal API template and that's brilliant with this one exception.
All the rest of the templates start with slappi slash which means that vit can proxy into all the things and this one does not. This one is just slashweather forecast. And I love being able to mix and match the templates because creating a TypeScript host app host with a React front end and an Express backend and then a C app host with a a Blazer front end and a C# backend and then like just adding the one to the other. And I always have to come in here and say API.
Can you make the template start with API and that way the mix and match just works because all the other templates do it that way.
>> Yeah, I remember why I did this.
Do you anyone want to guess?
>> Because the file new minimal API template does it that way >> partly like it doesn't have API in minimal because I created that template too. I can't remember. Um my thinking is that this is the starter template. This is the most complicated template we have. It's the starter app in C using the CS project host.
>> And yeah, you can see it's like five projects, right? Um I think it was done this way because they're separate they're separate hosts like the and so the assumption was putting API in front of a thing called API service was redundant whereas when it's part of an like a single template a single project that you are I don't know I can't remember that was the reasoning I think I had in my mind when I did this but if it's different to the other ones then we should just change it it's fine. Just send a >> make a React front end and a C back end.
It does say slash API.
>> Yeah, >> just send a pable magic. It's fine.
>> Yeah, that's a good one. That's a good one.
>> This web project is a Blazer um server project, a Blazer hybrid project.
And so yeah, I also need to put the API here.
>> Yep.
>> Yeah. But I see value in a Blazer Wom project in which case in C# 11 they're going to do um they're going to better rig out the dev server there so that we could configure it much like we do V and at that point then they would get deployed as static assets.
>> Yeah. into the WW root folder of the API in which case then yeah it would need to be API because it would proxy that way.
>> Yeah.
>> Yeah.
>> Yeah. So we could there's a few reasons we haven't done that to date. Um you touched on some of them which is the Blazer WASM with Aspire experience needs a bunch of improvements. Um and that that the Blazer team is working on that right now with the Aspire team. Um, the big like the reason Maddie was making the face she was making was because it's just complexity. Like the reality is Blazer is a huge complicated thing. It's actually very difficult to explain to someone when you when you when you build a Blazer app, how does that work? Like is it going to be server rendered statically? Is it server rendered dynamically? Is it a circuit? Is it a like and so we would have to introduce a choice.
>> The answer is it depends.
>> Yeah. It means you introduce a choice.
And so I understand like again the purpose of this template isn't to create a foundation for you to go and build real apps. It's give you something that works out of the box so you can explore and you could use it a foundation if you wanted to delete the stuff you don't want.
>> Yeah. But we are hesitant to introduce a whole bunch of configuration knobs in templates because now it's another question we have to ask you or it's another list item in the initial like list of like Aspire new and then we have to somehow come up with the words just in the title of the template that express this one is blazer that's server rendered or hybrid rendered and this one is blazer wom. Um it's just it's just and then and then running the the the challenge of then saying well now Aspire new looks really blazer heavy like why are there so many Blazer things in there like it's just we're trying to walk that line right >> yeah agreed >> like for the same reason people could argue why is there not an MVC template for the API or why is there not razor pages or why do we not offer >> why is there not a a view template why is not spelt template >> exactly it's about to go We played that game in the Gulp days and we played that game in the Webpack days before that and it's like >> Yeah. No, I I want to get out of the game of trying to keep up with JavaScript frameworks.
>> Well, and tell me and like Yes. Like doing it as a person who has to build them is one thing. Doing it as the people building the templates and shipping them is a whole other thing.
And we got burnt by Gulp like super bad.
Gulp and Bower.
>> Yeah.
>> Um I actually was Grunt first. So we did go we did Bower and Grunt in aspet core and ASPET and then like Bower died and then Gulp took over Grunt and we revved those things. So, and it was but then there were people using the other old ones like oh why don't take them away I use those like ah so we we got burned and we decided not to do that again >> and so I grant that React is the most popular front end and so leaning in there makes sense but I also wish there were others too but to that end what I do is I aspire new >> and then I ve in it and I ve it with all of the whatever I want in my frontend app and just swap out the front end folder for the one I just built.
>> Yeah. And so we we tried that at one point too. I don't know if you recall.
I'm sitting at aset core. We made the file new experience for the stuff with JavaScript front ends >> call the the like the the command that that created the front end rather than try to ship it statically.
>> And that created other problems like because then you've got version challenges and like >> Yeah.
>> Yeah. It was it was there's no simple like this is why you know to Mattiey's point just ship as little as possible and let the developers run the tools that they use trying to have opinions on this stuff is like super difficult.
>> Yeah.
>> Yeah.
>> And trying to then patch the V config to proxy to the correct URL on the back end and and um node wasn't able to get the ASP.NET dev server for a time and yeah it it's a thing. Yeah, fun fact for Blazer folks. Uh Javier on the Blazer team did recently merge the Aspire hosting Blazer integration, which the whole point of that is to model after what Maui did with Aspire Hosting Maui so that it controls its own destiny. Um and that will help alleviate a lot of the Blazer Wom junk.
>> Um >> cool.
>> Yeah. So that >> take that for the test, right?
>> Yeah. I I dropped the uh PR in the stream chat, but I'll send it to you too, Rob. So that's going to be fun. I think there's if if I recall correctly there is some stuff in net 11 that has to land for it to work fully >> but that might not be true but I know that's what we did with Maui is there was there was Aspire stuff we shipped that you had to be on the net 10 previews for it to work and then when net 10 shipped the Maui stuff worked >> um so like like out of the box but I I think that's the same with Blazer I'm not sure the other thing Rob is about 20 minutes ago Seb merged PR that we want to ask you about.
>> How familiar are you with CommonJS versus like modulebased TypeScript stuff?
>> Yes, that is quite the adventure.
>> Um, so in your in your infinite wisdom, you noticed that we dropped the app host at the root, which tramples on your package JSON. I don't know if you also noticed that when we dropped the app host in the root, we trampled on eslint configs and TypeScript configs as well. Have you noticed that?
>> Right.
>> Yes.
>> Part of the reason we did that is because we want you to be able to use top level awaits in >> Typescript so that you don't have to wrap everything in an await and then a main. Um, and and >> that is a thing, right? It feels like a feels like a script.
Um, but if you're using >> CJS, if your repo is CommonJS, it would get real mad at you. You can't just do that. Um, for reasons I don't fully understand, but that's just how it works. So there is a type of file called MJS or MTS which previously we just ignored and we kind of strongarmed your repo into figuring out a way to allow app host.ts.
Seb just merged support for Aspire run appost.mts.
Thoughts? Oo.
>> Um, the interesting thing about the CommonJS versus um, ES Next thing is that kind of CommonJS fell by the wayside and ES Next one.
>> And so it bothers me. I get it for backwards compatibility you need that type module to make it happen, but like everyone just does. So trying to support the non e es next paradigm to get back to the commonjs thing. It's like uh when I see documentation that is in commonjs that says to me that it's a legacy product that hasn't been updated in five years.
It's funny you say that is not our lived experience but >> like showing up to people's repos that is not what we see like and like and I mean maybe it's different in the world of people who are building apps that are internal and not open source >> but when we have like walked up to very very popular like JavaScript code bases or TypeScript code bases in the open ecosystem and even like looking at the examples of other extremely well-known tool tool chains, a lot of them default to CommonJS. Like it's a surprisingly like there's this maybe it's the whole thing of like anything with inertia, anything that has been around a while, >> things are hesitant to change in the same way that we walk up to aset core code bases and they're using the patterns from aspet core 3 >> despite us completely overhauling stuff in aspet core 6 and now we're on 10 building 11. people just don't change a lot of people unless they have a reason to. Um, and because we, you know, things are backwards compatible forever, a lot of so much stuff, people just don't have an incentive to change. So, >> yeah, it's hard.
>> And so, a lot of the popular libraries that have been popular for a while are still on. Yes. And publishing to npm in ES next is a little weird, but um yeah, building anything new in CommonJS is probably not a good idea. And now everyone's going to send me hate mail.
>> No, I don't think so. I mean, it's it is like >> it's a debate. It's a debate.
another argument for putting the app host in a folder so that you don't take over people's repo. You instead just >> mark that opinion in the specific app host project for a net. That's what we changed it to do. Um after living through all that pain live on stream walking into a repo and trying to drop in a TypeScript file that assumed it worked a certain way. I will say though, even when we put it in a subfolder, it didn't fix it. Like because of um monor repo, npm, typescript config, like we ended up, it was a whole rabbit hole of like trying to get that to just work.
Whereas MTS just works like it's just built into the extension. Like it doesn't matter what your config is, it just works. So >> yeah, I'm not bothered by that.
>> Okay, >> sweet. All right, Seb, do you have follow-ups on that? This is I know this is your latest.
>> Um yeah, I just want to be sure that nobody would be bothered by seeing a MTS file when they do Aspire new Aspire in it that it makes sense.
>> Well, it's not always >> if I have TypeScripty stuff already or if I'm doing a net new with TypeScript having MTS feels a little weird. But Aspire in it going into a legacy product. I see value in doing the MTS.
>> Yeah. Sev MTS isn't every time, right?
It's only if >> it's every time >> for a knit, right?
>> No. And we talked about >> for doing it makes sense. For new, it doesn't.
>> I thought we landed on new. We didn't.
We decided not to do it. Okay.
>> No. No. And it's funny because it was two days ago.
David, you and me were like very close and we talked about it and we said, David said, "Yes, okay, let's do that."
>> Yeah, fair enough.
>> And we talked about maybe we could do on new on new and MTS on init, but we said no, let's do MTS. And >> that's right. And we spoke to like the TypeScript people at Microsoft and they were like MTS.
>> Yeah. Like >> Yeah. They told us that people are less disgusted by MTS than they were in the past, but that doesn't mean we should always use it.
>> It's easy to change.
>> So yes, we could just generate thets file first. We support both. You can still write and your old appost.ts or the new appost. It's fine. Aspire will see them both. That's fine. Right.
>> It's just that when we do Aspire new the MTI post then we now today use a MTS file instead of oft sorry.
>> Um yeah I lost my train of thoughts. Um the other the other thing is that we use top level await because our app host as we discussed earlier is all async. Like you have all the method calls have to be awaited.
>> And no one wants to do that with callbacks. Like oh my gosh, can you imagine what that file would look like if it was callback based instead of await based. But to do top level awaits you have to use ESM is my understanding.
And so >> wait, yeah. Yes, you have.
>> And you have to be on a a version of Node that is modernish, you know, like 20 or better. And we're on >> You mean a supported version of Node.
>> I'm pretty sure the only ones that don't support it are all unsupported.
>> But the other way that you do it is you go like this. Um, >> function.
>> Yeah, that's how we go. That's how we get around it right now.
>> Yeah. So, not top level. Exactly.
>> Yeah. Now it's not top level.
>> Yep.
>> That's what I >> If that's a problem, that's how you solve for it. But now that top level await is a thing in all supported versions of Node, >> right?
>> Um just don't >> assuming you're using modules. If you're using CommonJS, then it's different. So >> new should really be appost.ts.
It just means the problem, Maddie, is that if you don't run a knit, if you go into existing repo and go and run a spire new and do that, you're in for a bad day.
>> Yeah, run a nit.
>> Yeah, but what if you don't What if you don't want to init? You just want to like new it up in your samples folder.
>> Well, I will say I will say that the first thing Copilot has tried every time I've tried it to aspire and knit something is to change file type to MTS.
So supporting MTS from the CLI might be enough >> maybe >> without making that our default.
>> You know what I mean? Like >> I don't think there's a clear answer here. I think >> I I think the thing that will always work is MTS. But why it feels weird is because we know we're going to land in repos that aren't using it. And that's why it feels like a schism. But the problem is that if you don't use it, you open up the whole Pandora's box of this isn't going to work for other reasons because the repo is common.js or whatever it might be. And I understand like yeah, a nit versus new. So we can make a nit always work, but then you still leave the case of like, well, if we don't do it in new and you happen to use new in the context of something that already has config, then you're going to have all those problems again. Whereas if we just use MTS, it'll always work.
>> So I don't know.
>> Someone just put in the chat, too. Can we just ask?
>> Well, that's the other thing. Then you then you or you introduce complexity by forcing >> like we could do detection first >> MTS. If so, let's just use it.
Otherwise, let's ask the user what they want.
>> But then there's an opportunity for them to get it wrong and then you can say, well, it was your fault. You got it wrong.
>> Yeah. Can we look through the folder and see if they're using CommonJS or ES Next and and just >> I mean that sounds easy until you go to a real repo that has like 3,000 files is like they don't match and they're using monor repo with different configs or different folders and it's like yeah all right >> the agent >> can we just walk up the chain until we find a package JSON and look for type module like is that enough or we have to look through other things too >> up the chain until we find that or a git route for example like it's never as straightforward as it sounds like the first time.
>> Yeah.
>> And it will not be deterministic such that it works in 100% of the cases like >> Yeah.
>> So we can do best effort things but best effort in our world is another word for it's going to fail a bunch of the time.
>> Yeah.
>> It fails 1% of the time and we have a million installs. That's still 10,000 people that are stuck.
>> Exactly. Law of large numbers starts hitting you. Sorry.
>> Is it slower to have ampts file?
>> I don't think so.
>> I mean, what's where where is the pain in?
>> Oh, the pain is just that it looks weird for people who don't use.
>> Yeah. So, I mean, you'll get used to it.
We pine did a review of all the the like nextjs vit all the things and they all support or ask for mgs or mts. Now they're config, right? I mean it's it's the future.
>> Yeah. Yeah.
>> I'm inclined. That's why we land there.
>> We should do it for new. That's fine.
Like otherwise people will be like, "Hey, why do you have a TS there and MTS one here?" Like, do I need to change it?
Do I need to migrate? And should we get a new PM? It will be easier. Yeah, >> I think you should. I think you should.
>> I think it's telling that like Palumi I did this research before and then I looked at it again just now. Like Palumi, it's very well known. It defaults to CommonJS. It has full support for ESM and top level away. It defaults to CommonJS because it's the lowest common denominator that works most of the time >> is my assumption is why they do that.
And then they have docs that are like, oh, if you want to use top level await, it's very handy. Do this. Like, you know, move to ESM, this is how you do it. We need to use a weight and we don't want to have to use main because that looks ugly.
>> Yeah.
>> It it really is just like I don't know.
It's one of those things that I think we're spoiled because we're a relatively new product. So, we can be like, why are you doing this the old way? Like we just made the decision to not support old yarn because like really that has been out of support for so long and we're making these decisions innet land where we have much more ownership over the stack and knowledge of the stack and why decisions are made to not support older patterns. Yeah.
>> So like we should be treating JavaScript the same way. But the reality of the ecosystem is like there's a lot of people using the old ways >> and not migrating to the new stuff for reasons. And it's like, oh, at least with the.NET stuff, we can control some of the reasons people don't want to migrate. Like, we can go and fix that, but we don't own JavaScript. We we own we know we know and we work closely with and and we have some leverage over Typescript, but Typescript is a is a wrapper. It's not a language and a runtime.
>> It's also just a culturally different community ecosystem, right? And it's much larger. So those two things combined just give you more variance which makes it difficult to say we're going to pick this one thing and you're going to love it. That's what we're going to do. Um but it's also practically impossible to make it just work all the time because there's just too much variance.
>> So I that's why I'm agree with Seb like I I landed on the let's just use the extension that always works.
>> Yeah. this is the highest chance of working even if it's the newest thing that some people might look at and go why are you using that like why not just configure it it's like well because that's really complicated.
>> Yeah. All right. I'll live with it. Also the now since I decided it um the official NodeJS version supported are 20 24 and maybe 26 >> and maybe 26 >> just be well you know it's officially supported as long as we we can test it okay which we do we test it we verify it we exercise it so it's it ships well we We ship a new version if the build works, if our test work on node 20 and node 24. But node 26 we could not do it because there is no mcr container for 26. So we can't test it on our CI, >> right? But it should work. It should work.
>> Yeah, sure.
>> It's super new. So I mean we have an MCR container.
All right, you're showing us Kubernetes, Rob. What? What in God's name?
>> Okay, Kubernetes is awesome. Just saying. Um, in >> No one ever said no one ever. YAML is awesome.
So, I >> first I've ever heard say that is Shane Boyer.
Hi, Emma.
>> I added the um add Kubernetes environment piece. I added the nuette package and that allows me to say aspired do deploy and it just spits out the thing which is really cool.
I said I want to do ingress because um I wanted to play with that and so I wanted my API service and my front end to be behind ingress and so it spit out this ingress and there's some bugs in that template like curly brace zero curly brace is not a thing.
So let's go find here in the host too.
It's like >> it looks like something didn't get processed that was supposed to be processed. That's what it looks like, >> right?
>> And so that's that's the first thing.
It's just like a bug in the process template.
>> This uh Helm chart though is kind of huge. It's kind of complex. Um there's a lot of configuration in here that you know if we're um it feels like this could be simpler like we could make some opinions about what needs to be in the thing and then um make this values yl shorter like knowing that these hotel settings are the same between things. Let's move them into a common spot. Um, you know, maybe we just make opinions that those environment variables are baked in or maybe um, you know, these feel like setting config map details or secrets and so move them into a secret instead.
I like for the API service there is a config and that's cool, but it's basically just harvesting the um, values YAML. So towards uh um the goal I know is that if I just deploy it just works and for me this feels like a good template like I would take this um Kubernetes YAML Helm chart and then start hacking on it to build the one that I wanted and that does mean that I forked it and now if I aspire deploy to Kubernetes again that it's um not that anymore and so there's a process of keeping that up to date that now has more overhead, but it's like this this Helm chart is kind of complex.
Um, especially the values YAML file. It just feels too big, >> huh?
>> I'm getting uh like OM generated SQL vibes like like it's a forever like thing when you when you have something else that's projected into something else. like this is a constant thing of like how can we refine what we project to be more idiomatic or more optimized for human consumption. Um this is the first iteration obviously of our of a lot of the Kubernetes stuff. Um >> and so like yeah this is it'll be interesting to how this how we optimize this. I haven't looked at any of the Kubernetes stuff yet. It's like so new.
Um >> I love that we're trying and so the first iteration building that Helm chart that's definitely moving in the right direction. It's just it feels like it's not there yet.
>> Yeah, >> it's good. That's >> Here's another with the Kubernetes stuff. Um I could say uh where is it? Front end. So I create this ingress and it's like well how do I connect this ingress to both the front end and the back end? Um you know I want to be able to build that v.config config kind of thing that says um slash goes to the front end and slash API goes to the back end and it's like there aren't um you know with default backend that got me started but it's like how do I configure the next one dot with backend oh with path is um yeah I guess copilot just made up a method but like configuring this ingress was hard and so I'm not sure how best to do that. The other thing that I want to do is I want to say if environment >> is development then add YARP and I don't remember. Oh, there we go. Um, so now in deployment it uses a Kubernetes ingress and debugging it uses Yarp and it's like well now if I need to do something like um u connect the things it's like well how do I is there a way to abstract this into a single abstraction that I can start to use elsewhere.
I've configured my routes twice which you know it's easy to get those out of sync. It's like can we create a a ingress abstraction that I could then project my routes into both Kubernetes and Yarp. Um you know that would be kind of a cool thing. I don't know how Oh, it's missing a using statement by the way. Um that's why it's mad.
Um I don't know how best to solve that but that's the problem that I found is that deploying an ingress and debugging with Yarp is hard.
>> Yeah we haven't abstracted the concept.
We don't have a gen generic primitive of type like ingress.
>> Yeah run as ger is interesting. Yeah.
Like so we have we haven't got super opinionated about this yet. Like ingress as a concept rather than what Kubernetes ingress is, >> right?
>> Is concept.
>> Yeah. Reverse proxy, whatever you want to call it, right? Like again like getting the simple concepts >> baked seems pretty straightforward, but again there's like people who have been in the industry a long time. You've probably worked with many different reverse proxy servers. I know I have and the concept of what that is over time has evolved.
Coming up with a way to express that generically that will scale well. Um I'm I'm I'm a little concerned about like it's possible that when we build more than one of these like we've built the ARP one now and we've just started on the ingress one. It's possible as and we just support we just shipped or we just finished Azure Front Door as well which is another example of a of a service that is a reverse proxy. Um, so it's possible that we could look at those three things on a whiteboard and go, "Yes, there is a distillation here that we can create a a an abstraction that maps really well without like losing all the fidelity." But I'm not sure that's true. Like I very often with these things, you want to immediately punch through to the specific configuration knobs and features of the actual thing you're using. Um, but maybe the route thing is is the is the exception. Maybe it's the idea of map this to that that we could build a DSL for effectively and then project. But um I think that'll become more evident as we build more of them out. But yep, understood. I I think the argument we would give to not build something in right now is to say to you, well, you write C#, go and write your own diction, you know, string to dictionary, whatever, or object model and write your own extension method and then you map it to the two that you want to to have it and see if it works well for you rather than immediately forcing this down to the lower layer that is Aspire that has to serve literally everyone and literally every integration. often it's better to simply do that dduplication in your app rather than where where you know there's only two. It's y and it's ingress and that you only have to make those two work together versus an Aspire ingress primitive which has to work with every reverse proxy that you'd ever want to reverse uh integrate with Aspire. So that would be my first round of advice.
>> Yeah.
Yeah. Some kind of dictionary of strings. Um >> endpoint that yeah >> and then of course you have to invent a language because typically you want placeholders just like routing and express and routing in a minute core you have placeholders and things and so >> it gets and the systems often use different placeholders holder syntax. So we would have to settle on one for our abstraction or some object model to represent those and then we'd have to project those. So >> well the cool part about ingress is you're just picking path prefixes.
you're not picking the full path.
>> And so I'm not saying slap API order number. I'm just saying slap API order goes to the the order microser and slappi product goes to the product microser and all the rest of the URLs within there also go to that container >> in theory. Yeah. Except the very first thing that we often hit with setting up reverse proxies on Aspire Fridays is does the reverse proxy we're using default to keeping the prefix or stripping it? And then if it's the opposite, how do we turn that off?
Because depending on the app that we're doing, we have to like conform to one URL shape versus another and we burn we've burned so many hours trying to get that right. Um we would have to make a decision on ours in Spire like we strip prefixes by default and then we'd have to let you turn that off and then project that to the underlying integrations settings.
And I I like because >> um >> then I get a natural map like here in my API service. I know that this is >> um slashweather slap API >> yep >> weather forecast and that naturally maps. So now I can debug it in the same way. I can do all the things. It's just >> it just works. um you know that happens to exactly match my mental model of how I set up my reverse proxy. If I strip those prefixes then suddenly it doesn't map correctly. And I realized that stripping prefixes is a good way to ensure that enterprise gets to dictate the thing and the apps don't have to figure that out.
>> Yeah.
>> But I lose my mental model as I try and cross that boundary.
>> Yeah, I get it. And then totally get it.
Um, it's just, you know, sometimes you're reverse proxying to something you don't own and you don't own the URL space and then you, you know, then it's a totally different set of problems you're trying to solve. So, >> that makes sense. Yeah.
And by the way, that is impre incredibly impressive to try and take on with TLS like to rig up manager to rig up um core DNS to rig up the let's encrypt doohickey like that was really aspirational and well done. Aspire mentioned.
>> I I Yeah, that's that's pretty much all Mitch I mean Mitch wrote >> the let's encrypt.net stuff too like right or um No, it was the what did he write? He contributed a net library to something so that we could use it.
>> Stig store.
>> Sig store is what he did. Yeah. But like a lot of that wiring up of stuff like Mitch was like, "Yeah, we have to do it.
Let's just do it." And did it. So that was cool.
>> Yeah. TLS is a forever thing like like we we will forever trying to make TLS just work by default and make it easier no matter if you're on the dev box or not. And like we've got David on the stream like we've been working a lot to try and make TLS just light up with your Vap and just roll up with Node and just light up. And it's a forever battle, but we're going to keep doing it because >> yeah, >> it's important.
>> TLS is hard and intentionally so I think.
>> Yep.
>> But once you get trust chains, it, you know, mixert makes that a whole lot easier because Mixert kind of just like fixes trust chains as long as you copy that root around.
>> Yeah. Which is what we do with the devert, right? Currently, we we just piggyback on the aspore devert and we copy it around. But we have aspirations to not use that C and to have Aspire completely um build its own C infrastructure um and use intermediates and things.
>> Yeah. So that that's the plan. That's the longer term plan um is to move off.
>> I love that.
>> And then beyond dev as well like because you know for certain resource types you need to do search. You can't avoid it because you're not even using it for TLS. using it for other reasons. And so then the idea of a a cert manager as a primitive in Aspire that when we can issue searchs for you and you can use them across your services and stuff is definitely on the road map.
>> That sounds really cool.
>> MTLS is another one. We haven't even gone to that one yet. Mutual TLS is the reason to own your own search though. So >> yeah, mutual TLS is super hard.
One of the things that a lot of our templates assume is that they're all baked in oh save sorry that they're all that they end up all baked in one container. And so um I don't know how we better do that. I like how you're like if >> we're losing you again >> explain if we ask or not then that adds additional complexity if we create more resources by no this bake the front end in microser and that feels like a fragile assumption I I think we lost you for a piece of that.
>> Yeah.
>> Did we get >> I know.
>> Did I go robotic again?
>> Just just a bit.
>> Yeah. Try that. Try that one more time and hopefully it doesn't cut off this time.
>> Okay.
Um, one of the things that Aspire that the Aspire templates assume is that I only have one backend microser and so I can bake the front end into that backend microser.
>> Yep.
>> And I I totally get the value of the difference between a starter template and a demo template. And so, um, I don't know. I I can see both sides of it. It's like do I prompt the user in the template to say do you want to shove the front end in the back end that adds additional complexity. Do I um if I don't shove the front end in the back end now I'm deploying more containers together with a reverse proxy and now it's like the argument is are you trying to sell more Azure but this just this rubs me wrong to try and push the front end into the backend container. If I have more than one micros service, I definitely don't want to do that. I want to grab ingress instead. And so it's like, well, do we set up a YARP in the template? I don't know. Maybe this is a sample that doesn't push the front end to the back end. It just >> I always tend to remove that publish with container files line.
>> Yeah, >> I could see us asking the question. I think you could possibly ask a single question for this template about do you want to use a reverse proxy or do you want to deploy it as one app? Um >> and that that would give you the flexibility you're looking for and then if people and the default would be keep it simple the default answer would just be emit what we have right now which is you just get one thing because it's simple but you can always choose no I want a reverse proxy and then now that we actually have the publish we didn't have the primitives to represent that in like when we built this template it's only with the work did in the last release that we now have easy methods to to to deploy it different ways So I could see us doing that.
>> And I realized as we're talking about reverse proxies, it's like now we also need to synchronize the V config.
>> And so yeah, this gets big.
>> Yeah. Like is there an environment variable that we can inject that we can then read in the V config to know what how the proxy relates to all the things like that? That's hard.
>> It is.
>> It's all very manual today. Agreed. And again to to make it not manual, we would have to invent >> a thing that we then push into all the places.
>> Um >> yeah, >> but yeah, >> and then you'd end up with something like um service my name_http_zero for some apparent reason.
>> Well, that so I can tell you the reason.
I'm glad we moved away from this towards the just simpler.
>> Yeah, >> the reason it's zero is because that original syntax which is still supported uh supports blind side load.
>> I understand how it is. You know that's the endpoint name and it could be more than one. So there's but it's like >> that is just a huge mouthful.
>> It is it's specifically to support um multiple endpoints for client side load balancing. There's an argument to be made. We should just inject one without the suffix as well and that's just the first address. Like we could just do services my name HTTP and if you do that we just give you whatever the value of zero is. I don't know why we didn't do that honestly. We could there's no reason we couldn't just give you the first one right and then if you want to do the ordinal based then you could. Um but yeah now we have the the simpler thing. So >> this is just so much simpler. I just love it.
>> Yeah.
So actually a question about that Damian >> like that syntax only applies on i resource with service discovery right like that isn't a okay that isn't >> yeah so that's all based on the original service discovery features that we built back when it was justnet and there is a client library you Microsoft extensionshps discovery or service discovery http and there's like a whole it's a fairly complicated >> client library stack that supports like all the things you would expect a C# extensions thing to support. Um, but part of that is we were very confident that we would need to do client side load balancing and the reality is very few people actually do that like in the real world. GRPC does it by default but you don't see any of it. It's like a thing they they just support >> and we were trying to build like super durable productionreadynet cloud services and in and there's opinions in some circles that to do that you need to do client side load balancing because then you can implement various patterns um that you that we know teams at Microsoft implement for their very very large scale services. For example, you have a logical endpoint that you want to talk to your accounts service and it's scaled out and listens on multiple different addresses, right? Multiple physical addresses rather than going through a load balancer and having it pick one and then coming back. You can do client side either load balancing and or um racing. So you actually send two parallel requests to two different addresses and then you pick the result that came back first.
So that rather than you always being at the mercy of whatever latency you get for the request that you made, you could fire off five requests to the five different servers that are currently serving that API because they're all stateless and then you just race them and then whenever the first one comes back, you cancel the other four. That is a thing that real services in very large scale do. And we have net libraries shipped by our team that do that by default and this naming scheme supports that. That's why it works that way. So yeah, >> that's cool.
>> Yeah, >> that's also a problem that the majority of us don't hit though.
>> No. So it's part of the HTTP resilience patterns package in Microsoft extensions. There's all these various patterns you can implement. They have like special names.
>> Um, and this scheme was designed to support all of those.
>> Um, so that's cool.
>> That's that's why it works that way. But again, supporting more stuff, more complexity. you often end up seeing the complexity and default scenarios. When you're in C using Aspire, you never see those environment variables ever. Like they're all masked by the fact we just inject them and then they're read automatically by service defaults and configured client. Once we moved out of C where we had opinionated client side stuff as well as server side, then we needed to do something like you see now on line 18 where it's just like, hey, now I just need the HTTP address for my for this API.
I like that.
>> This is the stuff that makes me just so glad I am not an enterprise web developer.
>> It's Yeah, like it's that again, those of us who have been around for a while, like decades have seen all of this stuff. And the they all these patterns exist for reasons.
>> Like they absolutely exist for reasons.
Um, >> yeah, >> it's but you don't want them in your like when you're building an app for the first time. You do not want to start there. It is like makes no sense to start with these things. Is so many moving pieces.
>> Yeah, good call. A new developer to Aspire doesn't want to have to deal with reverse proxies just to get a web app and an API behind it.
>> Yep, exactly.
let alone client side load balancing and resiliency patterns that do parallel racing and like all the stuff that you could do an enterprise template make it do by default and like a lot of the if you go and find like the Azure architecture template type stuff they do have a lot of these patterns in them by default and that's why those templates are enormous and there's like literally dozens and dozens and dozens of moving pieces and concepts you have to understand to be successful using those. Um, >> just before you can start playing with the template, >> before you can get hello world working.
Yep.
>> Yeah, >> it is truly amazing that anything works.
I know I say this a lot, but like it it's amazing. It's amazing. You can go to the web and it works, but >> yeah. I mean, to to draw maybe a an odd parallel, it's not that different. Like if you're into engines and you look at how the internal combustion engine has evolved over the 140 years it's been around like you can build an engine that very rudimentary engine with very with the quite a few and understand the concepts pretty straightforward. A modern engine is not anything like is based on the same fundamental concepts but is literally a thousand times more complex and there are all the reasons for that to exist are there whether it's efficiency or reliability or performance or all those type of things cost effective. Yeah, >> there's reasons why things get more comp complicated. Um but you would not want to learn how an engine works by opening the hood of a modern like super efficient high-end engine. Like you would just be lost in the first five minutes, right?
What do you mean it doesn't run unless my fuel injector or whatever?
>> Yeah.
>> Yeah.
>> Exactly.
>> My computer clock is off and suddenly >> Yeah. My timing signal is slightly out of whack or what? My knock sensor is firing a little too early or like Yeah.
No.
>> Yeah.
>> This is a classic XKCD. I do love this one. So >> Oh, yeah.
>> The >> So that's all my gripes of things that I wish were different in Aspire. I just think Aspire is really cool in in um kind of uh presenting open telemetry without pushing open telemetry in people's faces. It's really easy to get started because the new templates are just really elegant and kind of showing those varieties.
>> Yeah.
>> And as a launching point as I'm demoing it, it's like I'll just aspire new and and then run with it. The talk that you saw me do in Belgium was exactly that.
It had nothing to do with Aspire, but Aspire New was the easiest way for me to get there. So yeah, Aspire is pretty awesome.
>> That that did make me really happy when did your talk because I was like this is something we tell people all the time like don't you don't have to make a talk about Aspire but just use Aspire to demo you know use Aspire as as an implementation detail of your demo >> and it really just helps stuff and it helps us you know like get more eyes and and the best way to explain Aspire is to use it.
>> So that's that's that. But yeah. Wow.
This was, you know, Rob, this was pretty good. This is pretty good. I'll take it.
Yeah. I'm um >> I took a bunch of notes into my co-pilot and I have like seven things I'm going to go follow up on. But >> Oh, sweet.
>> Yeah. This and then put up PRs for whatever, you know.
>> Yeah.
>> Now that I found the templates, it's like, you know, we get to argue about them. I'm going to rename the API into API and and we'll see where that goes.
>> Yeah. just do it in a separate PR of anything else you want merged.
>> I would say add the option that we talked about. Just add make it ask you do you want do you want a reverse proxy and if you say yes we you can change the name of it to API in that one and then we'll just leave the default one what it is today.
>> There you go.
>> I really love that too. Do you want a reverse proxy and then put in Yarp with the fallback to Yeah. Um and then that starts to give us opinions around how can I abstract it a way that I can push it into Kubernetes ingress at the same time or push it into Azure front door.
You know, how do we create >> Right.
>> Yeah.
>> Yeah. I don't like that.
>> And I would like to see a bunch more samples. You know, it'd be really cool to have a Blazer Wom sample. It'd be cool to have a Vue.js sample, but you know, I also get that you don't want to be in the business of keeping samples up.
>> Don't we have a Vue.js JS sample.
>> We have I misspoke.
>> We have client apps. Where is it?
>> Oh, template. I see you want a temp.
Yeah.
>> Yeah, we're not going to do that.
>> No, no, no. Sample. You said sample specifically. So, we do have a Vue.js, but it's like really light, really lightweight.
>> So, >> yeah, >> we have a view, a spy with JavaScript sample that has V, Vue, React, and Angular in the one sample. So, all the same app written four different times.
That was David Pine a long time ago. So that is >> so I clone the sample and delete three of them >> if you want to build a view one or just copy and paste it. But yeah, clone it and then copy and paste the folder that you want. But we are not going to have this many templates. Like it's just not going to happen. We're not going to build it out that way. That said, >> yeah, >> we do have >> we we have talked about completely overhauling what templates are. And for example, building a scaffolding/template system. that's just based on git repos.
So you could just say yeah like I'd want to make me a new one based on this one over here. Um so you know never say never but certainly given using the template infrastructure that we rely on today we do not want to add more templates. It doesn't scale. It's like it is literally a mixture of net packages and hardcoded templates in the actual CLI source space and we kind of merged them together and we know it doesn't scale like we did that on purpose because it was fast um for us for us to get it out there quickly but we we have ideas to completely overhaul that we just haven't prioritized >> and so I see you know you as you added TypeScript you added a few more templates and that's totally fine and yeah so keeping the templates concise is really All right, I'll take it. That was pretty good. Thanks, Rob. Happy Friday, everybody.
>> We We might We might do Pearl next week, TBD, or it'll happen after build. So, like, come come stay tuned for that. Now that you've officially been indoctrinated to Aspire Fridays, Rob, too. You're gonna have to come watch the rest of them.
>> Um >> Oh, yeah. This is a whole lot of fun.
>> Yeah, these we have a good time. What can I say?
>> Yeah. Um, what else is there? So, we Yeah, 133 servicings have been shipping all week. So, keep keep updating, keep doing the things. Um, join the Discord if you aren't. I think I have the link.
Yes, Aspire- Discord is a great place to chat with everybody and to hash out opinions and and share memes and feedback. And um, Rob, when's the next place people can find you? Where can people find you if they want to chat or something?
>> Robrich.org. has on the top right all of the socials and so you can find me there. Um you can also send me an email from there.
>> Robrich.org. That's pretty easy. Yeah, >> that's a nice that's a crisp domain.
>> Yeah, >> it helps to have a small name. Mine mine is long because my name is >> Well, no, Rob's full name, the fully the government Robert Richardson is a long name.
>> I would argue Richardson contracts nicer.
>> That's true. Rich Edwards. I guess I could be damned or something.
Damned.com.
>> Damned.com.
Okay. Wait a second.
>> That's awesome.
But it's also really easy to transcribe or to flip around. Um, I'm not Rich Robertson.
>> Oh, I think I called you Rich in my head before, too. So, that actually that checks out. But, you know, >> whatever. So, all right, everybody. Nice to see you all. Thank you Rob Rich Rob Rich for coming and keep the feedback rolling and we will see you next Friday.
Bye.
Related Videos
Agentforce NOW AMA: Build with React and Salesforce Multi-Framework
SalesforceDevs
490 views•2026-05-28
How agent o11y differs from traditional o11y — Phil Hetzel, Braintrust
aiDotEngineer
450 views•2026-05-28
WEB TECHNOLOGIES UNIT-2 | Degree 4th sem BCOM Computers web technologies unit-2 full explanation💯✅
LearnwithSahera
1K views•2026-05-29
More tests are always better? How to use AI to identify tests that bring little value
Alliance4Qualification
335 views•2026-05-29
Search Algorithms Explained in 60 Seconds! 🤖💨
samarthtuliofficial
218 views•2026-06-01
People of Game of Thrones using JavaScript DOM
AltCampus
296 views•2026-05-30
Introduction to Problem Solving Part - 1 | Lecture 1 | Intermediate DSA
ascensionix
107 views•2026-05-29
🚀 BCS613C Compiler Design | Module 1 to 5 Schema Evaluation 🔥 | VTU 6th Sem 💯 #VTU #bcs613c #exam
Pranavaa-y4y
104 views•2026-06-02
