DEV Community: Mircea Sirghi

BFF

Mircea Sirghi — Sat, 08 Feb 2025 16:30:56 +0000

Intro

Heard recently about BFF. I have used it before, however, I like when people, become enthusiastic about a technology. It is so interesting almost funny, it also drives the incentive to discover it more.

I have refreshed myself on the topic, read a couple of articles and spotted a pattern. This article is about the dissonance I am feeling, after I used BFF, with what is being written about it, and what can be truly beneficial about it, in my opinion.

A little bit about the name

"Backend For Frontend" - if you call it this way you follow the usage coined by Phil Calçado PhilCalcado.com - BEFFE, however, it was shrunk to BFF by Nick Fisher. I think Phil Calçado is the first who described this pattern, though.

"Backend For Frontends" - if you call it this way you follow the usage promoted by Sam Newman SamNewman.io who adds some additional flavors to it.

Description

As PhilCalcado.com describes, it is a pattern that facilitates communication between FE with only one BE. For example segregated between Web and Mobile, you have one Mobile FE communicating with Mobile BFF, similarly for Web.

However, how it is used in reality or at least how I have seen it used, is that each domain be that, invoice, order, bill, contracts, etc. has it's own BFF. This is closer to how Sam Newman describes it SamNewman.io, however, at an even more granular level.

So it may solve the problem for the FE, as FE doesn't need to call various services, however, it just shifted towards BE.

Now, what it means to add a single field in a form? I will show two cases, the preferable one, and the worst case one.

Preferable flow to add one field

There are 3 PRs needed to add a single field. Just for visualizing it, each PR consists of:

Open PR
Receive approvals
Merge it
Deploy it on DEV
...

Worst case flow to add one field

Phil Calçado's PhilCalcado.com diagrams show they were making similar calls from BFFs, ending up defining a new layer to handle them, the so called "Application Service". I think they came to this solution because they didn't allow communication between Services in the first place, so they ended up building an additional layer. I would rather allow services call each other. Sam Newman also proposes the architecture where Services can call each other as an alternative.

Sam Newman proposes BFF for third party integrations also. I think the reason is that API can evolve internally quicker, and a BFF layer can help keeping a backward compatible communication.

How it is being promoted

BFFs can call any service, if required. I guess it also means that if the delivery is streamlined per domain you are still constrained to keep the backward compatibility at the service level because other BFFs, not from your domain, may call your service. Isn't it somehow evident or I am missing something ? I see this as an overhead, these systems hardly evolve, or evolve slowly(through API versioning), consequence to interdependencies.

However if you change the approach and allow services to communicate at the same time ban BFFs to call other services except from it's own domain then the meaning of BFF is diminished. You can directly send the response in the format FE expects without an intermediate layer to agregate info. ¯\_(ツ)_/¯

Maybe I am wrong, but I have started to think that the incentive for this patterns is driven by the rule of disallowing Services to communicate between them and, most probably, to avoid single point of failure provided by using a gateway layered architecture.

Conclusion

Putting everything together I realized the dissonance between how I have seen it used with how it is proposed to be used by authors, and how articles on this subject propose it. It took me a while to dissipate feelings about it and start objectively analyzing.

The way Phil Calçado describes it, makes a lot of sense to me, as they evolved their approach to a BFF layered one. And they coined it over an app with Mobile and Web interfaces. It dissonates with how I have seen this architecture applied per domain, where each team hold ownership over their BFF, and due to the lack of service gateway/discovery we had to maintain hard-coded urls per environment. I also found it cumbersome to implement changes on Service layer still having to cascade them to BFF layer. The amount of DTOs is big and redundant. Can be solved using libraries, but we weren't.

It is amazing how SoundCloud allowed projects to evolve. It was a well-founded process, every step was a particular solution to an emerging problem. This leads to concluding that an application evolving to BFF becomes much more suitable than it being applied from the start, as it just disables the teams to tailor their approach to client needs. Basically they loose adaptability. Isn't it an important factor?

