A generic service design
Given the configuration and logging possibilities that we've explored so far, the bare-bones service-as-a-function approach feels less and less viable, unless it's reasonable to expect that only one service will ever need to be written. Taking that basic approach is still possible, to be sure, but if there's ever a need to create another service, it'd be more efficient (and, at least, a somewhat more effective use of developer time) if there were a common starting point for creating any service, no matter what it's expected to do. To that end, then, we'll define a set of abstract base classes (ABC) that define the lowest common denominators of features and functionality that we'll expect from any service or daemon ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access