Григорий Мирсаитов - Вложенные сущности по требованию в API на Spring Data JPA

[@goranmichlovich8630]

Становится страшно, как подумаешь, сколько человеко-часов-денег, украли эти ребята у бизнеса в котором работают. Проект - это полное фиаско ИТ менеджмента, который позволил такой треш в проекте.

[@bbrother92]

Не понял, почему?

[@vladiksun1985]

Нет ничего лучше явной OpenAPI спецификации с четко определенными границами и DTO по который генерится код на бэке и фронте.

[@dmitrysmirnov5575]

Видимо было так - был SAP, который позволял делать expose своих данных с помощью OData (Odata как раз позволяет использовать эти expand параметры), был написан ui, который потреблял Odata endpoints. Пришло видимо время от Sap отказаться, а UI переписывать не захотелось. Так вот, если ui переписывать не хотелось, то правильное направление было использование Gateway, в функции которого, кроме прочего, входит трансформация протокола. Пусть бы этот гейтвей принимал запрос по старинке, но трансформировал бы его в вызов статического Rest endpoint. Перемудрили вы конечно здесь очень сильно.Требования к АПИ быть динамическим и работать с expand параметрами протекло по всем слоям вашего приложения, что привело реально к ошибке.

[@anyman777]

"как вы это тестируете" - "ну мы кидаем ошибку, если запрос неверный" 😁

[@GrishinMisha]

21:15 - А как вообще разрезание строк может повлиять на производительность целого запроса? Это как так нужно резать строки или какое их должно быть количество, чтобы это отражалось на производительности?

[@aiwprton805]

Ужасная архитектура. По сути на фронте была реализована вся бизнес-логика, а бэкенд превратили в сложный конвертер, который должен разбирать любые запросы фронта, адресовать их базе, делать постобработку опять же по параметрам фронта и отдавать фронту. Явный пример того, как делать не надо. Досмотрел до половины, дальше не смог. Надеюсь, они всё это сожгли и переписали нормально.

[@RickDkkrd]

Пздц, какой-то кромешный ужас. Соболезную разрабам, которым с этим работать.

[@PavelIvanovskii]

Какая-то фантастика...

[@МихаилБратухин]

Хорошо, что спикер сам понимает проблему излишнего "либерализма" в запросах к БД. Идея в конвертерах самостоятельно вытягивать данные не очень понятна. Разрывается роль конвертера и сервиса. По хорошему это ответственность именно сервиса дать данные на вход в конвертер, а тот должен быть тупой молотилкой. Но тут уже сколько людей, столько и мнений. Холиварная тема, да и в целом работает и так и эдак. Но мне такой подход не очень нравится тем, что конвертеры начинают обрастать бизнес логикой. Но возможно в данном случае он и оправдан. Как-то мне достался в наследство проект, где тоже куча догики творилась внутри конвертеров, всё это неявно через функциональные интерфейсы вызывалось. Было довольно неудобно отслеживать, что и откуда вызывается и т.д.

[@volshebniyfonar]

Не понятно зачем это извращение, которое невозможно будет поддерживать