К сожалению, я не обладаю тут полноценной информацией, так как этим занимается другая команда. Но могу предположить, что Яндекс, как большая IT-компании, делает свое решение по нескольким причинам:
Контроль над технологиями и данными.
Уникальные потребности: Разработка собственных продуктов позволяет адаптировать программное обеспечение под конкретные требования и бизнес-процессы компании.
Сложность интеграции: Разработка собственного решения может обеспечить более гладкую интеграцию с текущей системой.
Замечательный вопрос, который достоин отдельной статьи. Попробую ответить на него максимально кратко, но ёмко.
В Яндексе разрабатывают свою TMS (Translation Management System). Этим занимается отдельная команда.
Внутри Яндекса применяются разные CAT tools (Computer-Assisted Translation):
собственные разработки компании;
внешние готовые решения. В данный момент в Фантехе мы используем одно из таких внешних решений из-за его совместимости с ICU Message Format. Внутренние инструменты планируют поддержку ICU, и по завершении этого этапа мы планируем переход на внутреннее решение.
По поводу первого вопроса о "показе примера использования сообщений (с этими длинными ID) посреди другого кода", вы правы: скриншот React-компонента в статье — это и есть пример.
Относительно вопроса о контекстуальных подсказках вроде "вот этих текстов не стало" или "данная строка похожа на вот эту, которая уже переведена", в самом проекте такого инструмента у нас нет. Но он и не требуется, поскольку подобный функционал внедрен во многих CAT tools (в том числе в тот, который мы используем) через так называемую память переводов.
Что касается последнего вопроса о переиспользовании и согласовании переводов между проектами, то тут ответ такой. Мы рекомендуем в таких проектах использовать CAT tool с общей памятью переводов. Это значительно упрощает жизнь локализатора при переводе повторяющихся ключей.
Что касается самого процесса разработки, то мы настоятельно рекомендуем избегать переиспользования ключей между разными компонентами и страницами (особенно между разными проектами). Даже если текст в этих ключах одинаковый, все равно рекомендуется использовать два разных ключа. Это позволит избежать неожиданных изменений не в тех местах.
У нас были следующие проблемы с производительностью:
медленный старт приложения
медленные запросы
Для решения проблемы медленного старта приложения мы:
заменили компилятор по умолчанию на экспериментальный GraalVM, и в результате сократили время прогрева с двух минут до 30 секунд
добавили Python-скрипт для прогрева компилятора: в течение минуты мы отправляли запросы, похожие на реальные, и только после этого делали приложение доступным для внешнего мира. Такое решение полностью сняло все проблемы старта.
Для решения проблем медленных запросов мы:
добавили Redis для кэширования сложных в обработке запросов по ключу целиком.
Переписали код так, чтобы total вычислялся только по прямому запросу пользователя. За счет этого мы сократили количество запросов для подсчёта размера коллекции в БД в четыре раза.
Для оптимизации проблем N+1 запросов использовали подход с даталоадерами — это специальные классы, позволяющие объединять запросы объектов по ID и отправлять их в источники данных батчами.
Часто вижу этот аргумент, но почему нельзя выносить такие запросы в условный /v1/optimized/events/*?
В этом случае вам придется писать всё новые и новые методы под каждое требование клиентов. Систему в итоге станет сложно поддерживать и развивать. А главное, что вы становитесь заложником клиентов, а их может быть очень много. При этом каждое изменение будет требовать разработки, тестирования и выкладки в продакшн.
Каков по вашему критерий когда стоит перестать дописывать REST и переходить на GraphQL?
Все сильно зависит то того, сколько различных типов клиентов будет/есть у вашего REST и насколько часто они просят вас делать "специальные" методы для их нужд. Еще стоит обратить внимание, что существует довольно много клиентских реализаций для работы с GraphQL. И, согласно нашему опыту, общаться с API через них сильно проще, чем писать кастомный код про REST методы.
Вы имеете в виду на сервер будет отправлен только один запрос, или GraphQL может действительно собирать запросы к базе в один?
Да, все верно. Технология GraphQL позволяет на сервере собирать сложные ответы в одном запросе. Работает это следующим образом. У вас в проекте может быть несколько простых REST микросервисов, которые должны реализовывать следующие типы методы:
получить объект по ID;
получить список объектов по списку ID;
отыскать список ID по заданным критериям.
Далее в самом GraphQL применяется подход с даталоадерами, специальными классами, которые позволяют объединять запросы объектов по ID и отправлять их в источники данных батчами.
К сожалению, я не обладаю тут полноценной информацией, так как этим занимается другая команда. Но могу предположить, что Яндекс, как большая IT-компании, делает свое решение по нескольким причинам:
Контроль над технологиями и данными.
Уникальные потребности: Разработка собственных продуктов позволяет адаптировать программное обеспечение под конкретные требования и бизнес-процессы компании.
Сложность интеграции: Разработка собственного решения может обеспечить более гладкую интеграцию с текущей системой.
Экономия в долгосрочной перспективе.
Замечательный вопрос, который достоин отдельной статьи. Попробую ответить на него максимально кратко, но ёмко.
В Яндексе разрабатывают свою TMS (Translation Management System). Этим занимается отдельная команда.
Внутри Яндекса применяются разные CAT tools (Computer-Assisted Translation):
собственные разработки компании;
внешние готовые решения. В данный момент в Фантехе мы используем одно из таких внешних решений из-за его совместимости с ICU Message Format. Внутренние инструменты планируют поддержку ICU, и по завершении этого этапа мы планируем переход на внутреннее решение.
Не могли бы вы подробнее рассказать о том, что вы имеете в виду под "искать по буквам" в контексте музыкального поиска?
По поводу первого вопроса о "показе примера использования сообщений (с этими длинными ID) посреди другого кода", вы правы: скриншот React-компонента в статье — это и есть пример.
Относительно вопроса о контекстуальных подсказках вроде "вот этих текстов не стало" или "данная строка похожа на вот эту, которая уже переведена", в самом проекте такого инструмента у нас нет. Но он и не требуется, поскольку подобный функционал внедрен во многих CAT tools (в том числе в тот, который мы используем) через так называемую память переводов.
Что касается последнего вопроса о переиспользовании и согласовании переводов между проектами, то тут ответ такой. Мы рекомендуем в таких проектах использовать CAT tool с общей памятью переводов. Это значительно упрощает жизнь локализатора при переводе повторяющихся ключей.
Что касается самого процесса разработки, то мы настоятельно рекомендуем избегать переиспользования ключей между разными компонентами и страницами (особенно между разными проектами). Даже если текст в этих ключах одинаковый, все равно рекомендуется использовать два разных ключа. Это позволит избежать неожиданных изменений не в тех местах.
Про какую верстку идет речь? Уточните, пожалуйста, что именно вас интересует в верстке.
Нет, мы для сборки используем ya make. ya make — это система сборки общего назначения для Аркадии - монорепозитория компании Яндекс.
вот тут ответили https://habr.com/ru/company/yandex/blog/566700/#comment_23240300
У нас были следующие проблемы с производительностью:
медленный старт приложения
медленные запросы
Для решения проблемы медленного старта приложения мы:
заменили компилятор по умолчанию на экспериментальный GraalVM, и в результате сократили время прогрева с двух минут до 30 секунд
добавили Python-скрипт для прогрева компилятора: в течение минуты мы отправляли запросы, похожие на реальные, и только после этого делали приложение доступным для внешнего мира. Такое решение полностью сняло все проблемы старта.
Для решения проблем медленных запросов мы:
добавили Redis для кэширования сложных в обработке запросов по ключу целиком.
Переписали код так, чтобы total вычислялся только по прямому запросу пользователя. За счет этого мы сократили количество запросов для подсчёта размера коллекции в БД в четыре раза.
Для оптимизации проблем N+1 запросов использовали подход с даталоадерами — это специальные классы, позволяющие объединять запросы объектов по ID и отправлять их в источники данных батчами.
Мы выбрали GraphQL, так как эта технология лучше остальных отвечает всем нашим требованиям. А именно:
Позволяет клиенту точно указать, какие данные ему нужны.
Облегчает агрегацию данных из нескольких источников.
Использует систему типов для описания данных.
Имеет множество клиентских и серверных реализаций GraphQL почти во всех популярных языках программирования.
Имеет большую комьюнити и хорошую поддержку.
В этом случае вам придется писать всё новые и новые методы под каждое требование клиентов. Систему в итоге станет сложно поддерживать и развивать. А главное, что вы становитесь заложником клиентов, а их может быть очень много. При этом каждое изменение будет требовать разработки, тестирования и выкладки в продакшн.
Все сильно зависит то того, сколько различных типов клиентов будет/есть у вашего REST и насколько часто они просят вас делать "специальные" методы для их нужд. Еще стоит обратить внимание, что существует довольно много клиентских реализаций для работы с GraphQL. И, согласно нашему опыту, общаться с API через них сильно проще, чем писать кастомный код про REST методы.
Да, все верно. Технология GraphQL позволяет на сервере собирать сложные ответы в одном запросе. Работает это следующим образом. У вас в проекте может быть несколько простых REST микросервисов, которые должны реализовывать следующие типы методы:
получить объект по ID;
получить список объектов по списку ID;
отыскать список ID по заданным критериям.
Далее в самом GraphQL применяется подход с даталоадерами, специальными классами, которые позволяют объединять запросы объектов по ID и отправлять их в источники данных батчами.