Patrick, your channel is my goto place for learning new things about dotnet web development. I follow some other dotnet youtubers like Milan Jovanovic, Nick chapsas etc but I really like the way you present the code and explain the concepts. Thanks. 😊
Vivek, you can't believe how much your words mean to me. Mentioning me alongside Milan and Nick not only made my day - it made my year, I guess. 😅 Seriously, thank you so much!! Really appreciate it. Cheers! 🎉
I enjoy how organic and sincere are the steps you present. Especially when you forget/mistake a word and put a comment giving a “spoiler” on whats wrong. Also how specific are each videos demonstrating specific features. Congrats man.
I think like you mentioned having the duel is super awesome for backends and frontends, Your front end stuff is quick, SEO, and just displays quick data. and the backend is the admin portal, where having it download doesnt really hurt the users, but then moving around and doing all their updates etc, and scaling is super useful
I hope that in the final release we are going to have the new Auth with all the page done in Blazor. I really would like to see a video about it, including how to modify and extend the models and classes.
Second that. A start to end view on setting up a API web server and then getting a WebApp doing all the authentication using the API Server. JWT and Refresh tokens. Nothing out their showing start to end with .net8 at this time. Belive 'IAmTim', is going to do a video once released.
Thanks for the awesome content, Patrick! Something nice to see in net8 would be the option of blazor, mvc and maui templates with tailwind instead of bootstrap :( I dont get why Microsoft hasn't done that yet
hi patrick , good day to you. i do really appreciate your hard work and dedication in sharing your knowledge on this topic. just a question though, with blazor web app, can you still do lazy loading of separate say RCL?
When to use this template? To make this clear, today we have apsnetcore api with template. What if I want to migrate this to use the blaozr web app template, how all area and parts will work?
It still isn't clear to me whether it always make sense to use the new Blazor Web App template, as opposed to sticking with the Blazor Web Assembly template. I get that .NET 8 has added a bunch of new features to the Web App template, but for say, a LOB app, Web Assembly should still work fine and you avoid all the additional complexity around rendering modes.
Thank you for this overview. Maybe I am being pedantic here but here's a question about the final example: with the .net 8 approach, it isn't really clear to me which project would be deployed to a server. What would you deploy here? The BlazorDotNet8ServerAndWasm app AND the BlazorDotNet8ServerAndWasm.Client to the same server? Here are my long-winded thoughts on this!: I think the way the .net 8 projects are now structured is potentially confusing. Maybe I am missing something obvious. Take the final example you made, where you have a Server and WASM (BlazorDotNet8ServerAndWasm). The template will then produce 2 projects, the "main" BlazorDotNet8ServerAndWasm, then the BlazorDotNet8ServerAndWasm.Client project. Using .net 6 Web Assembly approach that you used in your ecommerce course on Udemy, it was very clear: you had a Server, a Client, no confusion. And you could theoretically deploy the server and client to separate servers (in reality that would be quite a common requirement - I have always had minimum 2 servers for deployment regardless of what stack I used... 1 for the public Website, 2nd one behind a firewall for the API, and only the API server had database access to block any outside access. Main Webserver never had direct DB access). All that said, there are some incredibly useful features in this release candidate... especially the render mode flexibility for various components. It gives us the best of both worlds. Thank you for putting this video together.
Hi @colllm For now, just think of the client project as a way of clearly defining exactly what .NET code is sent down to the client browser. No .NET code in the main server project will be sent down to the browser. For many of us, this clarity is important for security reasons. For others this is important so they can ensure the size of what is downloaded by the client is minimal. There is no reason your server project (such as when running the Signalr/InteractiveServer option) can't use any of the components you put in the client project, but you do need a line of code in Program.cs telling it to include components in that client project. It should give you peace that if you included this line in a server component: string myPassword = "Why did I put a password in my code"; You don't need to worry about that being included in the WASM stuff being sent to the client.
Absolutely understand where you're coming from. Having dabbled with RC2 (video on that coming up), I too felt a bit nostalgic about the ASP.NET Core hosted structure we saw with the earlier Blazor WebAssembly setups. With this new Blazor Web App Template, the Web API project isn't quite needed in the same way. To put it simply, the Blazor Server project now embodies the Web API. It's fully equipped to handle all the API needs, so you have the flexibility to integrate controllers if that's your approach. However, since you're inherently on the server, it's not a necessity. When you're keen on utilizing any server-side services within the WebAssembly project, you just link the reference, get them onboarded in the Program.cs, and you're set. One hiccup I find is the absence of an out-of-the-box Swagger UI for immediate testing. Nonetheless, it's feasible to isolate services, like those connecting to a database, and house them in a distinct class library project. This approach provides a neat separation of logic. While the Blazor Server project remains the primary startup project, there's freedom to host an independent Web API on an alternate server. There's a world of possibilities, but it does require a bit of acclimation. I sense that those who've deeply engaged with Blazor Server more than WebAssembly might find the transition smoother. My instinct tells me we might be nudged towards adopting a more streamlined architectural approach with this template. And honestly? That's not a negative shift in the slightest. I'm sharing this based on a couple of hours of exploration, so I'm curious - what are your thoughts on this?
Microsoft wouldn't be itself if it didn't change something during this 2 months from video release. Now startup of new Blazor template looks completely different :)
I think they really need to clarify the "render mode" names. StreamRendering vs ServerRendering when both are rendered server side. vs AutoRender, which is Stream first then client, or Server first then client? Also, I think they started calling something Static Server Rendering, which really doesn't seem like static rendering to me. To me "static" rendering would be a build time thing, where you render your site to static HTML at build time and just deploy the HTML.
I agree the names could be better, as you have server, server side rendering. As for the auto, from what I’ve read at the moment they don’t even know fully how it will work, or when the switch will happen, I guess data will be super important.
@@ConorDrewFrom the stand ups I've watched Auto will work like Blazor Server if the dotnet wasm runtime isn't downloaded yet, and it will d/l stuff. Next time that page is loaded with will be client side. There will be no data switching etc.
Nice video, thanks Patric, I am looking forward that they implement hosted mode as well as IdentityServer within it (the latest version of it), also having that IdentityServer endpoints exposed would be very good so we could build our own identity pages.
Looks great. What about RCL (Razor Class Library) in .net 8. How do you link this or is it work the same as it does now and I simply add this to existing Razor pages in the DotNet8.Client project but add the Render Mode? EG, adding another Razor component to a root Razor.page would look something like... eg
@@ConorDrew As in the OIDC authentication provider for Blazor Wasm doesn't work with the new template, has no ability to add authentication from the cli, and can't be added manually into a state that works. And the OIDC Authentication provider, even if it worked, explicitly states that it doesn't support code flow, only implicit flow which is depreciated for security reasons, thus meaning that no one should use it to deploy to production. And the new authentication stuff in .net 8 is just OIDC implicit password flow without the discovery endpoint and the endpoints themselves renamed for some reason. Even the payload of the token request is virtually identical. And it has exactly the same security vulnerability as OIDC implicit flow. As a result it shouldn't be used as written.
@jameshancock I am more comfortable for now with the dual project approach. Even if they had achieved their goal of a single project, I was concerned how you would stop someone accidentally including something intended for server side and having it shipped to the client. I think this is a reasonable start and they need to put a lot of though into doing this as a single project. For example, maybe as a single project, they would need you to be explicit about exactly what is included versus stripped from the project on building the WASM part. Regarding the OIDC stuff - are you talking about the new auth endpoints? because they have been clear this is not an OIDC implementation. I have not looked at it closely enough yet to comment, but have heard loud and clear it is not OIDC.
@@PortalUser2 dual project would be fine but the Auth provider for the wasm side is broken entirely. They claim it isn’t oidc implicit flow and they’re correct. It’s the even more outdated oauth2 rops flow that if you allow anyone but your own clients to use it is insecure. Which, given that the only thing stopping someone else using it is client id readily available in the browser, it’s insecure day one. ONLY code flow is even marginally secure in browsers. This isn’t it.
Patrick, your channel is my goto place for learning new things about dotnet web development. I follow some other dotnet youtubers like Milan Jovanovic, Nick chapsas etc but I really like the way you present the code and explain the concepts. Thanks. 😊
Vivek, you can't believe how much your words mean to me. Mentioning me alongside Milan and Nick not only made my day - it made my year, I guess. 😅 Seriously, thank you so much!! Really appreciate it. Cheers! 🎉
I have to second that. Patrick's explanations are crystal clear.
@@colllm Thank you soooo much! ❤️
I enjoy how organic and sincere are the steps you present. Especially when you forget/mistake a word and put a comment giving a “spoiler” on whats wrong. Also how specific are each videos demonstrating specific features. Congrats man.
@@joaoalbertofn Thank you so much! Really means the world to me! 😊
I think like you mentioned having the duel is super awesome for backends and frontends, Your front end stuff is quick, SEO, and just displays quick data. and the backend is the admin portal, where having it download doesnt really hurt the users, but then moving around and doing all their updates etc, and scaling is super useful
Glad you feel the same way. Thanks for your feedback. Cheers! 😊
I hope that in the final release we are going to have the new Auth with all the page done in Blazor. I really would like to see a video about it, including how to modify and extend the models and classes.
I think Nick Chapsas does a vid on it.
Second that. A start to end view on setting up a API web server and then getting a WebApp doing all the authentication using the API Server. JWT and Refresh tokens. Nothing out their showing start to end with .net8 at this time. Belive 'IAmTim', is going to do a video once released.
Honestly +1 for an Authentication example in this new template because I just can't seem to get it to work. Great videos man!
Thanks for the awesome content, Patrick! Something nice to see in net8 would be the option of blazor, mvc and maui templates with tailwind instead of bootstrap :( I dont get why Microsoft hasn't done that yet
Thanks! Maybe this video helps: ua-cam.com/video/tj4dNN2jQt0/v-deo.html Cheers!
Thank you. It has given clear knowledge :)
hi patrick , good day to you. i do really appreciate your hard work and dedication in sharing your knowledge on this topic.
just a question though, with blazor web app, can you still do lazy loading of separate say RCL?
When to use this template?
To make this clear, today we have apsnetcore api with template. What if I want to migrate this to use the blaozr web app template, how all area and parts will work?
It still isn't clear to me whether it always make sense to use the new Blazor Web App template, as opposed to sticking with the Blazor Web Assembly template. I get that .NET 8 has added a bunch of new features to the Web App template, but for say, a LOB app, Web Assembly should still work fine and you avoid all the additional complexity around rendering modes.
Thank you for this overview. Maybe I am being pedantic here but here's a question about the final example: with the .net 8 approach, it isn't really clear to me which project would be deployed to a server. What would you deploy here? The BlazorDotNet8ServerAndWasm app AND the BlazorDotNet8ServerAndWasm.Client to the same server?
Here are my long-winded thoughts on this!: I think the way the .net 8 projects are now structured is potentially confusing. Maybe I am missing something obvious. Take the final example you made, where you have a Server and WASM (BlazorDotNet8ServerAndWasm). The template will then produce 2 projects, the "main" BlazorDotNet8ServerAndWasm, then the BlazorDotNet8ServerAndWasm.Client project. Using .net 6 Web Assembly approach that you used in your ecommerce course on Udemy, it was very clear: you had a Server, a Client, no confusion. And you could theoretically deploy the server and client to separate servers (in reality that would be quite a common requirement - I have always had minimum 2 servers for deployment regardless of what stack I used... 1 for the public Website, 2nd one behind a firewall for the API, and only the API server had database access to block any outside access. Main Webserver never had direct DB access).
All that said, there are some incredibly useful features in this release candidate... especially the render mode flexibility for various components. It gives us the best of both worlds. Thank you for putting this video together.
Hi @colllm
For now, just think of the client project as a way of clearly defining exactly what .NET code is sent down to the client browser. No .NET code in the main server project will be sent down to the browser. For many of us, this clarity is important for security reasons. For others this is important so they can ensure the size of what is downloaded by the client is minimal.
There is no reason your server project (such as when running the Signalr/InteractiveServer option) can't use any of the components you put in the client project, but you do need a line of code in Program.cs telling it to include components in that client project.
It should give you peace that if you included this line in a server component:
string myPassword = "Why did I put a password in my code";
You don't need to worry about that being included in the WASM stuff being sent to the client.
Absolutely understand where you're coming from. Having dabbled with RC2 (video on that coming up), I too felt a bit nostalgic about the ASP.NET Core hosted structure we saw with the earlier Blazor WebAssembly setups. With this new Blazor Web App Template, the Web API project isn't quite needed in the same way. To put it simply, the Blazor Server project now embodies the Web API. It's fully equipped to handle all the API needs, so you have the flexibility to integrate controllers if that's your approach. However, since you're inherently on the server, it's not a necessity. When you're keen on utilizing any server-side services within the WebAssembly project, you just link the reference, get them onboarded in the Program.cs, and you're set.
One hiccup I find is the absence of an out-of-the-box Swagger UI for immediate testing. Nonetheless, it's feasible to isolate services, like those connecting to a database, and house them in a distinct class library project. This approach provides a neat separation of logic. While the Blazor Server project remains the primary startup project, there's freedom to host an independent Web API on an alternate server.
There's a world of possibilities, but it does require a bit of acclimation. I sense that those who've deeply engaged with Blazor Server more than WebAssembly might find the transition smoother. My instinct tells me we might be nudged towards adopting a more streamlined architectural approach with this template. And honestly? That's not a negative shift in the slightest.
I'm sharing this based on a couple of hours of exploration, so I'm curious - what are your thoughts on this?
Wonderful Learning content !
Do you happen to have any plans to add an English script in the future?
does this blazor web app template also use signalIR?
Hey Patrick, how would I go about adding authentication to this project?
Hi! Could You make video about using gRPC with blazor and JWT?
Hi, thanks for video. Will you update your blazor course on udemy?)
Saw the link in the description) Subscribed
Thanks for sharing. Maybe you can show how MudBlazor can be tied into the new Web App Template?
Patrick nice video. Can you also make one video about deploying blazor app to Aks?
What About MVVM in Blazor WASM with the Community Toolkit
it usefull or not ?
great!
Microsoft wouldn't be itself if it didn't change something during this 2 months from video release. Now startup of new Blazor template looks completely different :)
Please do a Many To Many & One To Many put and patch video in Entity Framework 7.
how to use oauth with this new template?
I think they really need to clarify the "render mode" names.
StreamRendering vs ServerRendering when both are rendered server side.
vs AutoRender, which is Stream first then client, or Server first then client?
Also, I think they started calling something Static Server Rendering, which really doesn't seem like static rendering to me. To me "static" rendering would be a build time thing, where you render your site to static HTML at build time and just deploy the HTML.
I agree the names could be better, as you have server, server side rendering.
As for the auto, from what I’ve read at the moment they don’t even know fully how it will work, or when the switch will happen, I guess data will be super important.
@@ConorDrewFrom the stand ups I've watched Auto will work like Blazor Server if the dotnet wasm runtime isn't downloaded yet, and it will d/l stuff. Next time that page is loaded with will be client side.
There will be no data switching etc.
Nice video, thanks Patric, I am looking forward that they implement hosted mode as well as IdentityServer within it (the latest version of it), also having that IdentityServer endpoints exposed would be very good so we could build our own identity pages.
Looks great. What about RCL (Razor Class Library) in .net 8. How do you link this or is it work the same as it does now and I simply add this to existing Razor pages in the DotNet8.Client project but add the Render Mode?
EG, adding another Razor component to a root Razor.page would look something like...
eg
Auth is broken in wasm portion and dual projects is a mess.
How is the Auth broken and do you mean its a mess from looking at it, or just a mess as in they shouldnt have done it this way?
@@ConorDrew As in the OIDC authentication provider for Blazor Wasm doesn't work with the new template, has no ability to add authentication from the cli, and can't be added manually into a state that works.
And the OIDC Authentication provider, even if it worked, explicitly states that it doesn't support code flow, only implicit flow which is depreciated for security reasons, thus meaning that no one should use it to deploy to production.
And the new authentication stuff in .net 8 is just OIDC implicit password flow without the discovery endpoint and the endpoints themselves renamed for some reason. Even the payload of the token request is virtually identical. And it has exactly the same security vulnerability as OIDC implicit flow. As a result it shouldn't be used as written.
@jameshancock I am more comfortable for now with the dual project approach.
Even if they had achieved their goal of a single project, I was concerned how you would stop someone accidentally including something intended for server side and having it shipped to the client. I think this is a reasonable start and they need to put a lot of though into doing this as a single project. For example, maybe as a single project, they would need you to be explicit about exactly what is included versus stripped from the project on building the WASM part.
Regarding the OIDC stuff - are you talking about the new auth endpoints? because they have been clear this is not an OIDC implementation. I have not looked at it closely enough yet to comment, but have heard loud and clear it is not OIDC.
@@PortalUser2 dual project would be fine but the Auth provider for the wasm side is broken entirely.
They claim it isn’t oidc implicit flow and they’re correct. It’s the even more outdated oauth2 rops flow that if you allow anyone but your own clients to use it is insecure. Which, given that the only thing stopping someone else using it is client id readily available in the browser, it’s insecure day one. ONLY code flow is even marginally secure in browsers. This isn’t it.
These sound pops are very annoying. I keep checking my phone.
thank you!