And finally there’s that approach where we deal with some side effects by ignoring them because we decided that they are not important.

Intuitively, this just sounds plain wrong, doesn’t it? We don’t like something about the code, why don’t we pretend it doesn’t exist!

Except that we’re already doing that anyway, just scroll back to the chapter on Inherent impurities to refresh your memory. We are ignoring the fact that every code that runs on an actual physical computer has to obey the basic laws of nature: it takes time to run, space to store the data, emits heat, and so on.

But, apart from these physical constrains, are there any other side effects that we can just declare sufficiently unimportant? The answer to that question is - it depends.

Let’s consider a simple example where we have a function that calculates the sum of two numbers:

function sum(a, b){
    return a + b;
}

This function has no side effects. Now let’s say that we expose its functionality through an HTTP endpoint:

GET /api/sum?a={a}&b={b}

This API operation is still free of any side effects. It does nothing else other than what function sum did.

But, what if it did do something else? Suppose that our web server logs every HTTP request to a file. Would this endpoint still represent a pure function? This question is not one that can get a clear-cut answer, it is rather a judgement call. Some factors we can take into account while trying to figure that out are:

  • Is the log file semantically significant for the work and purpose of the overall system?
  • Is there any process that consumes the stored data in any significant way? It’s your call what significant may mean, but one possible rule of thumb could be that e.g.:
    • if the file is only there for developer’s reference in the case of an emergency - it’s probably not significant
    • if the data is being parsed by a script and periodically uploaded to an external API - it probably is
  • Is there any disturbance to the system that can be caused by the fact that the log file is being written to, e.g.:
    • if the file grows indefinitely leading to slower and slower write times to the point that logging to it slows down the whole application, then yes, you could argue that its impact is significant
    • if the file is being rolled regularly, with old logs being deleted or archived in a way that ensures no performance degradation, then you could claim that there is no significant impact.

Let’s consider two similar examples. The first one is an endpoint that serves a logo image:

GET /img/logo.png

And the second one is an endpoint that serves a single pixel image used to track visits:

GET /img/pixel.png

We are logging all requests to both endpoint. Let’s assume that we are managing the log files efficiently and they are being rolled, archived and there is no risk of performance degradation in both cases.

The key difference is what we do with the two images. We only need the logo in order to display it somewhere on the site and we don’t really need the log entries to its requests. The only possible purpose we are even logging them is to be able to debug any potential issues.

On the other hand, we do care about the pixel tracking image because we have a script that periodically parses the log file, extracts all its requests and uploads the data to a different API that generates traffic analytics.

So, we had two example endpoints with the same kind of side effect, writing to a log file, but in the case of a logo image we decided the side effect wasn’t semantically significant, while in the case of pixel tracking image we decided it was.