Adding a new field means at least 3-4 PRs. There is a bunch of logs to consider to find a defect root cause. Each request consists of FE->BFF->Service->BFF->FE => 4 request, 8 message marshaling/unmarshaling, 12 chances something is not working(DB excluded). Code duplication is a concern. An additional layer is an overhead to me.

As opposed to gateway layered architecture BFF avoids single point of failure. Which has its benefits.

Overall it is an interesting approach, and while writing this article I became less reticent to using it in a gradually evolving manner as Authors describe it.

References

SamNewman.io

PhilCalcado.com

Learn.microsoft.com

Javascript "multithreading"

Mircea Sirghi — Sun, 02 Feb 2025 00:19:11 +0000

Intro

Yes, limited, however, it can run code and render content in parallel. Contrary to widespread opinion that it can't. You see, Java is also single threaded if Threads are not used, isn't it?

I think that devs who have been using single-threaded JS for the whole career become deeply offended when somebody inaccurately mentions multithreading.

I have browsed a little bit on this subject and everybody who mentions JS is single-threaded omits to specify their source - always.

I have tried to find this proof in Ecma-international standard, with no success. Maybe I am looking in the wrong place? However, here is the formulation from Mozilla developers:

And mozilla source is recomended from Javascript-manual. So there are sources that discuss Threads in JS. And almost all sources mention Web Workers. This is what this article is about.

Web Workers

It took me a while to understand how Web Workers work. How they interact with main thread, and how main thread interacts with Web Workers. I need to confess, I am not a JS developer, however I create JS scripts occasionally.

So what is a web worker? It is just a Worker instance in JS that loads a script and runs it. Additionally it has an API that allows communication between main and worker threads.

To demonstrate how they work, I imagined the following scenario, I want to display content on a web page that is generated from different Workers in parallel, so that it is clear from the content which Worker generated it.

Basically I want to have a button "Start worker" and whenever I press it a new Worker is created and added to the Pool(map) of existing workers. When I press "Stop workers" all workers are closed and content is cleared.

Each time "Start worker" button is pressed a new Worker is created by loading worker.js and receiving a startup message composed of ["Worker name", "Start"].

All workers are closed by sending termination command to each worker ["Worker name", "Stop"], "Worker name" is not yet used while closing, however it may be useful to stop a particular worker, in the future.

The problem

Current browsers have a security CORS policy and don't allow for a script to be loaded from local machine, only from a Web Server. But I want this application to work without additional setup. Thus the solution I found was to load the worker.js file in an input field and from there to use it to instantiate Workers.

Demonstration

Open concurent/index.html in browser, load concurent/worker.js, press "Start worker" button a couple of times and observe how content is being generated

Conclusion

Even if Worker threads run in parallel, the listener is in main thread, which makes responses become queued. This invalidates the parallelism as the content is sequentially added. JS may have the capability for multithreading but limited to a concurent way when messages are passed from Workers to main thread. It is not possible to generate content in parallel. However, there is still a way to get parallelism...

Parallel Javascript

The only way to render content in parallel is through OffscreenCanvas. Pass the canvas handling to the worker thread and it will work in parallel with the main thread. A canvas can be attached to a worker only once. It is not possible to send the same canvas to multiple workers, though.

I have also learned a better way to load worker.js from here: Web.dev

Open parallel/index.html in browser, press "Start worker"/"Stop workers", observe how content is rendered in parallel.

Final conclusion

As I see it, it is not a limitation of JS, it is just how browsers currently render the DOM tree, it is not thread safe. Imagine some content being rendered at the same time with a worker changing or removing it. The obvious solution, or the easiest, so to speak, would be to make it thread safe by forcing synchronous acces. But this is how it currently works with a single thread. Even better, main thread never competes for getting access to the DOM tree. Here is a good resource to learn about it Developer.mozilla.org.

Repo

Code is available in Github

References

Developer.mozilla.org

Scala Full-Stack templates

Mircea Sirghi — Tue, 14 Jan 2025 13:00:21 +0000

Intro

When I started to build Scala full stack projects I observed there are various frameworks and information is scattered all over the internet which is disconcerting. Especially annoying is that I could not find a book that would tackle this aspect sufficiently.

There are lots of templates available however who can tell which is the difference between them in a concise manner ?

