So one of the first mind-shifts I had to deal with is that you no longer have the basic concept of a session in Blazor Server. That seemed like a huge missing piece, so just how are you supposed to keep track of per-user (aka session) data?!! I was really lost and confused at first. You might be too.

You still can keep track of per-user data, and it's way easier. But having lived in the Web Forms and MVC worlkd for so long, I'd totally forgotten that session started out as basically a hack to emulate the way you store data in a non-web application. It's not that you cannot store per-user data anymore, you just don't need the session "hack" anymore! :)

So with the old way that we're used to, it's essentially fill out a form, submit it, then load a page with the new state in it. (Even with REST calls, it's using this pattern internally) Passing the session token told the web server which set of state data it should associate with the request/response. (This has all happened automatically for you for years, so you've rarely ever had to think about the mechanics of it, and can almost be completely unaware of the magic going on behind the scenes.)

Another thing to keep in mind is that by default, an ASP.NET MVC Controller is instantiated fresh for each request. So that's where session came in, as the controller is being re-instantiated for the Nth time, it has no recollection of any data state from it's previous instantiation even for the same use a second ago. But it does know enough to check for a session token and then retrieve that associated data from another part of the server-side code that knows how to maintain data state for a session and will gladly reprovide it to the fresh controller.

But with Blazor Server, there's no longer the same cycle. There's no longer a controller being created and destroyed with each request, with the contant connection of the SignalR pipe (In the background running automatically, almost invisibly), your code stays live on the server inbetween requests (Well not really requests any more, let's just call them user actions or events for now.) So any user data you are storing stays there, as long as you stay on the same page. It's like a single form on a Windows Forms app, or a console app, or whatever local-machine-only code you are running. You don't need to worry about session, because it's just there now! :)

But, you say, what if I need to switch between pages in my Blazor Server app? I'm going to have to do that, aren't I? 

Well, probably, and almost definitely. If you write a truly Single Page App (SPA) then no. But that can drive you nuts, so even in a SPA app, you still will probably group different functionality in different pages. When you switrch pages, then the page code does get torn down when yu navigate to a different page. So you have to use some way to keep some of the app code out of the page and move it somewhere else that stays alive between pages. This is really easy and where dependency injection comes to the rescue.

(I just had something come up, so will finish this post soon, sorry!)