Welcome to the new week!

I’ll start with an invitation to the next Architecture Weekly webinar. This time, a special guest, my friend Laïla Bougriâ, will tell us how to debug our thinking.

When I saw Laïla giving this talk as a keynote at this year’s NDC London, I was impressed, but the best commentary was that I heard a guy sitting behind me saying loudly to his friend: “Wow, that was a great talk!”. And it was, I think, essential to building a mental model for solving problems if we want to be architects.

Laïla is also one of my favourite speakers about messaging architectures. Yet, this talk won’t be about messaging but the general mind tooling for solving problems. I’m thrilled that she agreed to do the webinar for our community.

Laïla is a software engineer and solution architect with over 15 years of experience in the .NET space. She's a Microsoft Azure MVP and a frequent speaker at conferences worldwide. Currently, Laïla is busy building NServiceBus at Particular Software and solving distributed riddles.

You should not miss it! See the details on the webinar page.

I really think that Event Sourcing, with its repeatable patterns and focus on business, can streamline development. Yet, learning it may be challenging. You need to learn both new approaches and tooling. That’s why I decided to publish Emmett to package safe defaults and my state-of-the-art. I don’t want to replace or compete with existing tooling but guide you through this journey.

Tests are first-class citizens in Emmett. I think that’s a pretty rare thing. I want to make getting the trust in your code and yourself smoother while going through the Event Sourcing journey. The proportion between unit, integration and end-to-end tests is up to you. The most important part is that I’ve got you covered. How? Check my new article to get the full explanation:

• Oskar Dudycz - Testing Event Sourcing, Emmett edition

Moving on to the links! One of the main areas of confusion and struggle is not understanding the financial model for our products. In our industry, we’re passionate about the stuff we do, and I truly believe that passion is overrated. I would much prefer to have a clear business relationship where the relationship between employer and employee can be transparent. Both sides know what they are signing for. Even if you’re a regular employee, it’s important to understand how budgeting works and where money comes from. Swizec Teller nicely explained that in plain English; read more:

• Swizec Teller - The 3 budgets

Speaking about money, Open-Source tools and creators are fighting strongly in the sustainability battle. The battle may already be lost, especially since most of them didn’t think that their work may be abused. That’s also why we see the trend of databases and other tooling changing their license to require payment when certain conditions are met. For instance, Redis recently changed it to fight Cloud Providers hosting it for money without contributing back.

• Redis - Redis Adopts Dual Source-Available Licensing

Now, the battle may already be lost, as cloud providers are earning huge amounts of money and won’t want to cut their margins. We already saw that for Elastic and Mongo, where AWS provided the alternatives (OpenSearch and DocumentDB). Now, for instance, Microsoft announced their Redis alternative:

• Microsoft - Introducing Garnet – an open-source, next-generation, faster cache-store for accelerating applications and services

Of course, this won’t immediately match the maturity, flexibility, and feature parity of the regular tools, but oh well, they will advocate them as open-source, next-generation, and faster. And sell them to their clients.

Of course, it’s frustrating when we need to pay more, but we should also embrace the reason why the OSS model is broken and prepare for what will come next. Such changes are just the next sign of it.

Let’s continue the facts and myths considerations. Josh Collinsworth, in his article, shares an intriguing observation. On the one hand, people complain these technologies are too complicated, but on the other hand, they also say they're too simple to be taken seriously. There’s a truth in that people (especially backend devs) in tech don't give enough respect to frontend development, like working with CSS and HTML. This perspective is about 15 years too old. Nowadays, the front end is often more complex and has more responsibility than the back end. I think that we’ll see more of that, with the backend being blended with the front end and more computations moving on the edge.

The discussion is also about more than just coding—it's also about how people in the tech world see different jobs. Not valuing frontend work enough might partly be because of tech biases. For example, frontend development is more diverse than other tech fields, which might be why it's not seen as important as jobs like backend development, which have traditionally had less diversity. The article nicely goes through such considerations. Read more:

• Josh Collinsworth - The quiet, pervasive devaluation of frontend

Also, as a follow up, it’s nice to read Dan North's old take on how simple is too simple:

• Dan North - How simple is too simple?

Speaking about complexity on the front end, let’s go through two case studies, starting with Expedia’s (platform for travel search). They shared their search optimisation case study:

• Expedia - Search Speed: Making Expedia Flights Faster

