We need to interact from several different Web applications (remote) to a client-side application (.exe in .NET Framework, Windows.Console under our controlled environment). From the web applications, we need to send and receive data and invoke methods to client-side .exe on javascript events like users onclick. SignalR is one of the .Net alternatives to do that, but it adds overhead for what we need. Is it better to add SignalR at both client-side application and remote web application, or use gRPC as it sounds lightest and is multilingual?
SignalR or gRPC are always sending and receiving data on the client-side (from browser to .exe and back to browser). And web application is used for graphical visualization of data to the user. There is no need for local .exe to send or interact with remote web API. Which architecture or framework do you suggest to use in this case?
SignallR is not a strict contract based protocol like Grpc, its a framework for bidirectional client-server communication and by far the most versatile one. where as Grpc is on the other performance optimized point to point communication RPC, clients need to be agree on a schema/contract and is cross platform performance. it comes with pain of handling incompatible types and having to do a lot of modeling work and versioning; If you are not into c++ stack or so and mostly leaning to .net and js as your primary stack: I would say stick with Signalr for now.
If interoperability is something that you are looking into stick with signalR / socketIo etc ,al so they can do pub sub and all magic tricks (absent in GRpc it is not designed for it) if performance and cool thing to try GRpc
Note: MesasgePack over SignalR is faster than or equal to GRpc,
Dragons Ahead : SignalR and GRpc work on two different Http versions so hosting them under a single process is not going to work: Do take a look into Deepstream IO.