Use of Avalonia UI in a desktop based client/server app?

[bcw-mtc]

Hello, My company have tasked me with looking into technologies suitable as part of their update of a current product.
The product is a data acquisition / recording system for a highly configurable hardware set up and numerous UI's to view audio event data and 'tune' settings in the hardware configuration (which can be sampling data from 100+ sources).

Currently the system (20+ years old) is a mix of C/C++/Java/Swing/JavaFX/GTK widgets and a few others.
There are a few PC's connected to the system which runs totally on Linux within a VLAN.
A key requirement is that when underlying services are started they continue even if the client UI's are closed (or worse fall over).
Users are expecting a desktop style user interface/application, not a web application, which would suit the requirement.

I'm quite new to the business and have worked in the past mainly with C#/WinForms/WPF(limited) and Qt/QML.

I came across Avalonia UI when looking at what cross platform frameworks there were that were mature with .NET and Linux that could also support a client/server set up (perhaps using SignalR or maybe gRPC).

The question really is if others are using Avalonia in a similar way as our project is described above, especially with client/server on Linux?
If anymore info is needed let me know, thanks in advance.

[timunie]

Avalonia would be responsible to render the UI. Where the data comes from, is completely up to you.

On our website and at awsome-avalonia we have a set of other applications shown.

We also offer paid support just in case.

Last but not least I'd suggest to wire a quick prototype to evaluate your needs.

Happy coding

[bcw-mtc]

Hi @timunie , thanks for the reply. I'll take a look at your site examples over the coming weekend.

Yes the clients would be developed using Avalonia, I was more interested in how others have exchanged data to the UI in a client/server approach.

I'm not keen to use gRPC for everything that may come from the 'server side' as this would add an extra layer of complexity with proto files/wrappers classes for conversion of objects.

I'll start with a prototype next week.

[bcw-mtc]

Hi @Trigve ,

Thanks for the reply.
It sounds like you're doing something very similar to what I am thinking about.
The 'server' will definitely be a stand alone so that the client(s) can be closed/opened.
Our client(s) are going to be feature heavy, it's going to be very configurable, with many views and the due to the way the hardware side of the projects works means there will be a lot of data to be sent to the client on a frequent basis.

I had considered the use of web sockets, but felt the gRPC route gave more 'compliance' on each end once the proto files were well defined.
I was hoping to implement a lot of the server in C#, and have the long running services written in C++, almost like a client/server, with the server spooling other processes lower down towards the hardware.

Can I ask why not Qt vs Avalonia for the UI?

[Trigve]

Your approach seems reasonable. I can't comment on gRPC as I don't have any experience with it (I remember looking at it at one point but I think it was too "heavy/complicated" for our needs).

Even if there was no problem with Qt per se, its licensing options weren't great (for instance the WASM was licensed under GPL). Also the updates (for LTS) for non-paying customers are provided only in the source form and building it form source isn't fun.

[bcw-mtc]

gRPC can get 'heavy/complicated' if the proto's are not defined and can present issues if the different parts of the system are using different versions. I have some experience using it from C# (the good experience), and some using it with Qt/QML (not so good as there's no nice/easy package manager in C++, at least not like in the .NET/Java eco systems).

I've also been there with building Qt from source at my current place and my previous place.
I have to say, now they're not using qmake and adopted cmake (Qt6 onward), it's made the whole build process of their sources much easier.

The amount of potential library building that could be needed for the upcoming project is a reason I'm looking at C#/Avalonia UI.

I'm finishing up some small in house utils using Avalonia and then plan to start some prototyping.
I'll make some updates here.

Thanks for the inputs.

[Trigve]

Regarding the Qt, still on the 5.x branch and have no plan to upgrade as I'm 95% sure Avalonia client would be our default option now (and using the old Qt only for old versions). Anyway, I think that web option (either as asp.net with wasm or Avalonia wasm) in your case maybe a better fit. For instance our current roadmap is to have avalonia thin client (desktop) and also Avalonia wasm "client" (browser) with the end result using only wasm one (I was also making a prototype with asp.net wasm ONLY client but it just didn't give me the freedom of Avalonia; you're still in the "html" world).

Anyway, good luck with your project ;)

[bcw-mtc]

That's a fair approach , the Qt5 -> Qt6 upgrade isn't too bad, though depends how big the code base is.
I'll look into Avalonia WASM, it wasn't on my radar tbh.
I'm 100% not wanting to be in the web technology space for this project.
Likewise, good luck on yours.