Showing posts from May, 2021

Storing read optimized Tree in a Database

Introduction Have you ever tried putting a Tree (a Parent-Child hierarchical structure) into a Database Table? What seems to be a trivial thing from an implementation point of view can sometimes turn into a real performance nightmare when a large number of requests continuously try to read different portions/branches of the Tree.    Example Use Case Let's say we have an e-commerce solution with a multi-level Product Catalog. One of the most basic requirements would be that if a Customer browses one of the Categories, he should be presented with Products from that Category and from its Subcategories (regardless of their depth in the hierarchy).  If I browse for Phones, I should be presented with all the Phones of all the brands. I can then decide to browse a Sub-category of Phones - for example iPhones or Samsungs. The same use case will apply to any Taxonomy based systems that need to fetch Items related to entire Branches of Trees, not only from single Nodes. It is based on an

Creating Expression evaluation Engine

 Introduction Have you ever been tasked with creating a piece of logic that would parse and evaluate (execute) a String Expression? It seems a very niche requirement in today's world, but it can happen (and it happened to me). I'd like to go over the thought process that led me to implementing a very pragmatic and yet extremely powerful solution.   Requirements  The language would have to be dead simple and easy enough for the business folks to write the Expressions. Ideally it should follow an Excel-like formula syntax, with possibility of more advanced constructs (functions, true 'if's and loops) for the pro users. Choices I've started with listing all possible choices/routes I could follow to achieve my goal. The first that came into my mind were: use a JavaScript parser - for example Nashorn, and write Expressions in JS unfortunately Nashorn is deprecated since Java 11, so it wouldn't make sense to use it JavaScript may be too confusing and too complex for b

Hi there!

  Welcome to my professional blog! Or at least to an attempt of one. I've never written anything serious so please be forgiving :) Lately I've accumulated some experiences and things I'd love to share with other Java developers. I am a Poland based Lead Java Dev and Architect with more than 10 years of experience and I felt it would be nice to try something fresh and to start this blog. You can find me on LinkedIn and GitHub . Let's see where this new adventure will take me. I'm Writing this blog in english because english is a de-facto standard for any Java developer and I hope to gain more audience that way. I will try to make regular contributions to the blog, but I won't write something just for the sake of writing. I'll create stuff when I have something to share and, more importantly, when I have time to do it, so please be patient. Ok, that's that. Again - welcome to Kode Krunch. I hope you'll find something of interest here. P.S. T

Dealing with Spring's reactive WebClient

 Introduction   Being a Java developer usually means that we will interact with Spring Framework in some way. Today I'd like to focus on my personal struggles with making the brand new, reactive WebClient utility work the way I need and want to.   New doesn't always mean simple But wait... shouldn't the brand new API be dead simple to use? WebClient has a builder, so shouldn't it be as simple as this?: WebClient.builder().build();  Well, yes. As long as you are using it to call API/Services that are available on the Internet. This use case will work just fine: @Test public void webClientTest () { WebClient webClient = WebClient.builder().build(); String content = webClient.get() .uri( "" ) .retrieve() .bodyToMono(String.class) .block(); System.out.println(content); }   Unfortunately if you try to use any URL that is not on the In

Using UUIDs as Database Identifiers

 Introduction Why would anyone want to use a UUID as a database identifier? It's ugly. It's (pseudo)random. It takes more space than a regular number. And it can kill your database's performance. All of that is true. So is there any practical use case and can it be implemented to not slow down the database? I think so.  Numeric limitations Traditional numeric identifiers are small and fast, but come with some limitations and trade-offs, especially in the distributed environment: Their sequential nature means that they have to be centrally generated - usually by the Database itself in a form of a Sequence or a form of an auto-generated value. If we fetch values from a Sequence, we need to either use a library (like Hibernate, which I don't like to use at all) to cache and manage generated Sequence values, or we need to implement this logic for ourselves. If we use any kind of Database-side id auto-generation, we need to retrieve the generated value, which also means more

Scope Management in Java Architecture

 Preface This is an english translation of my original article that was published on a polish tech blog of JustJoinIT . No Man's Land Scope has many different meanings in programming, depending on the context. Let's focus on understanding this term in the context of object-oriented languages. In this case, it is one of the basic mechanisms that guarantees encapsulation. We use it every time we create a new class, a method, or a field. Are there any difficulties in managing scope? We deal well with this at the micro-scale – we know when the element is to be private, when it is public, and when it is protected. For fields, methods, and internal classes ( nested class ) this is most often due to our current needs.   Public is a public API. Protected , (possibly package -private – although less common) is useful when you want to use polymorphy and/or get into the implementation of the base class from derived classes. Private means that we do not want to share with anyon