Eventeny

eventeny

Learn How Build a Progressive Web App in Minutes with Next.js

Obteniu informació sobre com crear una aplicació web progressiva en qüestió de minuts amb Next.js

Aprenda a crear una aplicación web progresiva en minutos con Next.js

Découvrez comment créer une application Web progressive en quelques minutes avec Next.js

Next.js के साथ मिनटों में प्रगतिशील वेब ऐप बनाना सीखें

Naučite kako izgraditi progresivnu web-aplikaciju u nekoliko minuta uz Next.js

Pelajari Cara Membuat Aplikasi Web Progresif dalam Hitungan Menit dengan Next.js

Scopri come creare un'app Web progressiva in pochi minuti con Next.js

Next.js を使って数分でプログレッシブ Web アプリを構築する方法を学ぶ

Leer hoe u in enkele minuten een progressieve web-app bouwt met Next.js

Aflați cum să creați o aplicație web progresivă în câteva minute cu Next.js

Научите како да направите прогресивну веб апликацију за неколико минута помоћу Нект.јс

Next.js yordamida bir necha daqiqada progressiv veb-ilovani qanday yaratishni bilib oling

The iOS Guide to Haptic Feedback

When a project needs to be split How do successful projects usually get started? Quickly, without long discussions, in startup mode: we build features and deal with technical debt later. Under such conditions, it’s hard to establish an architecture that would allow the project to continue evolving after 5–7 years. The frontend part of our project was no exception. In this article, I’ll explain how we transitioned from a classic React application to a truly big project. So, we had a typical React 17 app. Redux + logic in thunks and middlewares. Custom SSR on Express. The project was actively growing, attracting new users, and gaining functionality. The complexity of the code increased, and after the Series A round of funding, the company allowed us to allocate up to 15% of our time to technical tasks. At this stage, the product development team began to split into “units”—this is what we call the teams which handle the app’s functionality (a specific user role or scenario). At this point, the frontend project saw its first optimisations: Client-side lazy loading of components
Optimising the Redux middleware call stack These optimisations allowed us to add new features to our React app for a few more years. The project eventually got Series B funding, so the number of frontend developers reached 30 and the size of the main bundle grew to 300 KB. The code's interdependence and task complexity indicated that it was time to break the app into parts. We started by improving the asynchronous loading of components using React Loadable. This allowed us to load not just components asynchronously but entire pages. React Loadable gave us the ability, with our SSR, to understand which parts of the app were touched when rendering the HTML, collect those JS files, and load them before the first client render. After that, we realised that the main issue was in the middleware and thunks, not in the code of our pages. So, we began splitting the business logic within them. Getting started We decided to divide the project into modules using a modern tool for microfrontends. Here are the challenges we faced: SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR.
Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. At this point, we had a 4 KB overhead per module and a few asynchronous pages using the microfrontend tool, but it still didn’t solve the main issue—splitting the business logic. In the end, we put a lot of effort into implementing the tool without gaining significant optimizations. This happened because, regardless of the tool you use, what’s most important is how you logically split the app’s parts. After that, we moved on to directly dividing the business logic, having first solved a few related issues. Data sharing What’s stopping us from separating a module from our app? First of all, the shared stores. Let’s look at this problem using the example of the ‘users’ store. It looks something like this: export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; Each of our future modules uses such a store in roughly the following way. UserIds are stored in objects used by our module, and in selectors, we fill them with data from the users store. Why was it done this way at the start of the project? For convenience, caching, and data normalisation. Data from modules is stored in one place and, in some cases, can be reused from the cache instead of being requested again. The problem is that such a reducer is part of the common store, and if all modules have access to the shared store, it increases module interdependence. So, we extracted such reducers into separate stores using Zustand. This allowed us to isolate modules from data they didn’t need, while maintaining data sharing and reactivity between modules. Event sharing between modules The next issue we solved was shared middleware. Let’s break this down using the example of socket middleware. As the name suggests, this middleware processes events coming through a WebSocket connection. The problem is that this single middleware processes events for the stores of almost all modules. We reorganized it as follows: we created a separate event bus based on EventEmitter, independent of Redux, and now the module that maintains the WebSocket connection produces messages straight into the event bus. This way, we managed to split the common logic and distribute it across modules. An important point here: when switching from dispatching events to EventEmitter, you don’t need to migrate all events, just those used in multiple modules. Events that happen and are handled within one module don’t need to be migrated to EventEmitter. It’s crucial to understand the list of modules you want to isolate. A few more things to mention Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render.
In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. After solving these issues, we began splitting the business logic into modules, reflecting the structure of how our company is divided into teams and areas of responsibility. Conclusion Our mistake was starting with a tool before logically dividing the modules. The correct order for modularisation in our case would have been: Logically divide the project into modules: make a list of modules.
Solve the main issues with shared stores, events, and the base component library.
Actually split the business logic.
Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. And in conclusion, I want to wish good luck to everyone who is starting to split their application into modules. It's a long journey, but the result is worth it. When a project needs to be split When a project needs to be split How do successful projects usually get started? Quickly, without long discussions, in startup mode: we build features and deal with technical debt later. Under such conditions, it’s hard to establish an architecture that would allow the project to continue evolving after 5–7 years. The frontend part of our project was no exception. In this article, I’ll explain how we transitioned from a classic React application to a truly big project. So, we had a typical React 17 app. Redux + logic in thunks and middlewares. Custom SSR on Express. The project was actively growing, attracting new users, and gaining functionality. The complexity of the code increased, and after the Series A round of funding, the company allowed us to allocate up to 15% of our time to technical tasks. At this stage, the product development team began to split into “units”—this is what we call the teams which handle the app’s functionality (a specific user role or scenario). At this point, the frontend project saw its first optimisations: Client-side lazy loading of components Optimising the Redux middleware call stack Client-side lazy loading of components Optimising the Redux middleware call stack These optimisations allowed us to add new features to our React app for a few more years. The project eventually got Series B funding, so the number of frontend developers reached 30 and the size of the main bundle grew to 300 KB. The code's interdependence and task complexity indicated that it was time to break the app into parts. We started by improving the asynchronous loading of components using React Loadable. This allowed us to load not just components asynchronously but entire pages. React Loadable gave us the ability, with our SSR, to understand which parts of the app were touched when rendering the HTML, collect those JS files, and load them before the first client render. After that, we realised that the main issue was in the middleware and thunks, not in the code of our pages. So, we began splitting the business logic within them. Getting started Getting started We decided to divide the project into modules using a modern tool for microfrontends. Here are the challenges we faced: SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR. Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR. SSR Build Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. Integration with Loadable At this point, we had a 4 KB overhead per module and a few asynchronous pages using the microfrontend tool, but it still didn’t solve the main issue—splitting the business logic. In the end, we put a lot of effort into implementing the tool without gaining significant optimizations. This happened because, regardless of the tool you use, what’s most important is how you logically split the app’s parts. After that, we moved on to directly dividing the business logic, having first solved a few related issues. Data sharing Data sharing What’s stopping us from separating a module from our app? First of all, the shared stores. Let’s look at this problem using the example of the ‘users’ store. It looks something like this: export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; Each of our future modules uses such a store in roughly the following way. UserIds are stored in objects used by our module, and in selectors, we fill them with data from the users store. Why was it done this way at the start of the project? For convenience, caching, and data normalisation. Data from modules is stored in one place and, in some cases, can be reused from the cache instead of being requested again. The problem is that such a reducer is part of the common store, and if all modules have access to the shared store, it increases module interdependence. So, we extracted such reducers into separate stores using Zustand. This allowed us to isolate modules from data they didn’t need, while maintaining data sharing and reactivity between modules. Event sharing between modules Event sharing between modules The next issue we solved was shared middleware. Let’s break this down using the example of socket middleware. As the name suggests, this middleware processes events coming through a WebSocket connection. The problem is that this single middleware processes events for the stores of almost all modules. We reorganized it as follows: we created a separate event bus based on EventEmitter, independent of Redux, and now the module that maintains the WebSocket connection produces messages straight into the event bus. This way, we managed to split the common logic and distribute it across modules. An important point here: when switching from dispatching events to EventEmitter, you don’t need to migrate all events, just those used in multiple modules. Events that happen and are handled within one module don’t need to be migrated to EventEmitter. It’s crucial to understand the list of modules you want to isolate. A few more things to mention A few more things to mention Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render. In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render. In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. After solving these issues, we began splitting the business logic into modules, reflecting the structure of how our company is divided into teams and areas of responsibility. Conclusion Conclusion Our mistake was starting with a tool before logically dividing the modules. The correct order for modularisation in our case would have been: Logically divide the project into modules: make a list of modules. Solve the main issues with shared stores, events, and the base component library. Actually split the business logic. Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. Logically divide the project into modules: make a list of modules. Solve the main issues with shared stores, events, and the base component library. Actually split the business logic. Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. And in conclusion, I want to wish good luck to everyone who is starting to split their application into modules. It's a long journey, but the result is worth it.