In this article I am gathering main full stack examples I can find.

Scala full-stack with

Scala3
Htt4s
ScalaJs
Javascript

For this template I used the repo outline proposed in this tutorial IdiomaticSoft as it is close to what I am using in Java full-stack.

I have also used ScalaJs integration from RockTheJvm along with fixes for package versions. RockTheJvm tutorial also integrates with database/docker, therefore provides an extended insight into the approach. I want to keep templates concise so any integration is left outside the scope.

After I created the template I realized that it is suitable to use Typescript instead of Javascript. Thus changing the client to whatever FE framework is available is suitable with least impact on the concept.

Project structure

Common - (Domain) shared code - DTOs
Client - FE code
Server - BE code

Common Module

Contains DTOs shared between Client and Server.

Client

Build vite.js project
Create ClientApp.scala which calls BE to get all products. It transforms the list of products into html content and fill it in <... id="app"> from index.html
Add the following field and script to index.html, the rest of its content is not needed <div id="app"></div> <script type="module" src="/app.js"></script>
Use styles.css from Startbootstrap
app.js calls scalajs:main.js which is compiled by ScalaJs inside client\target\scala-3.6.2\client-fastopt\main.js, it contains the converted scala into javascript code from App.scala and common->Product.scala
Add vite.config.js to configure server proxy, explained here Vite-Server-Proxy

Server

Use http4s - EmberServerBuilder to start a server with a "controller".

CLI

Command line is pretty well explained in IdiomaticSoft, RockTheJvm or in Readme

Github repo:

Github - Scala3Http4sFullStack

Scala full-stack with

Scala3
Zio
ScalaJs
Javascript
Laminar

As previously, I have used the repo outline proposed in this tutorial IdiomaticSoft.

Project structure

Common - (Domain) shared code - DTOs
Client - FE code
Server - BE code

Common

Create the DTO that is shared between Client and Server.

Client

This time client is provided by Medium-ScalaFullstackWebApp, it is implemented in scala using Laminar.

Necessary files

index.html
main.js
package.json
vite.config.js
build.sbt
plugins.sbt
add src folder
add scala code in src folder

Server

Use the code from Medium-ScalaFullstackWebApp

CLI

Command line is pretty well explained in Medium-ScalaFullstackWebApp or in Readme

Github repo:

Github - Scala3ZioFullStack

Observations

In particular any of the referenced tutorials is either complex or contain too much unrelated info, or have some missing, unexplained elements. For me, it is important to have a clean setup that is also predictable, should result in building the same structure and produce the same outcome. It is easy to mess things up just by calling, apparently similar content, in different ways. For example, the most suitable way to have a clean -common- module is by creating it using this command (crossProject(JSPlatform, JVMPlatform) in file("common")) other variations provide different result, I learned this stuff while reading RockTheJvm - Scala3Typelevel. From IdiomaticSoft I learned about .aggregate(server) which provides a cleaner build result. Each tutorial comes with a benefit and a difference that worth to try while searching for a suitable template.

References

IdiomaticSoft

RockTheJvm

RockTheJvm - Scala3Typelevel

Medium-ScalaFullstackWebApp

Startbootstrap

Vite-Server-Proxy

Github - Scala3Http4sFullStack

Github - Scala3Http4sFullStack - Readme

Github - Scala3ZioFullStack

Github - Scala3ZioFullStack - Readme

Scala's Variance

Mircea Sirghi — Thu, 12 Dec 2024 14:07:36 +0000

Intro

I think Scala variance chapter is misunderstood heavily even by skillful programmers. All the articles I have found so far explain more or less the same boilerplate they may have found on some common resource and everybody repeat themselves and don't cover enough aspects which makes everybody confuse this concept.

Understanding Contravariance

This appears to be the hardest, however, it is not harder then Covariance, even more, it is easier that Covariance. IMHO Covariance is misunderstood as well, which makes Contravariance so difficult.

Notation: SomeClass[-A] - reads as SomeClass is contravariant in A

How is it used ?

