I’ve been looking at the possibilities of a simple middleware pipeline script. So far I’ve implemented a version of the Chain of Responsibility pattern. I’ve also been looking at using the same builder to work with promises. Here is what I’ve found.
Fetching some data from an API
So for this example I will define a few interfaces defining the data I am working with.
The context for each middleware function is going to be an object with a request and a response. This means that the middleware can work with either during each step.
Out of curiosity, I’ve been experimenting with what you can do with a simple and generic middleware builder. I’ve been surprised at how powerful it can be with such a small amount of code.
A simple but powerful function
I did a lot of reading, and gained a fair amount of inspiration from researching various implementations of the Chain of Responsibility pattern along with diving into the express.js and redux codebases.
It has essentially boiled down to using reduceRight on an array of functions. The following code has simplified types to make it easier to read but shows the concept.
For guides on how to use version 2 please refer to the fp-ts website
In any codebase there are several paths which can fail. Like I discovered with handling nullable values I want to flow through the code and deal with errors gracefully and in a logical manor. Too many times have I found I’ve written a tangle of if statements and try / catch blocks which make reading a logical set of instructions hard.
For guides on how to use version 2 please refer to the fp-ts website
It’s such a pain dealing with values which could be null or undefined. I like to get
rid of the potential for them as much as possible when designing interfaces but there is
no escaping it sometimes. I hate it even more when you have a set of them, which you need
to check before moving on.
We’re using a lot more functional programming styles and pattens in our codebase. Part of getting better at using these patterns is knowing the tools available. Most of our codebase is TypeScript so we have chosen the fantastic fp-ts library.
I’m still maturing my fp understanding as well as exploring how it all works with fp-ts so I’ll gradually build a series around our journey. I’ll start with three of the most common use-cases our team needs to get their head around: handling nullable values, errors and async functions. I will try and expand on this in time.
Outside of reading over the concepts of functional programming I have never had the opportunity to really dig deep and get to know the theories, patterns and quirks. There has been a lot of talk in the JavaScript community about using functional programming ideas but I’ve decided to put JavaScript to the side for the moment because, whilst it can be used very easily to do functional programming, it isn’t a functional programming language. It’s also easy to fall back into habits when something is very familiar.
Dave Taylor - Software Engineer