Our Journey to Micro-Frontends

In-Depth Analysis of DolphinScheduler Task Scheduling, Splitting, and Execution Workflow

Using MinIO to Build a Retrieval Augmented Generation Chat Application

Die gebruik van MinIO om 'n herwinningsaansoek vir uitgebreide generasie-klets te bou

استخدام MinIO لبناء تطبيق دردشة يعتمد على الاسترجاع المعزز

Použití MinIO k vytvoření aplikace pro chat s rozšířenou generací načítání

Verwenden von MinIO zum Erstellen einer Retrieval Augmented Generation Chat-Anwendung

Uso de MinIO para crear una aplicación de chat de generación aumentada de recuperación

MinIO を使用して検索拡張生成チャット アプリケーションを構築する

ការប្រើប្រាស់ MinIO ដើម្បីបង្កើតកម្មវិធីជជែកកំសាន្តដែលបង្កើតឡើងវិញ

Mampiasa ny MiniIO hananganana fampiharana amin'ny chat Generation Augmented Retrieval

د ترلاسه کولو وده شوي نسل چیٹ غوښتنلیک جوړولو لپاره MinIO کارول

Použitie MinIO na zostavenie aplikácie na rozhovor s rozšírenou generáciou načítania

MinIO-dan peýdalanyp, gözlegiň giňeldilen nesil söhbetdeşlik programmasyny gurmak