The widespread example is on Serializers. If one defines a Serializer on a [parent of A] it can further be assigned to a Serializer of [A]. This way, it is not necessary to -reinvent the wheel-. In my words, I define something for a [parent of A] and I can use it for [A]. So it works at the class level.

Still, what's the point ?

It is like kibble that can be used to feed Dogs and Cats. Same food, different Animals.

abstract class Food {
  val foodType: String
}

abstract class Pet(val name: String)
class Dog(override val name: String) extends Pet(name)
class Cat(override val name: String) extends Pet(name)

class Kibble[-A](override val foodType: String) 
extends Food {
  def printData(values: List[A]): Unit = {
    for (item <- values) {
      item match
        case p: Pet =>
          println(p.getClass.getSimpleName + " "
            + p.name + " food type is "
            + foodType)
        case _ =>
    }
  }
}

So the following apply:

def main(args: Array[String]): Unit = {
  val listCat: List[Cat] = List(Cat("cat1"), Cat("cat2"))
  val listDog: List[Dog] = List(Dog("dog1"), Dog("dog2"))

  var kibble = Kibble[Pet]("pelletsOfMeat")

  var kibbleCat: Kibble[Cat] = kibble
  var kibbleDog: Kibble[Dog] = kibble

  kibbleCat.printData(listCat)
  kibbleDog.printData(listDog)

  kibble.printData(listCat)
  kibble.printData(listDog)
}

Implications

First implication:
SomeClass of [A] can be assigned a value of a SomeClass of a [parent of A or A].

Second implication:
One can create list Kibble[Cat] and Kibble[Dog] just from Kibble[Pet] without having to dig into specifics.

Third implication:
A function over Pet type can be passed a Cat type and it will run successfully. Also it will have a strong type checking.

Understanding Covariance

So, what is Covariance ? Well, it is not easier than Contravariance, and it's purpose is not opposed, it's different.

Notation: SomeClass[+A] - reads as SomeClass is covariant in A

How is it used ?

The widespread example is of a function that is consuming a parent and is passed a child and it still works. So it works at function level as opposed to Contravariance that works at class level. However, it works at class level as well. So, there are two variations of Covariance.

Variation 1, Class level

abstract class Food {
  val foodType: String
}

class Kibble[+A](override val foodType: String, val pets: List[A]) extends Food {
     def printData: Unit = {
       for (item <- pets) {
         item match
           case p: Pet =>
             println(p.getClass.getSimpleName + " "
               + p.name + " food type is "
               + foodType)
           case _ =>
    }
  }
} 

abstract class Pet(val name: String)
class Dog(override val name: String) extends Pet(name)
class Cat(override val name: String) extends Pet(name)

The following apply:

def main(args: Array[String]): Unit = {
  val listCat: List[Cat] = List(Cat("cat1"), Cat("cat2"))
  val listDog: List[Dog] = List(Dog("dog1"), Dog("dog2"))

  var kibbleCat: Kibble[Cat] = Kibble[Cat]("pelletsOfMeat", listCat)
  var kibbleDog: Kibble[Dog] = Kibble[Dog]("pelletsOfMeat", listDog)

  var kibbleCat1: Kibble[Pet] = Kibble[Cat]("pelletsOfMeat", listCat)
  var kibbleDog1: Kibble[Pet] = Kibble[Dog]("pelletsOfMeat", listDog)

  kibbleCat.printData
  kibbleDog.printData

  kibbleCat1.printData
  kibbleDog1.printData
}

Variation 2, function level

def printDataVariation(kibble: Kibble[Pet]): Unit = {
  for (item <- kibble.pets) {
    item match
      case p: Pet =>
        println(p.getClass.getSimpleName + " "
          + p.name + " food type is "
          + kibble.foodType)
      case _ =>
  }
}

The following apply:

def main(args: Array[String]): Unit = {
  val listCat: List[Cat] = List(Cat("cat1"), Cat("cat2"))
  val listDog: List[Dog] = List(Dog("dog1"), Dog("dog2"))

  var kibbleCat: Kibble[Cat] = Kibble[Cat]("pelletsOfMeat", listCat)
  var kibbleDog: Kibble[Dog] = Kibble[Dog]("pelletsOfMeat", listDog)

  printDataVariation(kibbleCat)
  printDataVariation(kibbleDog)
}

