Information
- Rating
- Does not participate
- Location
- Минск, Минская обл., Беларусь
- Date of birth
- Registered
- Activity
Specialization
Backend Developer
Middle
Git
OOP
Java
Java Spring Framework
Spring Boot
High-loaded systems
Elasticsearch
Apache Kafka
Kubernetes
Redis
Все конечно круто. Вот только обещанный код было-стало что-то я плохо разглядел. А так конечно, не хватает картинок и графиков, где можно было увидеть перформанс до и после, частота проблем до и после, и самое главное как это отразилось на конечных разработчиках, стало ли им удобней? А то может впилили один велосипед вместо другого, без звёздочки и с колесом поперек рамы, а разрабам сказали, что это круче. Но спасибо за введение в архитектурный менеджмент. Надеюсь ваш рефакторинг улучшит Яндекс.Музыку в Яндекс.Авто медиасистеме, бо она там работает на отколебись - искать можно только через Алису, треки слетают, ui поплыл и иногда не загружается. Главное чтобы политики не угробили компанию.
Даже очень интересно. Потому что в крупном проекте, без джойна очень тяжело. Очень буду ждать статью по этой теме.
Поддерживаю. Сам очень часто сталкиваюсь с ситуациями, когда нужно агрегировать данные из разных сервисов. Но ещё добавлю, что есть ещё проблема создания фильтров для нескольких сервисов одновременно. Иногда возникает ситуация, что нужно выгребсти много лишних сущностей из разных сервисов, чтобы нормально их отсортировать. Одно из решений джойна данных - создания прослойки в виде сервиса-агрегатора. Но у него есть плюсы и минусы, и вдобавок увеличивает количество запросов на +1, хоть он и внутри кластера. Но очень интересно, как у других решается эта популярная проблема
На мой взгляд эта проблема связана как минимум с функционалом генерации класса на лету (в рантайме). И соответственно метод createResource может сгенерировать класс реализующий интерфейсы Resource и List<? extends Resource>. И по идее это вполне логично и допустимо. А это известно только в рантайме.