As always, the most interesting part of such write-ups is what you can read between the lines. It seems that they used micro-frontends to reuse code, speed up delivery, and enable Progressive Web Applications (so they could load the code gradually). That led to a fragmented and chatty API, which also caused redundant payload transfer between the backend, frontend, and services. Sometimes it’s useful to group small calls into one bigger. They named it “horizontal slices”.

To let the user be able to view the search offers summary faster, the detailed information was separated out to another GraphQL query which only resolves upsell information. This helped speed up the user experience as now the user can view the summary information faster and the downstream call will be made only for the offer which is clicked. Horizontal Slicing experiment improved the non-supply overhead by 20% on Web and Native apps (iOS/Android)

In my opinion, that’s not a precise term. It’s still vertical for me, as it’s focused on the specific process (upsell). It’s a realisation of the fact that business works differently than expected.

As always, with such articles, I’m also curious how much of the improvement is related to knowing the domain better and how much to the specific technical decisions.

The other case study comes from Decathlon. They published a four-part series explaining their approach to Backend-for-frontend. So, APIs are designed with the client's needs as the prime goal. I think that they’re a decent story on the considerations, tradeoffs, etc:

• Decathlon - BFF: A design pattern helping teams gain ownership

From the different topic. OpenTelemetry started its CNCF graduation process. They’re already production-ready and mature. It’s also one of the most impressive collaborations between multiple competitors to come up with a unified approach. If you want to help them with your case study or see some references, you can contribute here:

• OpenTelemetry - CNCF OpenTelemetry Graduation proposal

Read also an interesting article from Werner Vogels on the trial between AWS and HeatWorks to use the servers heat to warm up houses.

• Werner Vogels - District heating: Using data centers to heat communities

Check also other links!

Cheers

Oskar

p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!

p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.

Architecture

• Oskar Dudycz - Testing Event Sourcing, Emmett edition

• Swizec Teller - The 3 budgets

• Josh Collinsworth - The quiet, pervasive devaluation of frontend

• Dan North - How simple is too simple?

• Decathlon - BFF: A design pattern helping teams gain ownership

• Expedia - Search Speed: Making Expedia Flights Faster

• Andrew Schofield - Queues for Kafka

• Linda Rising - Understanding the Power of Abstraction in Patterns

• 📺 Gregor Hohpe - Build Abstractions Not Illusions

DevOps

• OpenTelemetry - CNCF OpenTelemetry Graduation proposal

• McDonald's Technical Blog - Reduce, reuse, recycle: McDonald’s reusable workflows

• Retina - eBPF distributed networking observability tool for Kubernetes

Databases

• Redis - Redis Adopts Dual Source-Available Licensing

• Microsoft - Introducing Garnet – an open-source, next-generation, faster cache-store for accelerating applications and services

• Raddevus - How Much Can Sqlite Handle? Multiple Threads Concurrently Inserting Into Sqlite

AI

• Adrian Cockcroft - Nvidia GTC: Hyperscaler Happiness and Enterprise Indigestion

Testing

• Bruno - Opensource IDE For Exploring and Testing Api's (lightweight alternative to postman/insomnia)

Frontend

• TanStack - High-quality open-source software for web developers

Java

• Inside Java - The Arrival of Java 22!

• Piotr Przybył - The best Java 22 feature: concurrent gathering

.NET

• 📺 The Breakpoing Show - Episode 016 – The 1 Billion Row Challenge With Mark Rendle

• Steven Giesel - NCronJob - Scheduling made easy

• Gérald Barré - Generate OpenAPI specification at build time from the code in ASP.NET Core

• Babu Annamalai - Marten native partial updates - patching

Node.js

• Drizzle - Headless TypeScript ORM with a head. Runs on Node, Bun and Deno. Lives on the Edge and yes, it's a JavaScript ORM too

TypeScript

• Matt Pocock - Type vs Interface: Which Should You Use?

Management

• Padmal Vitharana, Shahir A. Daya - Challenges in Adopting and Sustaining Microservice-based Software Development. Organizational challenges can be more difficult than technical ones.

Security

• ArsTechnica - Unpatchable vulnerability in Apple chip leaks secret encryption keys

Trivia

• Werner Vogels - District heating: Using data centers to heat communities

• LifeHacker - How to Make Google Show You the Good Search Results Again