Внутри: 00:00 - Интро 00:20 - Вступление 00:40 - Живой пример из системы Talantix 01:14 - Проблемы REST API 03:56 - Что такое GraphQL? 04:57 - Пример GraphQL-схемы и запроса к серверу 05:50 - Сравнение GraphQL и REST 06:37 - Особенности миграции на GraphQL в hh.ru 07:57 - Плюсы перехода на GraphQL 08:42 - Подводные камни 10:35 - Заключение
С бэкендом на джаве вы не распробовали самую суть - граф нужен не только и не столько для фронта, сколько для общения подсистем бэкенда . CQRS на стероидах 😂 А подача и харизма топ, спасибо за живое интересное изложение вашей практики 🧘
имхо, применимо для каких-то сложных аналитических страниц со статистикой и графиками. для обычных вещей лучше API. чем больше зоопарка в технологиях проекта, тем хуже. лучше меньше всякой всячины использовать.
Как проектируете изменения в API? Code-first сильно форсит сразу писать реализацию - что если хочется сначала спроектировать и запустить обновленный API, запустить его для возможности фронтенду работать с ним прямо сейчас, а реализацию пилить в процессе?
Привет! Спасибо за хороший вопрос. У нас на клиенте есть механизм стабов, можем с лёгкостью подменять ответы к нашему графкл клиенту. При проектировании новой сущности мы, первым делом, составляем контракт вместе с бэкендом, где описываем query для конкретной задачи. Что позволяет на фронте 1 к 1 застабить данные и начать раньше разработку не зависимо от бэкенда. Порой бэк быстрее успевает сделать контракт, где мы уже просто выкачиваем схему ;)
обычно на сервере готовишь данные для клиента, например прописываешь на сервере getClients и он вернет то что написано на сервере. А GraphQL прописывает клиент то есть в теле прописывается только нужные данные клиенту например имена клиентов или только их номера. Клиент готовит данные.
Тут важно упомянуть, что мы внедряли graphql в уже существующий проект, который целиком написан на java - банально легче и сильно дешевле было поднять графкл в уже существующих сервисах. Но хоть и мир java скорее на догоняющей позиции в призме графкля, не всё так уж и плохо, решения prod-ready. За всё время мы столкнулись с единственной проблемой из-за небогатства поддержки - в java только одно code-first решение, которое перестало ментейниться, хотя нам оно зашло
А если параметров станет больше одного? Например если появится мобильная версия приложения, версионирование апишки и проч? Идет постепенное создание велосипеда-аналога graphql Ну и тестирование такого огромного роута станет сущим кошмаром. Надо добавить одно поле в один микроэндпоинт и надо проверять, что другие не поломались
@@Artem-v7d В GraphQL обязательно все запросы POST? Нельзя ли хотя бы разделять на мутирующие и не мутирующие, отправлять мутирующие как POST а не мутирующие как GET?
@@sergeypodunov2606 "В GraphQL обязательно все запросы POST?" - вовсе необязательно! Вполне можно и GET использовать, передавая query-параметром сам запрос. Просто в теле POST-метода чуть удобнее передавать потенциально большой graphql-запрос, не боясь выйти за пределы максимальной длины query-параметра, например, в случае GET-запроса. "Нельзя ли хотя бы разделять на мутирующие и не мутирующие" - технически можно в принципе, но зачем? Если ради разделения запросов на идемпотентные и неидемпотентные, то это сработает только для не мутирующих методов, однако идемпотентные методы изменения/удаления сущности мы не сможем отличить от неидемпотентного метода создания - в graphql-мире это просто мутация =/. А это знание может понадобиться, например, для ретраев идемпотентных запросов, если возникла условная проблема с сетью. Мы ещё не внедряли мутации и поэтому такую проблему ещё не решали, но сходу подумал о возможности прокидывания спец. хедера, указывающего идемпотентен запрос или нет. Но возможно есть ещё более изящные решения :)
