CQRS is a useful pattern to reason about the activities of a specific domain. But it definitely comes with a steep learning curve. Reads, Writes, DDD, Event Sourcing, Eventual Consistency, why should we care?
I’m working on a new project intended to replace a large — too large — monolith that created ramifications and introduce coupling in the whole company.
To adapt to the evolving needs of the…
The Conduktor developer team is composed of a group of experienced and curious professionals. Scala features/enables a lot of characteristics we value, so that’s the language we chose. Our DNA is our Kafka expertise and we believe that modern software architectures have to be built around streaming.
We believe that FP is the best way to write robust software without surprises. Our team has the required knowledge to use this paradigm, and we of course want our applications to leverage FP.
This post is an excerpt of my full article on my blog: https://www.sderosiaux.com/articles/2019/08/07/kafka-streams-topology-and-optimizations/. It’s quite long but has many insights, explanations, diagrams, and code examples.
Optimizations clearly reduce the load on our Kafka Cluster by avoiding to create unnecessary internal topics and simplify the Topology our Kafka Streams applications use. They improve performances and reduce memory/network pressure on Kafka Streams applications: they will process less data and will avoid doing unnecessary or redundant operations to process our streams.
Despite a few subtleties (explained in the full article) and exceptions we can get when starting the Kafka Streams application, we should…
Today, someone asked me this question: “What makes you a Kafka expert?” at the beginning of a job interview where I applied to work as a Freelance. The job was interesting because the company was considering moving from a monolith to a Kafka stack and micro-services. A huge step! I wanted to know more. At the end, the job interview looked more like a training seance than an interview. Damned, I didn’t even bill them!
By no means I’m considering myself a Kafka expert. I lack a lot of knowledge about Kafka: I can’t answer all the questions one asked…
Working with my team, I had to deal with some business errors which were Exceptions. I was a bit nervous about them, and was having a “not good enough”, “not expressive enough” feeling. Having a Scala background, I decided to show them how we could handle errors differently.
Let’s look at how we are generally dealing with errors in Java. We’ll see what are the downsides, and why’s important to properly handle all of our errors in a more type-safe way.
We’ll work from a base solution and improve it using vavr and some of its functional types: Either, then…
Working in a large company, my team and I are working with JSON data (let’s not talk about CSV and XML please). We had to find out what were the definitions and business rules of the models we received from other services. Trust me, it’s not that easy. Knowledge is sparse.
There is a ongoing work in a business unit dedicated to the standardization of the models across the company. It’s purely conceptual, without code. Each service implement the models it relies on. Nobody shares code. It’s a share-nothing architecture. …
New Job, Big Company, Java team, no Scala miles away.
My goal: move some not-that-big Java projects to Scala and start the inertia to create new projects in Scala.
Why? While I like Java as it gains more capabilities, I simply love Scala. The existing projects were in good ol’ verbosy Java and I know quite well Scala and the benefits we could expect from it.
I think Scala makes it easier to read — when we don’t use “esoteric” libraries — , to share with others, and to refactor. Scala leads to a more robust code, a better productivity…
We all started with Scala Futures. They bring so much power and their syntax is simple enough. “Concurrency and asynchrony made easy” could be their tagline.
Futures allow us to deal with “values that don’t exist yet”. We can create a pipeline of transformations on top that will be applied when the time comes: when the Future will be fulfilled.
We can execute Futures in parallel, we can also race them. As developers, we often need to deal with concurrent operations. We have several databases, several services: we always wait for some answers asynchronously.
This sort of code does not…
It always feels good to follow the rhythm of the tweetosphere, to use the latest tool or framework (still in alpha version), to be hype, to talk about it, to blog about it: you need to use this revolutionary bleeding-edge thingy.
Your ops team will love you. (taken from experience)
Beyond that, in the real-world, when you have a serious business, systems running in production, when you can’t have any downtime, when you need to monitor everything and be responsive: you can’t play with your technology stack, you can’t be hype. You could burn yourself and the whole company at…
It’s not always obvious to understand what referential transparency is and why it matters. It’s often intertwined with “complex” frameworks, dealing with Functional Programming.
Here, I start from a simple case all developers are dealing with (constants), and show the “equivalence” for more complex cases (class), and the impact when Referential Transparency is present or not.
When we are working with constant values, it’s easy to reason about: we know the value is fixed, we can replace the constant by its value. We often use UPPERCASE notation to notify the reader of this behavior. It’s the same in every language: