От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру

Хах, ну GraphQL и правда не для массового использования на мой взгляд 😀 в этом плане REST конечно более универсальный и устоявшийся

От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру

Здесь ответить затруднюсь, пожалуй, так как глубоко в ее внутренности не погружался – не возникало необходимости

Но когда дело дойдет до написания статьи про CI/CD пайп – погрузиться точно придется 🙂

От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру

не совсем понял вопрос) "куда ушли" в смысле "что с ними сейчас стало" или "что делают эти 300к строк, на что вы их потратили" ?😃

От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру

мне тоже schema-first больше симпатична 👌🏻 но тут накладывает свои ограничения библиотека, которая используется в кач-ве движка) мы выбрали caliban – а он code-first)

а вот про CI/CD-пайп статью написать - это идея интересная 🤔 спасибо, возьму на примету!

От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру

у нас code-first)

схемы подграфов собираются из пакета /model Bazel-рулом, заставляем апп подграфа распечатать свою схему

схему суперграфа собирает наша коммунальная тулза, она же и проверяет на валидность всю конструкцию

Процесс изменения не сложен: в коде добавляется/меняется модель -> скриптом пересобираются все подсхемы -> из них суперсхема) мержится все вместе: и классы, и схемы) после мержа триггерится CI-пересборка роутера, чтобы он подтянул новую схему и научился новым полям) потом автоматически выезжает в прод

для валидации внедрили CI-проверку, которая не даст вмержить изменения в /model без пересборки подсхем и суперсхемы, такое уже проходили на ранних этапах внедрения)

От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру

мы скорее преследовали цель жестко отселить домены друг от друга) так, чтобы эту границу было очень сложно (и не нужно) перелезать