Becoming Agile: How to solve it? Complexity in code - Improving flow control through functional pipelines

Code: https://gitlab.com/danbunea/improving-control-flow-in-code-using-functional-pipelines

Why?

You:

Why?

Me:

Because code is better...

You:

Code is better? How?

Me:

Because is it easier to:

read
extend
debug

You:

Prove it!

Me:

Ok let's look at the following problem:

In practice

We have to write an endpoint which returns an offer by its id:

GET /offer-by-id/:offer-id
Possible results:

- 200 {"offer-id":2, "offer-data":""}
- 400 {"errors":["The id you provided is invalid"}]}
- 404 {"errors":["The id you provided cannot be found"}]}
IMPORTANT: if an id is valid but not found the deposit must be notified!

Solution 1: IFs

The problem could be solved by:

Or in code:

Whenever we have ifs in code, it becomes dificult to read so maybe we could simplify it, making it more like:

step 1
then step 2
then step 3

Or more like

validate
then find offer
then jsonify

Hmm, can we?

Solution 2: Exceptions

We'll use exceptions to break out flow:

The solution above is very present in Java, even if the way the errors are caught might not be this explicit.

Because it's a fairly simple example we could also use the strategy pattern. Basically we use ifs to choose a strategy, then we execute it to give us the result.

Solution 3: strategy pattern

Functional programming gives us sever possibilities using pipes.

What is a pipe?

A pipe makes sure that steps get executed in a certain order and that the result of a step is passed to the next step. Like:

In our case we'd like something like:

validate(requestId)
.then(findOfferById)
.then(jsonify)

Solution 4 Functional either or railway oriented programming

This is a very common solution in typed functional languages such as F# or Haskel, but it's becoming very common in Java as well.

Having a single pipeline is very beautiful but how do we handle errors? By using two parallel pipes. A pipe for the happy path and a path for the errors. Basically all our functions can return either a SuccesfullResponse or a ErrorResponse. This will get passed on to the next function that will process it and return again either a SuccesfullResponse or a ErrorResponse.

In F# we'd have something like:

findOrderById: IResponse -> SuccesfullResponse | ErrorResponse

we might describe it like:

SuccesfullResponse | ErrorResponse aFunction(SuccesfullResponse | ErrorResponse response)

For the happy path we'd have:

And if we get a validation error in the first step we'll have:

And the code, will have a class for Success and a class for Error. Each will inherit an IResponse and will implement two functions receiving a function (lambda) then and fail. In Succes we'll return the result of applying the function on what we have on then and the data we have on fail, and on Error we'll do exactly the opposite.

Imaging you'd replace then with map and fail with orElseGet, doesn't that sound like an optional?

In dynamic languages, there are other options. But first let's describe functional composition.

Functional composition is when you combine 2 (or more) functions into one, then apply it. It's pretty much like pipe but you may do the composition at runtime.

Now we can look at the two options. First is:

Solution 5: pipeline with flag

We'll pass through the pipe an object that contains a flag which tells you whether there were errors before. Basically using a value in your data instead of using the type of the data (has response property instead of type: Successful or Error).

In our case, the flag is whether a response has been set already:

if(state.response) return state;

Solution 6: pipeline + overflow pipeline

The second option is to have a pipeline and an overflow pipeline.

We'll use exceptions once again to bypass the normal pipeline and go to the overflow pipeline.

Unlike the previous two options when an exception happend it will jump straight to the end, bypassing the next steps directly.

The code: https://gitlab.com/danbunea/improving-control-flow-in-code-using-functional-pipelines/tree/stage-1

Readability

In terms of readability it could be a lot easier, to see the code as a pipeline:

step 1
then step 2
then step 3

While also handling the errors:

step 1
then step 2
then step 3
fail on-error

or

safe(
step 1
then step 2
then step 3
)

Extensibility

But what about extensibility?

We now have to modify our endpoint

to check if the offers are still active. If the aren't we need to return an error
to update the number of times the offer has been accessed

GET /offer-by-id/:offer-id

Possible results:

- 200 {"offer-id":2, "offer-data":"", "active":true, "requests":1}
- 400 {"errors":["The id you provided is invalid"}]}
- 400 {"errors":["The offer expired"}]}
- 404 {"errors":["The id you provided cannot be found"}]}

IMPORTANT: if an id is valid but the offer expired the deposit must be notified!

We changed the tests:

Then we change the code and we can look at how
For solution 1:

The way we solved it was to add more ifs inside an existing if thus increasing the cyclomatic complexity of the solution making it even harder to read. And real life code tends to be more complex than this.

For solution 2: