Recently I had an opportunity to try out implementing a Proof of Concept for our experiences to have some degree of resilience against transient errors. Our upstream APIs are built on Microsoft Web API, which are pretty reliable, the downstream legacy mainframe systems we rely on however, are extremely unstable. Throwing transient errors at all hours of the day, any day of the week. Some go into maintenance mode every night for up to two hours!

Surely we are not the only one having this plague of legacy systems, someone must have solved it, all I need is to google…

Inheritance is not cheap

In last episode we started off this idea of Rule Engine as a way to separate policy versus operation. We implement the Rule Engine using class and inheritance. Class offers a great deal of encapsulation through which we have this clear sense of boundary that wraps around a single purpose unit. We also enjoy a vast array of language features that comes with it, e.g. private state, behaviours, local functions, virtual methods, etc. Inheritance however, is one of the strongest couplings in object-oriented paradigm, if not careful, it could make our solution over-complicated, or worse, counter productive.

I always reason…

Asynchronous is NOT about multiple background threads, but about making more efficient use of the current thread.

Question Everything

I use async-await in C# all day every day, I rarely pay close attention to the effect on performance, some subtle, some very noticeable, depending on how we use async-await. I never felt the need to question or verify what I learned on Microsoft documentation articles, which I think they did a fantastic job in recent years keeping those documentation up to date and high quality.

Until recently, in a conversation with a friend of mine, who by the way is a brilliant…

Some Say If is Evil

In Robert Martin’s book Clean Code he explains why if statements are considered harmful and suggests when there is an awful amount of if statements in our code, it usually indicates the underlying nature of the problem is polymorphic. I am not going to discuss why if statements considered harmful here, you can read an excellent article by Jetbrains about the problem if statements could bring if you are interested.

I do see the point as in why excessive amount of if statements are a terrible situation to be in. I don’t however, quite agree on that polymorphism underpins the…

Separate policy from mechanism

I personally don’t like to think it as a rule as such, rather I see it just like any other rules or principles, as a perspective from which we think and reason our code structure.

This rule looks a bit abstract, so let me give you an every day experience so you may understand and remember what it means.

Every time I try explaining this to my colleagues I use the example of the sliding doors at our work building so here we go:

At work we have a pair of sliding doors when we tap…

Most articles or answers on the net only explain either the client or backend leg. Hardly any resources as far as I could search for, explains the complete end-to-end flow.

So I created a little experiment of an JS client with a C# web api backend to fully explore the possible approaches for file upload.

Source code demo is available here.

Scope

This article is based on react and ASP.NET web api 2 for PDFs upload. For other backends and file formats, the handling might be syntactically different but the basic idea remains the same.

Setup

First all, we need…

Problem: the try-catch insanity

Again, I admit I have done it, we all have done it. Another copy and paste job from some tutorial that written up in 2 minutes for the purpose of learning NOT fit for production code that is littered with try-catch.

Here is a contrived example:

As you can see, this is not very good for our mental healthy, let’s see if we can do it better.

Option 1: try-catch wrapper

In the case that we don’t want error to bubble up to root Saga, or we are interested in handling in a specific saga…

We’ve all done it — copy from tutorial, stick it in production code and never look back! So this is what we end up:

Okay, let’s apply some good old Unix programming philosophy — Fold intelligence into data structure so your program can be simple and stupid.

Here is how:

We use a data literal called ‘which’, its keys are action type, properties are a lambda function returns a new state.

By doing this, we fold the correlation (knowledge)between action type and its handler into a data structure so our program can be as stupid as which[action.type].

Thanks for reading if you have any suggestions please PR to my Github, and stay tuned for next article about Dictionary Pattern.