search

MarimerLLC / cslaforum

Discussion forum for CSLA .NET
https://cslanet.com
Other
31 stars 6 forks source link

What is WASM/Blazor good for? #514

Open tfreitasleal opened 6 years ago

tfreitasleal commented 6 years ago

There is a lot fuss around WASM/Blazor. Sure this a major technical achievement but there are some important points we need to be aware about this subject.

Some context notes:

1) WASM runs in the browser so whatever comes from WASM/Blazor can NOT be trusted. 2) I understand WASM code can't access a database directly. It can access a service that talks to the database. 3) Since WASM code can't be trusted, it should NOT have access to a database, not even using a service that calls the database to run queries. Queries set up by WASM code can be tampered by attackers.

If I want my application to be on the security side, I can NOT move the application to WASM/Blazor and have on the server just a few services to support database access or other application functions that are impossible to be handled by WASM/Blazor code .

So what is WASM good for?

1. Pre-validate data on the browser.

If I run my business rules browser-side, this should deliver a smoother experience to the user. He doesn't have to wait until the form is submitted before getting forms data validation. Then again, using JavaScript/AJAX I can achieve the same effect. The point is how easy would be it to get the same experience using JavaScript/AJAX or using a WASM solution.

Sticking to the validation problem

2. Move the Presentation Layer (aka UI) to the browser

This means you don't need to have any Views specific code running on the server. Your application lazy-downloads the Views code (let's ignore any possible speed issues for now). On the server side you would have a business layer, maybe a specific one to handle the unsafe WASM/Blazor environment.

Referring to CSLA .NET architecture diagram, what about the UI Control layer? I think this is a whole new UI paradigm and the logical answer would be that we need a new UI Control paradigm, as MVC and MVVM were designed for different UI paradigms. Again, maybe this is easier to solve than we can antecipate.

A note about the UI Framework. Blazor is experimental and I'm not not sure at all it's here to stay, even with revisions. The Silverlight experience demonstrated it's quite easy to kill an UI frameworks. On this particular case, I would understand it, as Blazor is just an experiment.

I think WASM is a subject to follow, it may very well become the future in Web development. I can't say the same about the Blazor experiment.

rockfordlhotka commented 6 years ago

I think it is critical to understand that wasm (WebAssembly) is a standards-based construct that is currently available and enabled by default in all major browsers. It is not a plug-in, it is a second runtime engine that sits right alongside the older JavaScript runtime engine in every browser. It just happens to run assembly code instead of JavaScript, and that means more languages can compile their code to run in the browser, because this assembly language has better support for a lot of traditional concepts as compared to JavaScript.

I've done some blogging on this:

If we assume (as I do) that my second blog post is correct, then the future of things like Windows Forms and WPF and UWP and GTK+ and Coco (mac) is basically at an end. Why would anyone write a smart client app that is single platform, when they can write an app targeting wasm that runs on all platforms with near-native performance?

Many (if not all) the problems you highlight around client-side security and whatnot are true for all client-side technologies. Look at the game industry and the constant arms race between hackers and every game-maker. If your code runs on the client it is breakable, end of story.

If your primary fear is having your code run on the client, then the only real option is a VT100 or 3270 terminal, or perhaps even something less powerful than that yet - like an old teletype 😄

People who've been with me in CSLA-land for the past couple decades are probably well aware of my love for the smart client though. Starting with VB1 and going all the way through to today, I think there's nothing better for business apps in terms of providing a highly productive experience to users, as well as the ultimate in scalability by offloading quite a lot of work to the (effective) supercomputers we have on our desks, laps, and even in our pockets these days.

Exactly what UI frameworks will end up running on wasm is hard to predict. Given that wasm currently is supported with compilers from numerous languages, it isn't even clear that .NET will be the dominant player. Or that Blazor will be the dominant UI framework.

Though in the .NET space there's also an early Xamarin Forms port called Ooui, so there does seem to be a lot of enthusiasm by Microsoft and the broader .NET community around wasm.

Personally, I expect that anywhere an organization would find Windows Forms, WPF, or UWP to be valid options for their client experience, that some wasm-based solution will ultimately be the correct counterpart.

I also expect that anywhere that Angular, React, Vue, and other JavaScript frameworks that strive to make JavaScript into an enterprise-caliber development environment will ultimately give way to higher quality and better options that run on wasm.

This may take years. Perhaps as few as a couple years. Perhaps as many as 5-7.

The one thing wasm does for certain, is breathe new life into the entire value proposition of CSLA, by enabling the full use of mobile objects and the data portal between a truly cross-platform and web-deployed client, and your app servers.

Which means that I don't need to ultimately abandon C# and .NET and write everything (client and server) in JavaScript - something I've been avoiding for some years now. With a little fear, but also a great deal of confidence that JavaScript would eventually fall from grace and gain a true competitor for client-side development.

tfreitasleal commented 6 years ago

News of desktop applications death are greatly exaggerated

