As every Java developer know, variables with non-primitive types are initialized to
null. This is the Java (and not just Java) way to say that "value is missing" or "variable has no value assigned yet".
There are often situations when we may return value, but sometimes we need to notify the caller that there is an error. The idiomatic Java way to do this is to throw an exception.
What described above situations have in common? They cover different cases and use different ways to represent/handle them.
In fact, both of them deal with special states of the variables. …
This article is not attempt to make reader choose or not choose microservices. Intead I’m trying to fill some gaps in the microservices-related information so reader may make informed decision.
It's hard or even impossible to ignore microservices hype. Every day one can see more and more new articles describing how good and advanced microservices, that everyone who does not do microservices should start doing them immediately, which patterns to use and which avoid, and so on and so forth.
This flood of shameless microservices propaganda leaves very little room for objective analysis of advantages and disadvantages of "microservices architecture".
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.
(image courtesy of Jonathan Farber)
The microservices are all the hype today. Everyone does them, everyone wants them, everyone looks for devs who know them. Any critique or, at least, attempt to look at them with sober view immediately attacked and blamed in all possible sins.
But there is a very inconvenient truth behind the hype — microservices is a terrible solution from a technical point of view.
This is hard to accept at first, but let’s look into the roots: any system built with microservices is a distributed system. …
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.