PDA

View Full Version : WebApp and SignalR - Future?



starzen
17-Mar-2021, 03:40 PM
Wonder if DAW is looking at SignalR or similar tech at all for possible future versions of WebApp

We have been using Blazor in some projects and Blazor is in a number of ways of similar design to WebApp.
Attempt to keep the developer in their language (DF in WebApp, C# in blazor).

For DF all the DF code is server side. In Blazor you have a choice of server or client side C#

Both allow the use of JavaScript but try to shield you from it

Major difference is the client/server communication. In WebApp its HTTP which is a request/response model and uses HTTP protocol.
It is stateless (the communication only lasts one roundtrip) and is initiated by the client allowing one way communication and response.

Blazor uses SignalR as its form of communication between client and server. SignalR is essentially a websocket connection with a bunch of libraries to handle all the socket and protocol management
It is a persistent connection that allow state and bi-directional communication. Client App actually has a constant connection to the server.

chuckatkinson
19-Mar-2021, 09:30 AM
Interesting !

Focus
19-Mar-2021, 09:49 AM
After the initial oooh would you not end up in a similar place to running DF or any other DB application over a WAN ?

Fine if you keep the number of messages low but if you try an communicate like you are on a LAN it starts to grind to a halt because of the latency ?

starzen
19-Mar-2021, 10:04 AM
no not at all. the communication is very small. you can watch the small packets in the browser. Actually the comm is much lower than other standard webapp techs

comm is actually quite similar to that of webapp. biggest difference is the constant connection which actually makes it faster.

Raphael Theiler
22-Apr-2021, 05:01 AM
Moving code from the server to the browser can decrease the loads drastically. Moving business logic from the server to the browser should only happen in trusted environments.
Decompiling and Debugging the compiled code in the browser is possible (in the same way a windows application can be debugged and decompiled). Hardcoded credentials, encryption secrets, etc. should not be moved to the browser. All the business logic should be verified on the server, especially if the WebApp is available to "external" users (e.g. is accessible over the internet).

I think WebSockets would actually be useful for us. Being able to "push" messages/data from the server to the client would open a lot of possibilities. (Automatically updating views/grids/logs, showing notifications if something happens, displaying a progress bar)
Another approach would be the HTTP/2 and SPDY features, which would allow a "server push" as well. Compared to WebSockets the HTTP/2-stuff feels pretty new and a bit complicated.

It would require a few changes in the Dataflex/IIS-interface to allow long lasting connections between the browser and the IIS without hogging the webapp processes from the pool. It would also require a method to send "messages" to those connections.

starzen
22-Apr-2021, 05:26 AM
You may be thinking about Blazor WebAssembly which is not even released yet. It will have its place especially for disconnected apps by allowing to run client side code but it doesnt mean all your business logic runs on the client. Only what you choose to put on the client.

But Server side Blazor runs all code on the server (except for some javascript of course to make it all work) so none of the things you mentioned would be on the client.
in addition there should be no hard coded credentials or similar in your code either way. We store all our credentials in secure vaults on AWS for example. only accessible to authorized users from the application.

With Blazor actually a lot more of your webapps code is protected on the server as server side blazor uses a lot less client side code

Biggest issue with using a technology like SignalR with DF WebApp would be the design of the server side.

DF WebApp processes disconnect from the client after a call was made so there is no more active process that could later decide to call back to a client.
if you change the server side to keep a process connected like Blazor does DF WebApp would be to server hungry (each active user would need an active process)
you could of course keep the server processes but make a SignalR router type thing but then you would have the problem of having to synchronize the server side all the time

We have been using Blazor now for a while and i really like the way it works.