0

I am looking to build a productivity app using the Windows Firewall API. The idea is that the user can open a desktop or a web app and use the UI to configure and schedule when he wants various websites or programs to be blocked, and a background process does the work. I am looking for advice on the architecture.

I have already written the components of this application, and they are:

  1. A process monitor which logs any process starting or stopping using handlers (no polling)
  2. An API to interact with the Windows Firewall
  3. A SQL database to store the user's rules
  4. A front-end where the user creates rules and sees a log of processes

How can I tie these components together, so everything is done as near to real-time as possible, and I avoid polling and timers by all means? I was considering two applications/threads, the front-end a regular desktop or web app, the back-end a sort of service-style application. They are decoupled unless for the database with which both read from and write to. But how can I prompt the front-end to show processes in real time as soon as the back-end detects them, and how can I prompt the back-end to create a firewall rule as soon as the user creates it in the front-end, some sort of asynchronous synergy of the two?

If the decoupling is a good idea, what would you use for the back-end logic? Windows Service, WCF Service, IIS? If not, what kind of architecture would best support this use case?

Thank you all.

  • Might be that you should have this questions out of yourself before you made the components. If you intend to make a web UI (HTML, CSS, JS), out of it you can get mobile versions with Cordova easy and with Electron you can make desktop UI as well. – DanteTheSmith Nov 13 '17 at 17:12
  • Thanks for the tips, but it is the backend I am more concerned with. – mearlboro Nov 13 '17 at 18:21

0 Answers0