Handle I/O at the edges of the program.

It’s impossible to build a program that is truly side-effect free. We need I/O, or the program may as well not exist at all. The way I deal with I/O is to keep it decoupled from application logic. That is, you could conceive of your software as streams of inputs which get processed and directed into streams of outputs.

What happens between those inputs and outputs is the application logic.

Understanding the effects of a program is simple when the application logic and I/O are handled separately.

For example, a React application handles user I/O with React components, but the components don’t know anything about what the application does with that I/O. That part of the program is off limits to the components.

One way to handle logging is to use logging middleware. In other words, for each route you need logging for, you might stream connections through the logging middleware, which extracts the relevant information and streams it to the log.

Generally, you want to log in two places: At the beginning of the transaction handling, and at the end of the transaction handling. In other words, you may log information from the initial request being logged, and you may log information about how that request was handled.

The wrong way to do it is to sprinkle the log handling randomly throughout the application logic. The really wrong way to do it is to have random things looking at the stuff that’s logged by other things in the same process, because then it becomes very difficult to know the full effect of logging.