It’s largely accepted that backend logic takes care of dealing with workflow inputs and outputs from the frontend. A user might click their way through a workflow in the UI, but the backend then takes that information, validates it and might do further enrichment or calculation, thus representing the business logic.

So what happens when a customer says “Hey, should this value be counting down and not up?”. If you’re a subject matter expert of both the application and requirements of the application, then you might without question go to the core business logic and change the behaviour. Business logic can be deeply baked and the blast radius of making a change can send reverberations through the rest of the business logic. In other words, one simple perceived change such as a credit counter decrementing to zero instead of counting up to a threshold, can result in a deep set of changes, requiring changes to the test infrastructure, database entries, product schemas and more.

In these moments, it’s worth taking a step back to make a drink or find your own moment of disconnect. If you’ve baked your business logic properly, then your presentation layer might be the best place to make the change. If a counter is incrementing to a threshold, then the chances are you have the threshold already in the UI which was previously fetched by an API call. The simplest of JavaScript function can result in the change required. The backend does the heavy lift activities and making light changes can result in chaos. Thanks to JavaScript, presentational data like this is easily dealt with, keeping the customer happy in the most pain free way.

It might seem glaringly obvious, but more often than not, I start looking at the business logic before realising the simplest solution is quite literally staring me in the face.

Happy Monday!