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:
- A process monitor which logs any process starting or stopping using handlers (no polling)
- An API to interact with the Windows Firewall
- A SQL database to store the user's rules
- 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.