Service Stack a quick IPC solution
Recently I was working on a application that required the separation of the User Interface
from the background processing module whereby the User Interface would only receive progress messages from the background process, thus making the communication paradigm well suited to something akin to anonymous pipes, where the service would need to be running on top of some ’self hosted’ infrastructure / plumbing.
The service (term I will use lightly in this case) would be crafted with top shelf, running as a windows service with the expectation of being in operation for long periods where the User Interface would be shutdown. In summary, both applications had no need to be running concurrently and shared their domain data from a light weight data store. On the occasion that both processes were running, the service send “work in progress” messages to the UI so that users can monitor project activity.
Now, when it came to implementation details I had a plethora of choices, some of which included .NET Pipes, WCF or even using something like a self hosted NancyFx endpoint but in the end I opted for Service Stack and I have to say it couldn’t have been simpler or more enjoyable. Sure this was one very simple problem and the solution needed to be just as simple but I have a strong suspicion that Service Stack can ante up to much bigger problems and seems very nicely suited to synchronous reads (web services) from a data store over http. Of course I could have even gone down the NServiceBus path however in this case it would have been overkill. Well done to the guys at ServiceStack your framework stayed right out of my way as I developed this application, it was an experience low on “friction”, unencumbered by annoying item templates or ceremony.
Yes I know WCF is getting better at this but still not enough to encourage me to use it
.
How long will we have to wait for the touted write once render everywhere revolution?