Paggamit ng MiniIO para Bumuo ng Retrieval Augmented Generation Chat Application

When I was a child, I used to lie on the bed and gaze for a long time at the patterns on an old Soviet rug, seeing animals and fantastical figures within them. Now, I more often look at code, but similar images still emerge in my mind. Like on the rug, these images form repetitive patterns. They can be either pleasing or repulsive. Today, I want to tell you about one such unpleasant pattern that can be found in programming. Imagine a service that processes a client registration request and sends an event about it to Kafka. In this article, I will give an example of an implementation that I consider an antipattern and suggest an improved version. Option 1: Methodcentipede The Java code below shows the code of the RegistrationService class, which processes the request and sends the event. public class RegistrationService {

    private final ClientRepository clientRepository;
    private final KafkaTemplate<Object, Object> kafkaTemplate;
    private final ObjectMapper objectMapper;

    public void registerClient(RegistrationRequest request) {
        var client = clientRepository.save(Client.builder()
                .email(request.email())
                .firstName(request.firstName())
                .lastName(request.lastName())
                .build());
        sendEvent(client);
    }

    @SneakyThrows
    private void sendEvent(Client client) {
        var event = RegistrationEvent.builder()
                .clientId(client.getId())
                .email(client.getEmail())
                .firstName(client.getFirstName())
                .lastName(client.getLastName())
                .build();
        Message message = MessageBuilder
                .withPayload(objectMapper.writeValueAsString(event))
                .setHeader(KafkaHeaders.TOPIC, "topic-registration")
                .setHeader(KafkaHeaders.KEY, client.getEmail())
                .build();
        kafkaTemplate.send(message).get();
    }

    @Builder
    public record RegistrationEvent(int clientId, String email, String firstName, String lastName) {}
} The structure of the code can be simplified as follows: Here, you can see that the methods form an unbroken chain through which the data flow, like through a long, narrow intestine. The methods in the middle of this chain are responsible not only for the logic directly described in their body but also for the logic of the methods they call and their contracts (e.g., the need to handle specific errors). All methods preceding the invoked one inherit its entire complexity. For example, if kafkaTemplate.send has a side effect of sending an event, then the calling sendEvent method also acquires the same side effect. The sendEvent method also becomes responsible for serialization, including handling its errors. Testing individual parts of the code becomes more challenging because there is no way to test each part in isolation without using mocks. Option 2: Improved Version public class RegistrationService {

    private final ClientRepository clientRepository;
    private final KafkaTemplate<Object, Object> kafkaTemplate;
    private final ObjectMapper objectMapper;

    @SneakyThrows
    public void registerClient(RegistrationController.RegistrationRequest request) {
        var client = clientRepository.save(Client.builder()
                .email(request.email())
                .firstName(request.firstName())
                .lastName(request.lastName())
                .build());
        Message<String> message = mapToEventMessage(client);
        kafkaTemplate.send(message).get();
    }

    private Message<String> mapToEventMessage(Client client) throws JsonProcessingException {
        var event = RegistrationEvent.builder()
                .clientId(client.getId())
                .email(client.getEmail())
                .firstName(client.getFirstName())
                .lastName(client.getLastName())
                .build();
        return MessageBuilder
                .withPayload(objectMapper.writeValueAsString(event))
                .setHeader(KafkaHeaders.TOPIC, "topic-registration")
                .setHeader(KafkaHeaders.KEY, event.email)
                .build();
    }

    @Builder
    public record RegistrationEvent(int clientId, String email, String firstName, String lastName) {}
} The diagram is shown below: Here, you can see that the sendEvent method is completely absent, and kafkaTemplate.send is responsible for sending the message. The entire process of constructing the message for Kafka has been moved to a separate mapToEventMessage method. The mapToEventMessage method has no side effects, and its responsibility boundaries are clearly defined. Exceptions related to serialization and message sending are part of the individual methods' contracts and can be handled separately. The mapToEventMessage method is a pure function. When a function is deterministic and has no side effects, we call it a "pure" function. Pure functions are: easier to read,
easier to debug,
easier to test,
independent of the order in which they are called,
simple to run in parallel. Recommendations I would suggest the following techniques that can help avoid such antipatterns in the code: Testing Trophy Approach
One Pile Technique
Test-Driven Development (TDD) All these techniques are closely related and complement each other. Testing Trophy This is an approach to test coverage that emphasizes integration tests, which verify the service's contract as a whole. Unit tests are used for individual functions that are difficult or costly to test through integration tests. I have described tests with this approach in my articles: Writing Effective Integration Tests in Spring: Organized Testing Strategies for HTTP Request Mocking, Improving Integration Test Transparency, Reliable Testing with Kafka: Isolation Techniques. One Pile This technique is described in Kent Beck's book "Tidy First?" The main idea is that reading and understanding code is harder than writing it. If the code is broken into too many small parts, it may be helpful to first combine it into a whole to see the overall structure and logic, and then break it down again into more understandable pieces. In the context of this article, it is suggested not to break the code into methods until it ensures the fulfillment of the required contract. Test-Driven Development This approach allows separating the efforts of writing code to implement the contract and designing the code. We don't try to create a good design and write code that meets the requirements simultaneously, instead, we separate these tasks. The development process looks like this: Write tests for the service contract using the Testing Trophy approach.
Write code in the One Pile style, ensuring that it fulfills the required contract. Don't worry about code design quality.
Refactor the code. All the code is written, and we have a complete understanding of the implementation and potential bottlenecks. Conclusion The article discusses an example of an antipattern that can lead to difficulties in maintaining and testing code. Approaches like Testing Trophy, One Pile, and Test-Driven Development allow you to structure your work in a way that prevents code from turning into an impenetrable labyrinth. By investing time in the proper organization of code, we lay the foundation for the long-term sustainability and ease of maintenance of our software products. Thank you for your attention to the article, and good luck in your quest for writing simple code! When I was a child, I used to lie on the bed and gaze for a long time at the patterns on an old Soviet rug, seeing animals and fantastical figures within them. Now, I more often look at code, but similar images still emerge in my mind. Like on the rug, these images form repetitive patterns. They can be either pleasing or repulsive. Today, I want to tell you about one such unpleasant pattern that can be found in programming. programming. Imagine a service that processes a client registration request and sends an event about it to Kafka. In this article, I will give an example of an implementation that I consider an antipattern and suggest an improved version. Option 1: Methodcentipede The Java code below shows the code of the RegistrationService class, which processes the request and sends the event. RegistrationService public class RegistrationService {

    private final ClientRepository clientRepository;
    private final KafkaTemplate<Object, Object> kafkaTemplate;
    private final ObjectMapper objectMapper;

    public void registerClient(RegistrationRequest request) {
        var client = clientRepository.save(Client.builder()
                .email(request.email())
                .firstName(request.firstName())
                .lastName(request.lastName())
                .build());
        sendEvent(client);
    }

    @SneakyThrows
    private void sendEvent(Client client) {
        var event = RegistrationEvent.builder()
                .clientId(client.getId())
                .email(client.getEmail())
                .firstName(client.getFirstName())
                .lastName(client.getLastName())
                .build();
        Message message = MessageBuilder
                .withPayload(objectMapper.writeValueAsString(event))
                .setHeader(KafkaHeaders.TOPIC, "topic-registration")
                .setHeader(KafkaHeaders.KEY, client.getEmail())
                .build();
        kafkaTemplate.send(message).get();
    }

    @Builder
    public record RegistrationEvent(int clientId, String email, String firstName, String lastName) {}
} public class RegistrationService {

    private final ClientRepository clientRepository;
    private final KafkaTemplate<Object, Object> kafkaTemplate;
    private final ObjectMapper objectMapper;

    public void registerClient(RegistrationRequest request) {
        var client = clientRepository.save(Client.builder()
                .email(request.email())
                .firstName(request.firstName())
                .lastName(request.lastName())
                .build());
        sendEvent(client);
    }

    @SneakyThrows
    private void sendEvent(Client client) {
        var event = RegistrationEvent.builder()
                .clientId(client.getId())
                .email(client.getEmail())
                .firstName(client.getFirstName())
                .lastName(client.getLastName())
                .build();
        Message message = MessageBuilder
                .withPayload(objectMapper.writeValueAsString(event))
                .setHeader(KafkaHeaders.TOPIC, "topic-registration")
                .setHeader(KafkaHeaders.KEY, client.getEmail())
                .build();
        kafkaTemplate.send(message).get();
    }

    @Builder
    public record RegistrationEvent(int clientId, String email, String firstName, String lastName) {}
} The structure of the code can be simplified as follows: The structure of the code can be simplified as follows: Here, you can see that the methods form an unbroken chain through which the data flow, like through a long, narrow intestine. The methods in the middle of this chain are responsible not only for the logic directly described in their body but also for the logic of the methods they call and their contracts (e.g., the need to handle specific errors). All methods preceding the invoked one inherit its entire complexity. For example, if kafkaTemplate.send has a side effect of sending an event, then the calling sendEvent method also acquires the same side effect. The sendEvent method also becomes responsible for serialization, including handling its errors. Testing individual parts of the code becomes more challenging because there is no way to test each part in isolation without using mocks. kafkaTemplate.send sendEvent sendEvent Option 2: Improved Version public class RegistrationService {

    private final ClientRepository clientRepository;
    private final KafkaTemplate<Object, Object> kafkaTemplate;
    private final ObjectMapper objectMapper;

    @SneakyThrows
    public void registerClient(RegistrationController.RegistrationRequest request) {
        var client = clientRepository.save(Client.builder()
                .email(request.email())
                .firstName(request.firstName())
                .lastName(request.lastName())
                .build());
        Message<String> message = mapToEventMessage(client);
        kafkaTemplate.send(message).get();
    }

    private Message<String> mapToEventMessage(Client client) throws JsonProcessingException {
        var event = RegistrationEvent.builder()
                .clientId(client.getId())
                .email(client.getEmail())
                .firstName(client.getFirstName())
                .lastName(client.getLastName())
                .build();
        return MessageBuilder
                .withPayload(objectMapper.writeValueAsString(event))
                .setHeader(KafkaHeaders.TOPIC, "topic-registration")
                .setHeader(KafkaHeaders.KEY, event.email)
                .build();
    }

    @Builder
    public record RegistrationEvent(int clientId, String email, String firstName, String lastName) {}
} public class RegistrationService {

    private final ClientRepository clientRepository;
    private final KafkaTemplate<Object, Object> kafkaTemplate;
    private final ObjectMapper objectMapper;

    @SneakyThrows
    public void registerClient(RegistrationController.RegistrationRequest request) {
        var client = clientRepository.save(Client.builder()
                .email(request.email())
                .firstName(request.firstName())
                .lastName(request.lastName())
                .build());
        Message<String> message = mapToEventMessage(client);
        kafkaTemplate.send(message).get();
    }

    private Message<String> mapToEventMessage(Client client) throws JsonProcessingException {
        var event = RegistrationEvent.builder()
                .clientId(client.getId())
                .email(client.getEmail())
                .firstName(client.getFirstName())
                .lastName(client.getLastName())
                .build();
        return MessageBuilder
                .withPayload(objectMapper.writeValueAsString(event))
                .setHeader(KafkaHeaders.TOPIC, "topic-registration")
                .setHeader(KafkaHeaders.KEY, event.email)
                .build();
    }

    @Builder
    public record RegistrationEvent(int clientId, String email, String firstName, String lastName) {}
} The diagram is shown below: Here, you can see that the sendEvent method is completely absent, and kafkaTemplate.send is responsible for sending the message. The entire process of constructing the message for Kafka has been moved to a separate mapToEventMessage method. sendEvent kafkaTemplate.send mapToEventMessage The mapToEventMessage method has no side effects, and its responsibility boundaries are clearly defined. Exceptions related to serialization and message sending are part of the individual methods' contracts and can be handled separately. mapToEventMessage The mapToEventMessage method is a pure function. When a function is deterministic and has no side effects, we call it a "pure" function. Pure functions are: mapToEventMessage Pure functions are: easier to read, easier to debug, easier to test, independent of the order in which they are called, simple to run in parallel. easier to read, easier to debug, easier to test, independent of the order in which they are called, simple to run in parallel. Recommendations I would suggest the following techniques that can help avoid such antipatterns in the code: Testing Trophy Approach One Pile Technique Test-Driven Development (TDD) Testing Trophy Approach One Pile Technique Test-Driven Development (TDD) All these techniques are closely related and complement each other. Testing Trophy This is an approach to test coverage that emphasizes integration tests, which verify the service's contract as a whole. Unit tests are used for individual functions that are difficult or costly to test through integration tests. I have described tests with this approach in my articles: Writing Effective Integration Tests in Spring: Organized Testing Strategies for HTTP Request Mocking , Improving Integration Test Transparency , Reliable Testing with Kafka: Isolation Techniques . Writing Effective Integration Tests in Spring: Organized Testing Strategies for HTTP Request Mocking Improving Integration Test Transparency Reliable Testing with Kafka: Isolation Techniques One Pile This technique is described in Kent Beck's book "Tidy First?" The main idea is that reading and understanding code is harder than writing it. If the code is broken into too many small parts, it may be helpful to first combine it into a whole to see the overall structure and logic, and then break it down again into more understandable pieces. In the context of this article, it is suggested not to break the code into methods until it ensures the fulfillment of the required contract. Test-Driven Development This approach allows separating the efforts of writing code to implement the contract and designing the code. We don't try to create a good design and write code that meets the requirements simultaneously, instead, we separate these tasks. The development process looks like this: The development process looks like this: Write tests for the service contract using the Testing Trophy approach. Write code in the One Pile style, ensuring that it fulfills the required contract. Don't worry about code design quality. Refactor the code. All the code is written, and we have a complete understanding of the implementation and potential bottlenecks. Write tests for the service contract using the Testing Trophy approach. Write code in the One Pile style, ensuring that it fulfills the required contract. Don't worry about code design quality. Refactor the code. All the code is written, and we have a complete understanding of the implementation and potential bottlenecks. Conclusion The article discusses an example of an antipattern that can lead to difficulties in maintaining and testing code. Approaches like Testing Trophy, One Pile, and Test-Driven Development allow you to structure your work in a way that prevents code from turning into an impenetrable labyrinth. By investing time in the proper organization of code, we lay the foundation for the long-term sustainability and ease of maintenance of our software products. Thank you for your attention to the article, and good luck in your quest for writing simple code!

Methodcentipede

Server Sent Events 101: A Guide

How To Study Source Code: Object Prototypes and Mixins in Express.js

সোর্স কোড কীভাবে অধ্যয়ন করবেন: Express.js-এ অবজেক্ট প্রোটোটাইপ এবং মিক্সিন

So studieren Sie Quellcode: Objektprototypen und Mixins in Express.js

Cómo estudiar el código fuente: prototipos de objetos y mixins en Express.js

Comment étudier le code source : prototypes d'objets et mixins dans Express.js

स्रोत कोड का अध्ययन कैसे करें: Express.js में ऑब्जेक्ट प्रोटोटाइप और मिक्सिन

ソースコードの学習方法: Express.js のオブジェクト プロトタイプとミックスイン

소스 코드 공부 방법: Express.js의 객체 프로토타입과 믹스인

Como estudar código-fonte: protótipos de objetos e mixins em Express.js

Как изучать исходный код: прототипы объектов и миксины в Express.js

Kaynak Kod Nasıl Çalışılır: Express.js'de Nesne Prototipleri ve Mixinler

Cách nghiên cứu mã nguồn: Nguyên mẫu đối tượng và Mixin trong Express.js

如何研究源代码：Express.js 中的对象原型和 Mixins

How to Create a Server Driven UI Engine for Flutter

ফ্লটারের জন্য কীভাবে একটি সার্ভার চালিত UI ইঞ্জিন তৈরি করবেন

So erstellen Sie eine servergesteuerte UI-Engine für Flutter

Cómo crear un motor de interfaz de usuario controlado por servidor para Flutter

Comment créer un moteur d'interface utilisateur piloté par serveur pour Flutter

फ़्लटर के लिए सर्वर संचालित UI इंजन कैसे बनाएं

Flutter 用のサーバー駆動型 UI エンジンを作成する方法

Flutter용 서버 기반 UI 엔진을 만드는 방법

Como criar um mecanismo de UI orientado a servidor para Flutter

Как создать серверный движок пользовательского интерфейса для Flutter

Flutter için Sunucu Odaklı UI Motoru Nasıl Oluşturulur

Cách tạo Công cụ giao diện người dùng điều khiển máy chủ cho Flutter

如何为 Flutter 创建服务器驱动的 UI 引擎

Hacking Backward and Forward-Compatible Application Releases

Stories, News & Mentions about EVENTENY

Eventeny’s Stories on HackerNoon