[HN Gopher] Asp.net Core updates in .NET 8 Preview 1
___________________________________________________________________
Asp.net Core updates in .NET 8 Preview 1
Author : vyrotek
Score : 67 points
Date : 2023-02-21 19:51 UTC (3 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| vyrotek wrote:
| Blazor United looks ambitious but sounds great! The goal feels
| similar to that of Remix.run and a few other frameworks that are
| blending SPA/SSR.
|
| I do wonder about the scalability of the Blazor Server mode which
| requires live and "sticky" SignalR connections.
| bottlepalm wrote:
| I have the same question, will Blazor United SSR still require
| a persistent SignalR connection? That's kind of a dealbreaker.
| megaman821 wrote:
| It looks like the first connection will use SignalR and
| download the WebAssembly in the background. All connections
| after that will use the cached WebAssembly.
| pca184 wrote:
| In Steve Sanderson's video showing off the prototype
| (https://www.youtube.com/watch?v=48G_CEGXZZM) he mentions
| around the 2min 15s mark that SSR has no websockets/SignalR
| or even JS required. From what I could gather, websockets
| will kick in when an interactive blazor component needs it.
| And there will be the option start downloading the WASM/DLLs
| in the background. When WASM is ready your app will switch
| from websockets to WASM. Hopefully that switch will be
| 'live', but in the demo it looked like a page refresh was
| required
| tomcam wrote:
| I'm 50% sure Blazor United is a soccer team
| avgDev wrote:
| I have been using Blazor Server for a project at
| work.....Honestly, it is so much better than using .Net MVC/Core
| with js sprinkled in.
|
| I developed stuff in java for android, swift for ios, and now
| mostly work in c#, SQL, .Net MVC/Core, blazor. Microsoft stack
| feels pretty good to me. Getting a start up job is a bit
| difficult, I came across two startups using microsoft stack and
| only one paid SV money.
|
| C#/.Net does have a pretty stable job market but pay is a bit
| lower.
| RagnarD wrote:
| It's easy to start with, as I did, but do yourself a favor and
| move to Blazor Webassembly. Blazor Server handles UI events in
| a centralized way, and network lag really destroys the
| application. It might be ok on a fast and reliable intranet,
| but you really don't want to use it on the general internet.
|
| Standard Blazor Webassembly project setup creates a server side
| project and a client side one. C# code on the client side is
| compiled to Webassembly. You then set up your server side
| functions called from the client side with usual C# .NET REST
| functions. This is less convenient than the Blazor Server
| model, but it captures the actual complexity of internet
| networking. It's also fast. You can put a lot of (hopefully
| non-confidential) processing onto the client side, running
| locally in the user's browser using a huge array of .NET
| library functions including from NuGet. It really is the way to
| go.
| layoric wrote:
| What kind of setup do you have to avoid users noticing the drop
| of their websocket connection due to a deployment? Blazor
| Server development experience is very good, but even for an
| intranet application, it can have a poor user experience by
| default due to the requirement of a persistent connection.
| avgDev wrote:
| It is yet to be launched but it will be used by a small
| number of users in a intranet.
|
| If there are issues I will just convert to webassembly.
| vyrotek wrote:
| The trick is to start the company yourself. :) We're 3 years in
| and full .NET stack.
|
| Is your project an internal app or public?
|
| I'm cautiously optimistic about Blazor Server but I'm not sure
| I like the sticky SignalR requirement. The expectation seems to
| be that the backend server will keep around a lot of state (
| _cough_ viewstate?) in memory associated to that session. It 's
| a very convenient dev experience for sure, but it seems
| difficult to scale beyond internal business apps.
| ofrzeta wrote:
| This is why they recommend using the Azure SignalR Service, I
| guess :)
| vyrotek wrote:
| Indeed. That's that the only way I'd consider it. Luckily,
| they are generous with the free messages. Last I looked it
| was about $161 per day to scale to 100k concurrent users.
| But that's just SignalR. We'll also need much beefier
| AppServices with lots more memory than what we use now.
|
| Not quite sure how it works beyond that when you need
| multiple service instances connected with a backplane. The
| new premium tier I just saw sounds convenient though.
|
| https://azure.microsoft.com/en-us/pricing/details/signalr-
| se...
|
| https://youtu.be/OsdBpMumf_c?t=635
| avgDev wrote:
| It is an internal app, otherwise I would go for web-assembly
| with an API.
| joenathanone wrote:
| Microsoft has been on a roll with .NET releases, it's been a 30
| minute or so upgrade process for us to go from 5 -> 6 -> 7.
| Looking forward to the new Blazor model!
| easton wrote:
| I wonder if it'll be possible ever to do Native AOT if you rely
| on Newtonsoft (which is reflection heavy, last I heard). Yes,
| yes, I know, use System.Text.Json, but I already have all this
| code relying on Newtonsoft-y things :(
| smackeyacky wrote:
| It's worth the work heading to System.Text.Json - even if only
| to make staying up with .NET easier for yourself.
|
| It had a bit of a rough start but it seems far more
| interoperable on weird edge cases than Newtonsoft now, so all
| the "Newtonsoft-y" things you're doing might evaporate.
| snarfy wrote:
| I've had the opposite experience. System.Text.Json adheres
| extremely close to the RFC and barely handles any edge cases.
| Newtonsoft will happily serialize invalid json. Not that you
| want that but if you have a legacy system it's not worth
| migrating. James Newton-King is a Microsoft employee btw.
| runevault wrote:
| Isn't Text.json also faster at this point because it uses all
| the new span goodness and the like?
___________________________________________________________________
(page generated 2023-02-21 23:01 UTC)