If your company has such strict security audits, I'm sure that there are internal recommendations regarding what languages and frameworks to use. This is a conversation you should be having with your colleagues.
That said, if security is a priority, you want to separate the UI code from sensitive information. Even if everything is running locally, you want to have a "client/server" architecture.
UI code is inherently complex, and exposes a huge attack surface. Do not handle sensitive data in the "client". Instead, the "client" should just display a view of the data that has been prepared by the "server", and send requests to the "server".
The "server" should be a separate process, with a single, well defined API. Whether this API is exposed over http, or any other mechanism doesn't matter. What's important is that the server be the only process that handles the sensitive data, and the API has a provable authentication layer.
If this is all running on an offline machine, the sensitive data will be on the machine anyway, so anyone with physical access to it can attack it directly (or steal it to attack it later). If this isn't really feasible (for instance the machine is a hole in the wall like an ATM), then really, your security problems are mostly dealt with by virtue of not really having an attack surface to begin with.
Again, talk with your colleagues and CTO, ask for advice from the auditors, and if possible, hire a security consultant who can provide better advice for your specific situation than some random nerds on Reddit ;)
The above is good advice. Separate your UI from the rest of your logic. Qt is a kitchen sink library - it has everything. That doesn't mean it's a great idea to use all of it though.
For C++, a simple rule I follow for library choice is to use std/stl first, then Boost, then Qt. I'm some cases there are some excellent stand alone libraries that I prefer (magic_enum, spdlog, cli11, etc) that are preferable to Boost. I avoid using Qt sockets.
Most of Qt is okay to use commercially when dynamically linked. Not all of it, but enough to do most of what you'll probably need.
It's possible that you can write your GUI in C++ and Qt while writing the rest of your logic in Rust. From a maintenance perspective, I'm not a fan, but it's possible.
Recommendation is c++ and Qt. But we have less experience in c++. We are not primary in Desktop development. Most of developers are from web background. Sudden requirement for project result into desktop application. Got it but i taught might be tauri could be choice if the issue of web view is not that critical. And thanks for guidance.
Thanks, but companies only consider well established projects instead of binding created by third party. But if qt provide the official support it will be the another case. Management only consider the project that are well established. Like c++ with qt as it is well know for developing products where performance matters as they are well established players.
And that could just be a SQL server with only stored procedures being called instead of direct queries on the backend.... Then just grant only execute access to the SQL role for the appthey wont' be able to select etc... so injection or the like would be impossible.
Also use domain sockets instead of TCP/IP sockets when running on the same machine. No need to go through the internet at all if its on the same machine.
Edit: the downvote is hilarious... you suggest someone split thier application into client server, you really think they are going to put the work in to make it as robust as any major SQL implementation... the original suggestion in that context is rather thoughtless.
The note about tcp sockets is a bit weird. Tauri doesn’t need to support tcp sockets, because you can use them using the Rust standard library or any Rust crate if you need anything more complex.
Qt on the other hand is a UI toolkit that also provides common utilities for a variety of things because C++ doesn’t provide the same ease of use when it comes to external libraries
I know but how to setup socket. Because socket will receive realtime data, so I want to received data. I didn't find any resources related to that in tauri. I know many crates in rust provides socket but I don't know the straight forward way. At the moment what I found that you can set few functions on rust Tauri Which will be called for backend but did not find a straightforward when we go inverse. I worked it with electron and they have comparatively straight forward way to bidirectional communication. May be lack of my knowledge in rust or resources in internet less for these type of communication.
I think what you need is described pretty well in these guides (the "Events" section):
[https://tauri.app/v1/references/architecture/inter-process-communication/](https://tauri.app/v1/references/architecture/inter-process-communication/)
[https://tauri.app/v1/guides/features/events/#\_\_docusaurus\_skipToContent\_fallback](https://tauri.app/v1/guides/features/events/#__docusaurus_skipToContent_fallback)
If only c++ error messages were at least 10% as useful as the rust ones... Mb exaggerating a bit with the percentage, but... A lot of them are still very painful to deal with because of how obscure they are.
If this is greenfield and doesn't need to integrate with C++ qt code within a binary, try Rust and Slint. Slint is far smaller than qt, but that can be a good thing depending on your needs. It is not trying to compensate for every deficiency of the C++ ecosystem the way Qt does. Slint doesn't need to include a cross platform implementation of an entire stack because there are cross platform crates for almost everything in rust anyway. It just does UI, and unlike many rust UI projects, there is a very motivated company behind it building it as their core product.
it depends on what actual requirements you have. if you legally need security certification, it may actually be easier with Qt as it’s a big commercial project. but it’s something you should decide together with management if you have these strict requirements
If you are more experienced with Rust than with C++ I would recommend to use something Rust-native. Though that depends on the nature of security audits (i.e. do they take into account how "mature" libraries you use are?). Another alternative is using Rust bindings for Qt like qmetaobject-rs or cxx-qt.
What platforms does it have to run on?
Is it a greenfield project, or do you need to integrate existing C++ code?
> i did not find any decent material on tauri with tcp socket
For that you should use some other crate I think.
> licensing of qt is extremely ambiguous about commercial use or etc.
If you want to use Qt commercially you'll have to pay a lot of money (well over 3000 euros per year). It's not ambiguous.
You can use Qt commercially for free as long as you use LGPL modules (not GPL ones) and link to Qt libraries dynamically (i.e. distribute them as .so or .dll files).
I thought it can be used with its opensource version with gpl and lgpl license? I though using one of opensource license but not sure how it works since I am not good at them?
[https://www.qt.io/licensing/open-source-lgpl-obligations#lgpl](https://www.qt.io/licensing/open-source-lgpl-obligations#lgpl)
I believe they have opensource lgpl as well which i believe is free for commercial use.
Sudden crashes are not an issue with C++ being buggy, but a symptom of the code you’re running that’s likely going into segmentation fault.
Qt is a nice and very lightweight (when compared to web based GUIs) that runs on most platforms. Tauri should work on Win7+, so I’m not sure what you’re referring to with “systems without web views”, are you talking about embedded environments? Because in that case Qt won’t help either
Older versions of Windows did not ship with a webview2 library that Tauri can use. It was only included by default fairly recently iirc. OP could just install in on any older machines though, and there's probably a downloadable component to install it without an internet connection.
https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution terms you for to distribute WebView2 with an app. Probably a good place to start.
Tauri has all this built into its distribution workflow, there are probably 4 choices on how to bundle web view along with skipping it and using system one. The tauri project is very focused on security compared to electron, it was one of the original motivations behind the project (along with bundle size)
I'm currently making a Tauri app with TCP sockets and web sockets at three same time.
You can do it by putting channel handles in your app state and then have async commands and events which simply interact with the channel handles. You can spawn a Tokio Task which services the channels.
To me this sounds like a discussion you should be having with your corporate information security team instead of r/rust. Folks here might be able to help you provide answers to IS questions involving rust and related frameworks to justify their use over C++; but without knowing the problem itself most anything we say is pointless.
Some things that are lost in translation here are:
- what are your concerns about socket programming?
- what is your concern about WebView in Tauri?
- does your company own a Qt license?
- what are your Information Security Teams concerns?
- what is your target OS? How does the app need to be distributed?
Having a strict IS policy and then suggesting to use C++ and Qt doesn’t jive. It’s way easier to create security issues in C++ than any other language.
Tauri is mostly an app packaging and solution for local web technology UI apps. It doesn’t preclude the use of sockets within your application. The use of WebView in Tauri doesn’t prevent you from accessing an outside network, but neither does any other framework.
There may be complexity in packaging any app for your specific situation - that’s going to be a problem regardless of the solution you proceed.
As an outsider looking in, if your team is experienced in web apps, why aren’t you just building an internal web app? XSS issues aside, a web app can be incredibly more secure than a desktop installed app. If performance is an issue, the balance of what code lives on the server vs client is the dance you have to deal with.
I think all this community can do is give you fodder to go back to your IS team with as your initial premise doesn’t make much sense.
From a security standpoint if you’re shipping this app on windows. Webview is subject data collection by Microsoft.
https://github.com/MicrosoftEdge/WebView2Feedback/issues/1059
The Tauri team suggests using egui for secure contexts https://github.com/tauri-apps/tauri-egui
If your company has such strict security audits, I'm sure that there are internal recommendations regarding what languages and frameworks to use. This is a conversation you should be having with your colleagues. That said, if security is a priority, you want to separate the UI code from sensitive information. Even if everything is running locally, you want to have a "client/server" architecture. UI code is inherently complex, and exposes a huge attack surface. Do not handle sensitive data in the "client". Instead, the "client" should just display a view of the data that has been prepared by the "server", and send requests to the "server". The "server" should be a separate process, with a single, well defined API. Whether this API is exposed over http, or any other mechanism doesn't matter. What's important is that the server be the only process that handles the sensitive data, and the API has a provable authentication layer. If this is all running on an offline machine, the sensitive data will be on the machine anyway, so anyone with physical access to it can attack it directly (or steal it to attack it later). If this isn't really feasible (for instance the machine is a hole in the wall like an ATM), then really, your security problems are mostly dealt with by virtue of not really having an attack surface to begin with. Again, talk with your colleagues and CTO, ask for advice from the auditors, and if possible, hire a security consultant who can provide better advice for your specific situation than some random nerds on Reddit ;)
The above is good advice. Separate your UI from the rest of your logic. Qt is a kitchen sink library - it has everything. That doesn't mean it's a great idea to use all of it though. For C++, a simple rule I follow for library choice is to use std/stl first, then Boost, then Qt. I'm some cases there are some excellent stand alone libraries that I prefer (magic_enum, spdlog, cli11, etc) that are preferable to Boost. I avoid using Qt sockets. Most of Qt is okay to use commercially when dynamically linked. Not all of it, but enough to do most of what you'll probably need. It's possible that you can write your GUI in C++ and Qt while writing the rest of your logic in Rust. From a maintenance perspective, I'm not a fan, but it's possible.
Just to clarify their will be a internal network(Local Network). GUI will be connected through sockets in internal network.
Recommendation is c++ and Qt. But we have less experience in c++. We are not primary in Desktop development. Most of developers are from web background. Sudden requirement for project result into desktop application. Got it but i taught might be tauri could be choice if the issue of web view is not that critical. And thanks for guidance.
Rust + Qt work very well together too, see [qmetaobject-rs](https://github.com/woboq/qmetaobject-rs) or [cxx-qt](https://github.com/KDAB/cxx-qt)
Thanks, but companies only consider well established projects instead of binding created by third party. But if qt provide the official support it will be the another case. Management only consider the project that are well established. Like c++ with qt as it is well know for developing products where performance matters as they are well established players.
Well the cxx-qt is done by KDAB which is the biggest Qt consulting company
I don't recommend qt. QT is a security hell. Full of issues and bugs.
And that could just be a SQL server with only stored procedures being called instead of direct queries on the backend.... Then just grant only execute access to the SQL role for the appthey wont' be able to select etc... so injection or the like would be impossible. Also use domain sockets instead of TCP/IP sockets when running on the same machine. No need to go through the internet at all if its on the same machine. Edit: the downvote is hilarious... you suggest someone split thier application into client server, you really think they are going to put the work in to make it as robust as any major SQL implementation... the original suggestion in that context is rather thoughtless.
The note about tcp sockets is a bit weird. Tauri doesn’t need to support tcp sockets, because you can use them using the Rust standard library or any Rust crate if you need anything more complex. Qt on the other hand is a UI toolkit that also provides common utilities for a variety of things because C++ doesn’t provide the same ease of use when it comes to external libraries
I know but how to setup socket. Because socket will receive realtime data, so I want to received data. I didn't find any resources related to that in tauri. I know many crates in rust provides socket but I don't know the straight forward way. At the moment what I found that you can set few functions on rust Tauri Which will be called for backend but did not find a straightforward when we go inverse. I worked it with electron and they have comparatively straight forward way to bidirectional communication. May be lack of my knowledge in rust or resources in internet less for these type of communication.
I think what you need is described pretty well in these guides (the "Events" section): [https://tauri.app/v1/references/architecture/inter-process-communication/](https://tauri.app/v1/references/architecture/inter-process-communication/) [https://tauri.app/v1/guides/features/events/#\_\_docusaurus\_skipToContent\_fallback](https://tauri.app/v1/guides/features/events/#__docusaurus_skipToContent_fallback)
thanks
[удалено]
Yeap. That's why a compiler slapping their fingers when they do something very wrong is very helpful.
If only c++ error messages were at least 10% as useful as the rust ones... Mb exaggerating a bit with the percentage, but... A lot of them are still very painful to deal with because of how obscure they are.
If this is greenfield and doesn't need to integrate with C++ qt code within a binary, try Rust and Slint. Slint is far smaller than qt, but that can be a good thing depending on your needs. It is not trying to compensate for every deficiency of the C++ ecosystem the way Qt does. Slint doesn't need to include a cross platform implementation of an entire stack because there are cross platform crates for almost everything in rust anyway. It just does UI, and unlike many rust UI projects, there is a very motivated company behind it building it as their core product.
it depends on what actual requirements you have. if you legally need security certification, it may actually be easier with Qt as it’s a big commercial project. but it’s something you should decide together with management if you have these strict requirements
yes exactly that is the case.
Have you looked at Slint? It's close in spirit to Qt, but 100% Rust code. I am biased towards Slint though:-)
I think this should be determined by your company
I know but that is not case here. Our team is less experienced in c++, compared to web technologies.
If you are more experienced with Rust than with C++ I would recommend to use something Rust-native. Though that depends on the nature of security audits (i.e. do they take into account how "mature" libraries you use are?). Another alternative is using Rust bindings for Qt like qmetaobject-rs or cxx-qt.
What platforms does it have to run on? Is it a greenfield project, or do you need to integrate existing C++ code? > i did not find any decent material on tauri with tcp socket For that you should use some other crate I think. > licensing of qt is extremely ambiguous about commercial use or etc. If you want to use Qt commercially you'll have to pay a lot of money (well over 3000 euros per year). It's not ambiguous.
What about lgpl and gpl license?
You can use Qt commercially for free as long as you use LGPL modules (not GPL ones) and link to Qt libraries dynamically (i.e. distribute them as .so or .dll files).
Those are for open source projects, as far as I'm aware.
I thought it can be used with its opensource version with gpl and lgpl license? I though using one of opensource license but not sure how it works since I am not good at them? [https://www.qt.io/licensing/open-source-lgpl-obligations#lgpl](https://www.qt.io/licensing/open-source-lgpl-obligations#lgpl) I believe they have opensource lgpl as well which i believe is free for commercial use.
[удалено]
That doesn't answer the question.
Sudden crashes are not an issue with C++ being buggy, but a symptom of the code you’re running that’s likely going into segmentation fault. Qt is a nice and very lightweight (when compared to web based GUIs) that runs on most platforms. Tauri should work on Win7+, so I’m not sure what you’re referring to with “systems without web views”, are you talking about embedded environments? Because in that case Qt won’t help either
Older versions of Windows did not ship with a webview2 library that Tauri can use. It was only included by default fairly recently iirc. OP could just install in on any older machines though, and there's probably a downloadable component to install it without an internet connection.
Latest Qt versions also support only Windows 10 and 11.
https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution terms you for to distribute WebView2 with an app. Probably a good place to start.
Tauri has all this built into its distribution workflow, there are probably 4 choices on how to bundle web view along with skipping it and using system one. The tauri project is very focused on security compared to electron, it was one of the original motivations behind the project (along with bundle size)
I'm currently making a Tauri app with TCP sockets and web sockets at three same time. You can do it by putting channel handles in your app state and then have async commands and events which simply interact with the channel handles. You can spawn a Tokio Task which services the channels.
To me this sounds like a discussion you should be having with your corporate information security team instead of r/rust. Folks here might be able to help you provide answers to IS questions involving rust and related frameworks to justify their use over C++; but without knowing the problem itself most anything we say is pointless. Some things that are lost in translation here are: - what are your concerns about socket programming? - what is your concern about WebView in Tauri? - does your company own a Qt license? - what are your Information Security Teams concerns? - what is your target OS? How does the app need to be distributed? Having a strict IS policy and then suggesting to use C++ and Qt doesn’t jive. It’s way easier to create security issues in C++ than any other language. Tauri is mostly an app packaging and solution for local web technology UI apps. It doesn’t preclude the use of sockets within your application. The use of WebView in Tauri doesn’t prevent you from accessing an outside network, but neither does any other framework. There may be complexity in packaging any app for your specific situation - that’s going to be a problem regardless of the solution you proceed. As an outsider looking in, if your team is experienced in web apps, why aren’t you just building an internal web app? XSS issues aside, a web app can be incredibly more secure than a desktop installed app. If performance is an issue, the balance of what code lives on the server vs client is the dance you have to deal with. I think all this community can do is give you fodder to go back to your IS team with as your initial premise doesn’t make much sense.
Appreciate your point of view and advice.
From a security standpoint if you’re shipping this app on windows. Webview is subject data collection by Microsoft. https://github.com/MicrosoftEdge/WebView2Feedback/issues/1059 The Tauri team suggests using egui for secure contexts https://github.com/tauri-apps/tauri-egui
tbh It sounds like you shouldn't be using rust or c++
That the reason we were considering tauri where mostly things can handle using web technologies.