Григорий Мирсаитов - Вложенные сущности по требованию в API на Spring Data JPA
ฝัง
- เผยแพร่เมื่อ 20 ต.ค. 2024
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
Скачать презентацию с сайта JPoint - jrg.su/LnWIEO
Во время разработки часто требуется создавать API, которые раскрывают взаимосвязанные сущности. Например, заказ и пользователь, который сделал заказ. Клиенты API зачастую сами не знают, что им надо получить в конкретной ситуации и хотели бы иметь механизм для динамического формирования запросов требуемой информации.
Спикер столкнулся с этой задачей при переходе от OData к возможностям экосистемы Spring. Во время доклада он показал, как собрать свой обработчик запросов на основе расширения Spring Data JPA. Рассмотрели что предоставляют Spring Data REST, Spring GraphQL и обсудил их ограничения. Исследовал, что внутри и сравнили с получившимся решением.
Рассказал о проблемах и путях решения, с которыми встретились при реализации.
Становится страшно, как подумаешь, сколько человеко-часов-денег, украли эти ребята у бизнеса в котором работают. Проект - это полное фиаско ИТ менеджмента, который позволил такой треш в проекте.
Не понял, почему?
Нет ничего лучше явной OpenAPI спецификации с четко определенными границами и DTO по который генерится код на бэке и фронте.
"как вы это тестируете" - "ну мы кидаем ошибку, если запрос неверный" 😁
Видимо было так - был SAP, который позволял делать expose своих данных с помощью OData (Odata как раз позволяет использовать эти expand параметры), был написан ui, который потреблял Odata endpoints. Пришло видимо время от Sap отказаться, а UI переписывать не захотелось. Так вот, если ui переписывать не хотелось, то правильное направление было использование Gateway, в функции которого, кроме прочего, входит трансформация протокола. Пусть бы этот гейтвей принимал запрос по старинке, но трансформировал бы его в вызов статического Rest endpoint. Перемудрили вы конечно здесь очень сильно.Требования к АПИ быть динамическим и работать с expand параметрами протекло по всем слоям вашего приложения, что привело реально к ошибке.
21:15 - А как вообще разрезание строк может повлиять на производительность целого запроса? Это как так нужно резать строки или какое их должно быть количество, чтобы это отражалось на производительности?
Какая-то фантастика...
Пздц, какой-то кромешный ужас. Соболезную разрабам, которым с этим работать.
Хорошо, что спикер сам понимает проблему излишнего "либерализма" в запросах к БД. Идея в конвертерах самостоятельно вытягивать данные не очень понятна. Разрывается роль конвертера и сервиса. По хорошему это ответственность именно сервиса дать данные на вход в конвертер, а тот должен быть тупой молотилкой. Но тут уже сколько людей, столько и мнений. Холиварная тема, да и в целом работает и так и эдак. Но мне такой подход не очень нравится тем, что конвертеры начинают обрастать бизнес логикой. Но возможно в данном случае он и оправдан. Как-то мне достался в наследство проект, где тоже куча догики творилась внутри конвертеров, всё это неявно через функциональные интерфейсы вызывалось. Было довольно неудобно отслеживать, что и откуда вызывается и т.д.
Не понятно зачем это извращение, которое невозможно будет поддерживать