I've seen a lot of unfulfilled promises, bunches of "the past is dead" statements. That's a human thing: try to kill the past to promote the faster adoption of something new. The fact is that in most cases the new world coexists with the old world but the later never dies. No, we never replaced all mainframes with clusters of servers, no we never retired all terminal based interfaces and replaced them by new applications.

Windows Forms was declared legacy and dead by bloggers and new generations of developers. But it never died and hundreds of new Windows Forms applications are written every year. Was WPF ever dominant as a development platform for enterprise systems? I doubt very much and by practical reasons. If my in-house team masters WinForms and if they must maintain a lot of existing WinForms applications, why add a new development platform, why make life harder on my team? After all, WPF is also a Windows only solution and it doesn't run on the web; same deployment problems, more pain with no gain.

When a given platform has a dominant position, it's not easy to kill it. It happens, but it's not common. Sure the dominance may shift, sure we need to adjust, sure we need to rethink but that's what life is all about.

What drives the industry?

Technical achievements enable industry changes but users are the ones that drive the industry. The real questions for a user aren't about the development platform but more like: how useful and easy it is? and how much it costs?. From an entreprise standpoint, you can add other questions like: how easy it is to deploy and maintain? and how reliable it is? but also how secure it is?. The order of the later set of questions is debatable and can change from business to business.

Back to a @rockfordlhotka question:

Why would anyone write a smart client app that is single platform, when they can write an app targeting wasm that runs on all platforms with near-native performance?

:smiley: Because I don't want to run Photoshop or Visual Studio on a Smartphone.

Of course one must contextualize the discussion. There are specialized applications, there are enterprise applications, there are common use applications, you name it. And there is a place for different kinds of applications and for different development platforms.

It's all about a secure architecture

Back to the application security. Whatever is on the hands of your users is never safe. Even a VT100 terminal can be used to do SQL injection. It's all about how your application is build. And that's the point of this thread.

This discussion isn't new at all. The issues are the same that were discussed about Silverlight. On Using CSLA .NET 4 e-books series, @rockfordlhotka discusses the security issues and a couple of solutions: edge applications and the 4-tier solution.

This is discussed on the following e-books:

The 4-tier deployment scenario is discussed with some detail, so you are better off reading the e-books.

Just a small quote from Data Portal Configuration, p. 58:

Another solution is to implement an n-tier architecture using the data portal, and to write code that runs on your web server to validate each incoming client request. This is supported by the data portal through the use of the MobileFactory attribute and the concept of object inspectors.

Adapting what's in the e-books, in the 4 tier architecture you have: 1) database server - secure intranet 2) application server - re-runs the business layer and the Data Access Layer - secure intranet 3) "web/screening" server - serves WASM code and screens browser requests - DMZ exposed to the web 4) browser running CSLA .NET under WASM - internet

Nowadays it's pretty common to access enterprise applications from anywhere. Even if your application is top security and isn't exposed on the internet, you should use the same model, exactly because it's top security (and you can't trust any browser).

Tier 3) above is the extra tier that screens everything that comes from the the WASM client. It speaks to the application server and the later is the only one that speaks to the database server. And yes, use different machines for each server. In the age of virtual servers, there is no reason to pack several tiers in the same virtual server.

Will the UI environment change?

The WASM revolution is just starting and it's too soon to understand what directions it will take. So again I have questions, no, just one question:

rockfordlhotka commented 6 years ago

Your concerns are all very valid @tfreitasleal, I don't dispute that at all. And, fwiw, some of my colleagues at Magenic share your skepticism.

Time will tell if my optimism is deserved, but regardless, having a vibrant client-side .NET runtime has rekindled my enthusiasm for continuing to extend and enhance CSLA! 😄

Regarding your final thought on html vs canvas, that's hard to say. Right now both Blazor and Ooui render using hmtl/css. And that has some important benefits in terms of automatically looking more native on each legacy OS. A button on Windows and Mac look a little different, and using html gets us that for free.

But I can totally see where canvas or OpenGL rendering may be worth an experiment. Unity has become very popular because it provides cross-platform .NET with 3D rendering, so there's no doubt that a niche exists for that sort of thing.

acrigney commented 5 years ago

Rocky we loved CSLA but these days I perfer Domain Driven Design that lets you use a microservice based architecture, with DDD you have an application service layer that you can use on any input end of the business from GUI to web api. Also you can plug and play any backend interfaces by injecting the repository interfaces, just like you could with CSLA.

rockfordlhotka commented 5 years ago

Although Eric Evans and I don't necessarily agree on the specifics of implementation, we're both DDD focused people 😄 Back in the mid-1990's I wrote one chapter in my book on object-oriented domain design, then Eric came out with his book - most of his book is on that topic, with a little implementation, where as mine was mostly implementation with a little design.

Whether you like to roll your own DDD or do DDD leveraging the rules engine and other capabilities of CSLA is totally your choice.