New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blazor server-side and static fields #1721

Closed
yself opened this Issue Nov 24, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@yself
Copy link

yself commented Nov 24, 2018

I am wondering about behavior of static fields in server-side blazor. Since the server is a single process, static field values are shared between all sessions. There are no app-domains in .net core to isolate values between sessions. This behavior is inconsistent with client-side blazor, where static fields behave like one might assume, one value per client application/session.

Lot of simple cases where static fields might be used can be solved with DI, but there are a lot of world cases, and a lot of existing code/libraries, where shared value between sessions might be a problem.

I mainly worry about the inconsistency between client and server side blazor. Since a lot of articles I read tend to say, that if a code is designed "correctly", it should work on both, client and server side blazor almost transparently. Such inconsistency of a core language feature as are static fields might be a problem for some.

Has there been any thought about this issue?

@TheFanatr

This comment has been minimized.

Copy link

TheFanatr commented Nov 24, 2018

I'd like to add to this by saying that I have experienced major such issues myself to a point where I had to give up on using a certain library because it was incompatible with server-side Blazor; while I'm not sure this can/should even be mitigated by Blazor itself, I think it's a good idea to discus the idea because it is a real-world scenario. The main issue is with client-side C# libraries for me because they were designed with app frameworks in mind and not server programs, so state information is usually stored globally. With the advent of WebAssembly, and Blazor's ability to transform .NET assemblies to target said platform, would it be feasible to allow certain libraries and user code to run in the browser? Could it also somehow be possible to add pseudo-AppDomains to store global state separately, possibly by firing up a dynamic assembly in a new process? It would be great if this could be looked into; while it would be great for libraries to be designed properly in the first place, it cannot be counted on.

@SteveSandersonMS

This comment has been minimized.

Copy link
Member

SteveSandersonMS commented Nov 26, 2018

You're right that developers need to be careful about use of static. There are two mitigating factors:

  • Virtually all .NET webdev-related libraries are intended for use on the server because historically that's all that was possible. So these will already avoid leaking state across users/requests via static.
  • Within your own application code, it's exactly the same constraint as in traditional server-side ASP.NET code. That is, static shares state across all users, so only use it if that's the behavior you want.

Overall, I'm not aware there's anything specific we either could or should do to change this. If you have specific suggestions please let us know, but in all likelihood I think it's just something that developers need to know about (exactly like with static in traditional ASP.NET apps, or exactly like using module-level const/var in Node.js, or any number of equivalent scenarios with other platforms).

Could it also somehow be possible to add pseudo-AppDomains to store global state separately

That's definitely not something we'd do by default, because (1) it would be very expensive in terms of server resources, and (2) it would break common patterns that you do want, such as using static fields as a cross-user cache of some kind. Developers who really want something like this may be able to start up multiple instances of the application host in different AppDomains, or even per-user server processes.

I'll mark this closed because no specific action is planned. But please feel free to continue discussing or providing a specific suggestion if you have one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment