Search
Write a publication
Pull to refresh
4
0.2
Кирилл Романов @Djaler

Сеньор-помидор

Send message

Это какая-то русская народная забава - заставить LLM считать числа и удивляться результату?

Идентификация то там описана - с помощью correlationId в хедере. Вот только она никак не поможет, если ответ просто придет в другой инстанс.

При асинхронной обработке - разницы нет. Но тут то смысл в том, что конкретный инстанс начинает "синхронно" ожидать ответ после запроса:

NotificationDispatchResponse dispatch(NotificationDispatchRequest notificationDispatchRequest) {
        String requestTopic = synchronousKafkaProperties.requestTopic();
        ProducerRecord<String, NotificationDispatchRequest> producerRecord = new ProducerRecord<>(requestTopic, notificationDispatchRequest);

        var requestReplyFuture = replyingKafkaTemplate.sendAndReceive(producerRecord);
        return requestReplyFuture.get().value();
    }

Вот мне тоже кажется, что при наличии нескольких экземпляров приложения это так просто не заработает, потому что обработка разных партиций топика с ответом вполне себе окажется на разных инстансах. Не обязательно на тех, откуда отправляли запрос.

В итоге пример классный, но как будто бесполезный в реальной жизни.

Мы логи на сервере пишем после десериализации запросов и до сериализации ответов

А ещё логи бывают вне приложения. Например, на балансерах/гейтвеях.

Для таких вещей есть дев и стейдж окружения, где минификации нет.

У вас замена имен у свойств при сериализации вшита в описание самих структур. Каким образом это отключается в разных окружениях?

Кажется, вам нужно было просто включить сжатие ответов и всё https://docs.spring.io/spring-boot/how-to/webserver.html#howto.webserver.enable-response-compression

А зачем нам сохранять читаемость Json? Для кого?

Для удобного дебага, чтения логов и т.д.

Статья про то, что в Kotlin Serialization есть аннотация, позволяющая управлять именем сериализуемого свойства? Как и у любой другой библиотеки для работы с JSON?

Такая статья в твит поместилась бы, мощно

Так в вашем примере со слоями тот же MockBean используется.

Я в своих проектах выработал простое решение - везде применяются SpyBean, и объявляются они один раз в базовом классе. Там где нужно - им можно задать поведение, как мокам. Где не нужно - они будут вести себя как настоящие бины. И контекст при этом будет создан только один раз.

Интеграционный тест с использованием @SpringBootTest нужен как минимум для проверки того, что контекст поднимается и нет никаких ошибок в конфигурации.

И тут уже встает вопрос, а если мы всё равно будем поднимать полный контекст, зачем нам дополнительно ещё поднимать отдельные слои контекста?

Настолько не официальный, что буквально живет на домене vuejs.org? https://pinia.vuejs.org/
Это давно официальная рекомендация, Vuex мёртв

Так люди хотят именно Postgres в браузере, а не какую-то другую поделку, которая даже не про SQL.

ISO-8601 только. А то у вас про турбинное масло)

IncidentResponse :)
Чаще всего не нужно смешивать объекты запроса и ответа

дело не столько в том, что возвращаются какие-то лишние данные, а в том - что так внешний контракт зависит от внутренних нюансов реализации (того как мы маппим сущность на хранилище и т.д.)

Id может быть и в DTO, а выставлять наружу сущность базы - антипаттерн.

Вероятно, стоит упомянуть о том, что такие манипуляции приводят к необходимости заново поднимать контекст.

Можно тогда ещё и colima добавить в тест?

https://github.com/abiosoft/colima

А почему статья в хабе $mol находится?

1
23 ...

Information

Rating
5,179-th
Date of birth
Registered
Activity

Specialization

Backend Developer
Lead
Java
Kotlin
Java Spring Framework
Spring Boot
PostgreSQL