For about a year, all Java code I’m writing heavily uses functional programming approaches. This provides a lot of benefits, but description of this new style is a topic for a separate long article (or even series of articles).
Now I’d like to focus on one curious observation: sometimes OO provides a more convenient way to use even purely FP concepts like monads.
Monads is a very convenient design pattern, often used to represent special states of values — potentially missing values (
Option) or results of computations which may fail (
Usually such a monad can be implemented using…
In previous articles (here and here) we’ve looked at backend applications from non-traditional angle. Such a look enabled us to see processing patterns which are inherent to backend applications and don’t depend on used tools, languages and frameworks. This article focuses on yet another ubiquitous processing pattern which present in virtually any backend application.
It should not be a surprise that almost every backend entry point requires some data to generate response. It might be as simple as constant string or as complex as invocation of several external services and retrieving different pieces of data from the database. Even if…
In previous article we’ve looked at backend application communication with external world from the point of view of I/O. Now I propose to look into another processing pattern which is explicitly or implicitly present in every backend application.
Let’s start again with the very simple HTTP endpoint. This time we’ll be looking at the processes which happen before our code is even invoked, in the depth of the framework or library we’re using. For convenience lets call this part of the framework or library a transport layer.
Let’s keep aside for the moment what happens when the client connects to…
We’re using a lot of different languages, platforms and frameworks to write backend applications. They dictate/promote/enable very different styles, approaches, architectures of the backend application. We are rarely looking under the hood of these tools, especially down to the level where happens actual interaction between backend application and external environment, most frequently OS API layer. But if we do, we may discover that all that languages/platforms/frameworks are just an isolation layer which hides the true internal structure of the backend application.
Let's take a look under the hood. For this purpose we’ll try to analyze how a very simple HTTP…
Practical Introduction to Monads for Java Developers
Let me start with the disclaimer. The explanation below is no way pretends to be precise or absolutely accurate from the point of view of Functional Programming. Instead, I’m focusing on clarity and simplicity of the explanation to let as many Java developers get into this beautiful world.
When I started digging into Functional Programming a few years ago, I’ve quickly discovered that there are an overwhelming amount of information, but very little of it is understandable for average Java developer with almost exclusively imperative background. These days situation is slowly changing. There…
The Builder pattern is extremely popular in Java applications. Unfortunately it’s often misunderstood and incorrectly implemented and used which results to run time errors.
So, what to do in cases when object must be built completely and there are no safe defaults for fields (i.e. Builder pattern is not applicable)? In such cases would be very convenient to use Fluent Interface pattern which allows to avoid errors caused by missing field(s). Unfortunately proper implementation of Fluent Interface usually is too verbose to be practical so developers use plain Builder and try to rely on careful testing to avoid runtime errors.
Not so many backend (and application in general) developers watching development of Linux kernel. But those who do, definitely noticed appearance and rapid development of io_uring. For those who is not aware what it is I’ll provide brief introduction below. But main topic of this post not the io_uring itself. Instead I want to show you that we are watching the beginning of the real revolution in backend development.
As I’ve explained in the article dedicated to Data Dependency Graph, each backend application at very high level has only three parts — set of inputs, set of outputs and set…
Last few years there is a wave of hype which crosses IT-dedicated media back and forth, growing bigger and bigger. And this wave is about microservices.
Countless articles, blog posts, videos and slideshows dedicated to microservices, how to design them or how to apply them to existing applications.
There are also some rare publications with more sober look at microservices. This article is my attempt to amplify this voice of wisdom.
First of all: I have nothing against microservices. Moreover, I’m pretty sure that in some cases they are completely reasonable solution. I’m just as well aware that majority of…
Every application somehow deals with data. After all, this is why applications are necessary in the first place.
In case of backend applications, there are well known stable patterns in how code deals with data. Everyone knows about CRUD, for example.
But there is another set of patterns which present in wast a majority of backend applications. Unlike traditional software design patterns, which more revolve around code and much less about data, these patterns are purely data-driven. To be precise, they are defined by dependencies between different parts of data circulating inside the application.
Very high level look at backend…
Yes, yes, I know, microservices are all the hype. But their claims correspond to reality? Let’s do a some fact checking.
Let’s pick a random article with shameless microservice propaganda. It’s not hard, given how many of them already exists and how many new ones published every day. For example, this one will serve the purpose very well. It contains the following statements:
What do Microservices Offer?
As services become smaller, the benefits are realized in multiple aspects
The foremost advantage of it is improved maintainability. Each service is relatively small and so is easier to understand, modify, and test.
Writing code for 30+ years and still enjoy it…