4 ms·

Full .NET stack. - Self-hosted identity management, "ASP.NET Core Identity", using new scaffolding from .NET 8 - Blazor, using the "Auto" mode from .NET 8: De

by onetoo 3y ago

Full .NET stack. - Self-hosted identity management, "ASP.NET Core Identity", using new scaffolding from .NET 8 - Blazor, using the "Auto" mode from .NET 8: Default to SSR, autopromote to Server mode for live updating components - EF Core for DB handling The idea is to focus on keeping things simple and easy for the developer. The most annoying part about the stack is the way Microsoft names things. Keeping the rendering logic fully server-side lets you use your EF DbContext/entities directly in your components, taking on some (I'd say minor) technical debt to greatly simplify development. You won't need a fully separate SPA with a dedicated API. Not yet, maybe ever. You can migrate your components to Blazor Wasm piecemeal if/when you reach a stage where using Server mode starts giving you troubles.

capl 3y ago
Yeah I've been looking at Blazor for some time, and the .NET 8 updates are great, but I just don't know if I like the .razor DSL and the fact that things are either SignalR (latency) or .NET runtime in the shape of WASM (huge bundle, literally the kitchen sink). The biggest upsides to Blazor is that, as you said, greatly simplify development as you basically have only one code base to think about with Blazor Server, and you save a lot of time not worrying about the backend / frontend bridge. On the other side, there is a demon on my shoulder whispering that the customer doesn't care about developer UX, and they'd go for a native web-app over a latency-riddled or slow initial load web app.
- onetoo 3y ago
  Blazor Server isn't inherently latency riddled. Blazor Wasm isn't necessarily slow to initial load with .NET 8. IIRC the compiler is also really good at trimming the Wasm bundle when publishing in Release mode. The neat thing about the new stuff in .NET 8 is that you can choose the interactivity at the component level, so if some component really sucks when used with Server interactivity, you can take the extra time to convert it to Wasm w/ some backend API. You should also ask your shoulder demon much would even be interactive in the first place. SSR'd pages with forms can get you very far.
  - capl 3y ago
    Hey again. Tested .NET 8 and blazor again, and it wins… I mean it wins by so much that I now default to using .NET and C# for any task web related. Having components be SSR’d by default and then using SignalR later on by interactivity demand fixed by biggest criticism which was initial load overhead. Also I’ve experimented with azure since it’s of course very well integrated with the .NET environment, and I think I’ll use that too instead of digital ocean which I’ve defaulted to before. I thought azure was too expensive, but re-evaluating now, it is actually very generous by giving free tiers which lets you launch without paying a dime.
ttymck 3y ago
I just want to note how much time would be lost to confusion on my team, if we had to differentiate between "Server Side Rendering" and "Server mode"... .NET is such a cluster of poor naming choices
- askarhussain 3y ago
  I ended up moving things to the standalone WASM app just for this same reason. This confusion gets worst if you have different layouts for different aspects of your app, and who knows where things should be placed appropriately. All of a sudden some of the components won't become responsive at all...only to realize that it's pre-rendered. In some cases, even the SSR gets you a quick time to first bite, clicking on a link that takes you to a WASM-rendered page freezes things for a bit while WASM and other files were getting downloaded. The experience turned into a bit of a mess and I ended up moving things back to WASM and so far a smooth ride since then. There's potential with the Blazor Web App approach, only if Microsoft put some heads into revamping that experience a bit better.
- onetoo 3y ago
  I feel like Microsoft's naming division has a mandate to cause as much name collision as possible, so that "out of date" requirements at very big very slow enterprises suddenly and magically target the latest hotness. It is my main gripe with the .NET ecosystem. Don't get me started on Azure.. But once you get over the hump and understand the meaning of the subtle differences, it's possible to make sense of it.

by onetoo 3y ago

capl 3y ago

Yeah I've been looking at Blazor for some time, and the .NET 8 updates are great, but I just don't know if I like the .razor DSL and the fact that things are either SignalR (latency) or .NET runtime in the shape of WASM (huge bundle, literally the kitchen sink). The biggest upsides to Blazor is that, as you said, greatly simplify development as you basically have only one code base to think about with Blazor Server, and you save a lot of time not worrying about the backend / frontend bridge. On the other side, there is a demon on my shoulder whispering that the customer doesn't care about developer UX, and they'd go for a native web-app over a latency-riddled or slow initial load web app.

onetoo 3y ago
Blazor Server isn't inherently latency riddled. Blazor Wasm isn't necessarily slow to initial load with .NET 8. IIRC the compiler is also really good at trimming the Wasm bundle when publishing in Release mode. The neat thing about the new stuff in .NET 8 is that you can choose the interactivity at the component level, so if some component really sucks when used with Server interactivity, you can take the extra time to convert it to Wasm w/ some backend API. You should also ask your shoulder demon much would even be interactive in the first place. SSR'd pages with forms can get you very far.
- capl 3y ago
  Hey again. Tested .NET 8 and blazor again, and it wins… I mean it wins by so much that I now default to using .NET and C# for any task web related. Having components be SSR’d by default and then using SignalR later on by interactivity demand fixed by biggest criticism which was initial load overhead. Also I’ve experimented with azure since it’s of course very well integrated with the .NET environment, and I think I’ll use that too instead of digital ocean which I’ve defaulted to before. I thought azure was too expensive, but re-evaluating now, it is actually very generous by giving free tiers which lets you launch without paying a dime.

ttymck 3y ago

I just want to note how much time would be lost to confusion on my team, if we had to differentiate between "Server Side Rendering" and "Server mode"... .NET is such a cluster of poor naming choices

askarhussain 3y ago
I ended up moving things to the standalone WASM app just for this same reason. This confusion gets worst if you have different layouts for different aspects of your app, and who knows where things should be placed appropriately. All of a sudden some of the components won't become responsive at all...only to realize that it's pre-rendered. In some cases, even the SSR gets you a quick time to first bite, clicking on a link that takes you to a WASM-rendered page freezes things for a bit while WASM and other files were getting downloaded. The experience turned into a bit of a mess and I ended up moving things back to WASM and so far a smooth ride since then. There's potential with the Blazor Web App approach, only if Microsoft put some heads into revamping that experience a bit better.
onetoo 3y ago
I feel like Microsoft's naming division has a mandate to cause as much name collision as possible, so that "out of date" requirements at very big very slow enterprises suddenly and magically target the latest hotness. It is my main gripe with the .NET ecosystem. Don't get me started on Azure.. But once you get over the hump and understand the meaning of the subtle differences, it's possible to make sense of it.