Выглядит очень круто. Есть вопрос по технологиям: раз уж выбрали Istio для service mesh внутри, кажется логично было бы взять их же Ingress для входящего трафика. Почему выбрали Nginx?

Добрый день. Батчинг работает в рамках одного запроса. Если вы вызовете movieBatch несколько раз в одном запросе с разными id, в БД уйдёт только один запрос со списком id, а не несколько по каждому отдельному id. Пример запроса в котором будет работать батчинг:

query {
  m1:movieBatch(id:1) {
    id
    name
  }
  m2:movieBatch(id:2) {
    id 
    name
  }
  m3:movieBatch(id:3) {
  	id
    name
  }
}

Наша система гораздо сложнее чем просто получение данных из MongoDB. БД вообще никакого значения тут не имеет, в примере на github вместо БД текстовый файл. И именно в объединении данных из кучи разных источников проявляются сильные стороны GraphQL

Последний раз, как мне кажется, стандарт OData обновлялся в 2016 году и у него не очень много сторонников. Он не очень удобный и кажется не совсем предназначен для того что нам надо. OData как-бы предоставляет клиенту доступ к базе данных через веб-запросы, а GraphQL –– это скорее механизм объединения разных источников данных в едином графе.

По спецификации GraphQL в ответе на запрос есть следующие поля: data, для собственно ответа, errors для ошибок обработки внутренних запросов и extensions для служебной информации. Туда например складывается информация по трейсингу работы каждого подзапроса, если доступно. Мне кажется это самое лучшее место для того чтобы там передавать метаданные которые вас нужны для обработки ответа.

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

mutation {
  createReview(episode: {}, review: {}) {
  	stars
    commentary
  }
}

то есть по сути тот же запрос как и в JSON-RPC, только вместо reviews.add мутация createReview. Можно договорённостями это решить, пусть называется не createReview а addReview, тогда тоже помнить ничего не надо.

Про обвязку я имел ввиду что часть запроса с mutation и именем запроса можно вынести в общий код (если договориться о нейминге мутаций заранее). Из ответа можно только id всегда возвращать например, тогда и часть с query уйдёт в общую библиотеку, останется только параметры подсовывать верные.

Мутации выглядят громоздко, тут должен согласиться. Но во-первых большинство клиентов будут использовать фреймворки (Apollo для js по словам наших фронтенд разработчиков очень удобен для разработки приложений на react например), во-вторых даже без фреймворков в итоге всё равно всё сводится к написанию объектов для запросов в JSON, так же как в JSON-RPC по сути. Мутации потребуют небольшую обвязку, которая будет написана в одном классе-построителе запросов

Нет, SELECT * мы не делаем. У нас MongoDB, мы пользуемся проекциями, но если перекладывать пример на SQL DB, то у нас два случая: в одном мы делаем SELECT Id, Name, а во втором SELECT Id, Name, Birthday, HairColor, Height,...

Это в любом случае ответственность слоя доступа к данным, который не должен позволять делать неоптимальные запросы, хоть с ORM, хоть без, а GraphQL здесь только вспомогательный инструмент. GraphQL не должен отдавать лишние данные клиенту, это его задача. А вытащат ли их из базы ему всё равно.

Нет, мы не компилим граалем, используем только JIT в рантайме. И даже это уже даёт прирост скорости старта. Хотим сделать эксперимент с Native Image, но пока не было возможности.

Фронтенд всё-таки не изолированно от бэкенда работает и мы можем оптимизировать запросы точечно под нашего клиента и под нашу предметную модель. Условно мы так же как в REST имеем две проекции для запросов объектов из базы: короткий списочный формат объекта и полный, если запрос идёт по id. При этом важное отличие –– запросы дочерних объектов. Если у User мы не запросим поле friends, то и запроса в базу не будет. Пример с count тоже это показывает.

А на уровне запроса выборку отдельных полей мы не делаем, потому что наверняка знаем, что клиент запросит все поля. Вообще такую выборку сделать несложно, даже есть биндинги к популярным ORM но мы не получим в этой оптимизации хоть какой-то выгоды, поэтому не разрабатываем эту фичу.

Про это уже очень много говорили коллеги в статье про систему контроля версий. В целом монорепозиторий позволяет нам эффективно бороться с велосипедами внутри компании, даёт зависимость от библиотек по коду, то есть у нас всегда самые последние версии внутренних библиотек, а единая система сборки позволяет одной командой собрать и java код и C++ либы для биндингов например.

Само переписывание системы as is заняло 2,5 месяца. С тестированием и исправлением базовых проблем производительности получается 4 месяца: с февраля по июнь.

Собственно переписывание и открыло для нас возможности оптимизации работы с БД, параллелизации запросов, дальнейшей оптимизации производительности.

Дополнительно стоит отметить что результирующее API уже послужило примером для других сервисов при создании собственных API Gateway, так что в любом случае время было потрачено не зря)

(удалено)

Мы используем GraalVM как замену С2 в проде, включаем соответственно просто через флаги

 -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler

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

Что касается скорости работы запроса, это только результат первого запуска. Мы в первую очередь стремились воспроизвести схему как есть и быстро запуститься, оптимизацию оставили на потом. Как видно из последней части статьи, дальше, благодаря правильным подходам к работе с запросами, мы смогли ускорить работу страницы ещё вдвое