Implications

First implication:
SomeClass of [A] can be assigned a value of a SomeClass of a [child of A or A].

Second implication:
A function that works with Pet type will work with child of Pet type.

Positions

There is also one more thing to notice with regards to functions, contravariant position is the argument list and covariant position is the return type. This is explained in (Scala in Action, MANNING, Nilanjan Raychaudhuri). However, I want to explain it over again for the sake of remembering it. Following are two similarly looking errors that mean different things.

1.
**Covariant** type A occurs in **contravariant position** in type List[A] of value values

This means that we have a Covariant type [+A] and create a function with a param of type A. which heads to the conclusion that contravariant position is synonym to function argument.

2.
**Contravariant** type A occurs in **covariant position** in type A of value findPet

This means that we have a Contravariant type [-A] and create a function with a return type A. Which heads to the conclusion that covariant position is synonym to function return type.

The wording "contravariant position" or "covariant position" has a sort of cockiness to it as I don't see the reason to not use "argument type" or "return type" instead. The reason scala wants to change the established naming convention is surreal. I also consider this to have a noticeable impact to the way these definitions are perceived by the community.

Invariance

Will elaborate on Invariance later. At this point, it feels straight forward. Will work on it if I observe any interesting elements.

Scala's Diamond problem

Mircea Sirghi — Sun, 08 Dec 2024 14:23:11 +0000

Intro
Have recently learned about Scala's Diamond problem solution and found out most examples cover particular paths leaving some opened questions.

In this article I reverse engineer the concept so that I can recall it next time I revise it, as this concept is pretty complex.

First thing I learned is that the solution to diamond problem is called Scala Linearization. It is an algorithm that constructs the list of traits in the order of priority. Where the nearest to the object has the highest priority.

Example:

A->B->C->D

Means B has the highest priority in the list, and A is the Object that has to call a method that can be defined and implemented in any of B, C, D.

Thus understanding how to build the list is the key to understanding what would be the result.

Reverse engineering the algorithm

Algorithm description in Wikipedia: "using a right-first depth-first search of extended 'traits', before eliminating all but the last occurrence of each module in the resulting list" Wikipedia - multiple-inheritance

This means there are three rules

right-first
depth-first
eliminate duplicates but the last

Right first is the most explained one of the three, a resource that I found insightful enough is this one: Medium - diamond-problem-solution-in-scala
There is no need to elaborate on it as it is pretty straight forward, one starts reading paths from the right.

Depth first is seldom covered in articles, a very good article, that I found impresive, is this one: Kyriakos - liniarization-in-scala
It analysis how linearization works, and in my opinion misses just one thing, the case when the right branch is bigger then the left one as below:

So if B and E override the same method, which one will be called ?

Extending the examples in the Right first article to demonstrate it:

object DiamondProblem {

    trait A {
        def M(): Unit = println("Hi, This is M from trait A")
    }
    trait B extends A {
        override def M(): Unit = println("Hi, This is M from trait B")
    }
    trait E extends A {
        override def M(): Unit = println("Hi, This is M from trait E")
    }
    trait C extends E {
    }
    class D extends B with C {
    }

    def main(args: Array[String]): Unit = {
        var sut = D().M()
    }
}

The result is:

Hi, This is M from trait E

And I guess it completes the demonstration for the depth first.

Eliminate duplicates but the last - for me it was hard to understand until I literally applied it over the Wikipedia's path:

D->C->A->B->A
removing duplicate elements but last results in
D->C->B->A

In case of depth-first we have D->C->E->A->B->A, resulting in
D->C->E->B->A.

I think I understood the concept. Comment if you disagree.

Where is the Monad ?

Mircea Sirghi — Thu, 14 Nov 2024 13:54:35 +0000

While learning Scala, I came across the concept of Monads or rather, what I’d call a widespread misconception, as most articles and explanations are incomplete, misleading, and steeped in confusion.

I recall a discussion, long time ago, with a colleague who mentioned that Scala is more interesting than Java because it contains Monads. When asked about what is a Monad, no clear definition was provided but an example: "think about it as an Optional(Java8) or Either(from Vavr)".

