In functional and reactive applications, side-effects must be present only in drivers. For debugging purposes, traces can be added in the pure code with the do_action operator.

The code in drivers should be as small as possible, limited to the part that is the side-effect. If a driver contains a side-effect and additional logic, then the additional logic should be moved out of the driver into some pure code. This has several benefits:

• The driver is easier to test, since it does fewer things. This is good because testing side-effects is more complex than testing pure functions.
• The resulting logic is now independent of the driver. It means that is can be used with other drivers, implementing similar side-effects but in a different way or with different technologies. When this additional logic is a full protocol, then it becomes a sans-I/O implementation, a protocol implementation independent of the I/O part.

The features provided by a driver should almost always use one sink observable and one source observable. The source observable may be a higher order observable if several sequences must be emitted by the driver.

Moreover, for operational purposes, other source observables can be exposed:

• Logging should be exposed via a dedicated observable. As explained in Chapter 10, Operators in RxPY, this allows us to make logging dynamic, and independent of the items emitted for the feature provided by the driver.
• Following the same logic, a dedicated monitoring observable should be exposed. This observable should also be independent of the two other ones (the response and logging observables).

With these three kinds of observable, an application can be tracked easily in production. The monitoring part allows us to continuously check the health of the system, while the logging part can be used to look for reasons for issues detected while monitoring. If the logging configuration can be enabled dynamically, then issues can even be analyzed without restarting the service.