I initially ignored the topic, but once I became a Scala developer, I decided to analyze and truly understand the concept so that I could speak about it without any ambiguity if ever asked

One thing I found out is that Monad is not a concept defined in Scala and that you have to implement it or benefit from already created ones.

In mathematics the concept is based of morphisms from one set to another, and their composition. Which is quite simplistic and at the same time highly abstract.

In programming though, you have to just start writing a for and stumble upon an embarrassing question: how many items are in a set ?

for(int i=0;i<=? ...

What if there are no items, one item, many or infinite ? Each case has to be treated separately jamming the code with if/cases and whatever other solutions out there...

What if there are different pairs of sets? Implement a for for each pair ?

Regardless of the chosen implementation it is always solving one thing, a mapping from one set to another. So if it is just about mapping from one set to another, why not making it a standard that works on any set, performs an action, returns another set and allow the process to start over?

Basically build a wrapper, it takes an array of a specific type, a function from one type to another type, and return a wrapper over another type. And it can be chained indefinitely or until the result is changed from wrapper to a value. <- the description of a monad in simple words

From here things become simple if not obvious, a construction like:

int sum = Stream.of("String 1", "String 2", "String 3", "String 4", "String 5") .mapToInt(String::length) .reduce(0, Integer::sum);

is a Monad in Java.

Here’s the formal (mathematical) demonstration of that:

Monad is a functor.
A Functor is a mapping between Categories, in simple terms it associates for any element x in Category A an element y in Category B,
A Category is a structure that consists of a set of objects, a set of morphisms and a binary operation defined on compatible pairs of morphisms called composition.
A category that has only one object is a Monoid. And this is the key to reverse engineer concept.

From Monoid to Monad

Monoid definition is simple

Set
Binary operation with a result in the same Set
Identity element

So lets define two monoids

Monoid S

A set of all strings
Concatenation operation (returns a string, also a part of set)
Identity element is ""

Monoid I

A set of all integers
(+) operation
Identity element is 0

From Monoid to Category

Monoid is a particular form of Category, thus we have two categories S and I.

From Category to Functor

We define a morphism from Category S to Category I:

(String item) -> item.length

And we have the Monad

sum = Stream.of("String 1", "String 2", "String 3", "String 4", "String 5") .mapToInt(String::length) .reduce(0, Integer::sum);

Problems that monads address

Simple for

for(every i in list) {
   doSomeStuff
}

Written in a monadic way:

list.forEachElementDo(doSomeStuff)

Chaining fors

Supposedly there is this list

parentList = List[List[B]]

The generic problem is to doSomeStuff on each element.

for(every i in parentList ) {
   for(every j in childList[i]){
     doSomeStuff
   }
}

Written in a monadic way:

parentList.forEachElementDo(childList -> childList.forEachElementDo(doSomeStuff))

It is clear now that the result is flattened(into doSomeStuff return type) therefore the flatMap function used in monads.

Thus, in a conventional manner, the code becomes:

parentList.flatMap(childList -> childList.flatMap(someStuff))

Sequencing fors

If you sequence "fors" as:

parentList.flatMap(doFirstStuff).flatMap(doSecondStuff)

You basically "monaded" this code:

for(int i=0; i<....){
   doFirstStuff
}
for(int j=0; j<....){
   doSecondStuff;
}

Conclusion

I approach monads from the perspective of the problems they solve rather than what they represent. It simplifies the concept and makes it easier to grasp intuitively, without getting lost in the mathematical formalism, which is often difficult to internalize and tends to create confusion.

This explanation is presented in the simplest way possible, which might seem almost unbelievable to those who have invested considerable effort in explaining monads through more complex approaches. Apologies if this comes across as a slight on anyone’s expertise. If so, please feel free to point out any mistakes in the explanation or share additional examples of problems that monads help solve.

Sources

Monad:
https://en.wikipedia.org/wiki/Monad_(functional_programming)
Functor:
https://en.wikipedia.org/wiki/Functor#endofunctor
Category:
https://mathworld.wolfram.com/Category.html
https://en.wikipedia.org/wiki/Category_(mathematics)
Monoid:
https://en.wikipedia.org/wiki/Monoid#Monoid_homomorphisms

Simplified explanation of JPA relations

Mircea Sirghi — Wed, 16 Aug 2023 06:27:06 +0000

It was hard for me to grasp the concept of JPA relations until I started to invest more time in it.

I will start with OneToOne, the easiest, what I find important in this relation is that we can insert ids for each participant making it bidirectional at no cost(except allocated space for parent id in child table).

It is not necessarily to map OneToOne bidirectionally and it does make sense to map it LAZY otherwise N+1 problem is your friend if using JPA QueryBuilder. This is pretty strange because LAZY is the source for N+1. True, however you can choose if it is a hidden N+1 or a managed one. When query a Parent through QueryBuilder, if OneToOne child is eagerly connected, JPA will run a query to find all parents, will create a list of child ids and for each id will run a query to get each child details, so N+1 through EAGER. This is hidden, you can spot it just by verifying generated queries. Only by using LAZY, you will be able to fetch Parents only. And yes you will have to fetch explicitly each child, still within N+1, the only difference is that first example is unmanaged, done by JPA behind the counter, second one is managed, you are fully aware of what happens.

OneToMany is a bit complicated, and I wish I knew from the beginning that in order to not duplicate the rows in parent table, parent table id should be placed into the child not vice-versa. The reason is simple, if child id is placed in parent, parent has to replicate its rows for each child relation just because child id is present in parent table.

Here is how data in parent duplicates:

A better approach would be to map child to parent by parent id and live it as is. It becomes ManyToOne now.

And data is aligned as expected:

The join table for OneToMany is an overhead. Not only it becomes redundant, requires additional space, and adds up to the complexity, it is also a source to mistakenly transform it into a ManyToMany relation.

For OneToMany relation join table does not save allocated space:

ManyToMany is where a join table helps. Its apparent complexity saves database space, without a join table database size will increase unjustifiably by replicating data.

Without join table:

Data is duplicated:

Moving to join table and schema becomes comprehensible:

Data also avoids redundancy except for ids:

Offtopic
Non relational databases are prone data replication issues. Mainly because it is hard to imagine a relational diagram. Though, not only non relational DBs are prone to this issue. Relational are too. For example if the architecture is based on Spark framework. The gain in performance by running tasks in parallel comes at the cost of removing foreign key relations from database. And when multiple DDL changes are made uncontrollably it is hard to imagine how data are linked. This is why Spark based architects run away from Hibernate/JPA, they will move to MyBatis or similar frameworks, even JDBC in this case would become a good choice. Most interesting is that after a while, Spark applications become Spark addictive. Due to data duplication it will be hard to optimize such databases. And the solution would be to increase the number of Spark workers. Unfortunately, even horizontal scaling is not indefinitely inflatable. It is easy to predict the refactoring to a new data storage solution, non relational inclusively, in this kind of projects.

Run Docker from WSL

Mircea Sirghi — Sat, 29 Jul 2023 07:12:50 +0000

Introduction

This article is a complete guide on how to setup WSL on windows and run docker, Kafka, Kubernetes commands directly from GitBash console without having to open WSL.

Additionally I have added the setup to use Java Test Containers.

The whole purpose is for anyone who wants to migrate to a new distribution or to change machines, or has to fix a broken WSL, in just a few steps the environment is prepared rapidly without the need to investigate the internet on each particular problem.

Preparing WSL with docker

First part is preparing windows to use docker from WSL without Docker Desktop.

Adding Java Test Containers

I observed that I can also automate the part to add Java Test Containers so this is the second part. So that anytime WSL gets broken or I want to switch to a new linux distribution or to change laptops, I can allway run the same commands and expect it works.

Setting up Kubernetes

Third part is how I setup Kubernetes through WSL.

Kafka setup

I will add setting up Kafka soon. Currently I am looking to change the whole approach to using just Kubernetes.

Note: I have removed scripts to enable docker on Powershell and CMD as I have never used them and find them redundant.

On Github

TBC