Однажды я на вычитку получил такой перевод:
«Необходимость обработки больших объемов связанных данных заставила специалистов отказаться от стандартной архитектуры REST API и перейти к графовому представлению данных».
Звучит складно. А теперь — оригинал:
«This led Facebook (now Meta) to reevaluate the computational demands of REST APIs when retrieving high volumes of graph-like data over the network».
И что же здесь не так? А всё не так. Этот перевод — прекрасный пример того, как можно исказить смысл, не сделав ни одной грамматической ошибки.
Давайте разбираться. Это не для того, чтобы кого-то обидеть, а для того, чтобы вы так не делали.
Ошибка №1: «Обработка» вместо «получения»
Переводчик увидел retrieving и почему-то решил, что это «обработка». Справедливости ради отмечу, что определенные основания у него всё же были. Рядом стояли слова computational demands (требования к вычислениям) и high volumes of data (большие объемы данных) — очень легко подумать о том, что здесь что-то про обработку. И всё таки, это не она.
Здесь retrieving — это получение или извлечение данных по сети.
Чтобы лучше понять, давайте представим, что мобильное приложение — это вы, а сервер — большой советский универмаг (или современный супермаркет). Как вам с ним взаимодействовать? В данном отрывке речь про два варианта взаимодействия: REST API и GraphQL.
- REST API — здесь вы будете бегать за каждым товаром бегали в соответствующий отдел. В молочный — за кефиром, в хлебный — за батоном, в мясной — за колбасой. Иными словами, много беготни и отдельных «запросов».
- GraphQL — здесь вы на входе даете один подробный список кассиру, и вам выносят одну корзину со всем, что вы просили. Один поход, один «запрос».
Так вот проблема простигосподи Facebook-а была не в обработке данных в универмаге-сервере, в неэффективности их получения клиентом. Мобильное приложение делало слишком много запросов по сети, чтобы собрать все нужные данные (сначала ваш профиль, потом посты друзей, потом лайки к постам и т. д.). Страшно неэффективно, особенно при плохом интернете. Оригинал говорит именно об этом: retrieving ... over the network — получение ... по сети.
Ошибка №2: «Отказаться» вместо «пересмотреть»
В оригинале стоит слово reevaluate. Это не «отказаться», а «пересмотреть», «переоценить».
«Отказаться» — это весьма радикально. Выбросить и забыть? Нет, именно «пересмотреть».
Facebook не «отказался» от REST. Они просто поняли, что для их конкретной задачи — отдавать мобильным клиентам сложные, связанные данные — этот инструмент подходит плохо. Они пересмотрели его возможности и создали более подходящий инструмент, GraphQL.
То есть REST по-прежнему жив, здоров и используется для тысяч других задач Facebook, где он отлично справляется. Не конкретно для описываемой задачи он оказался слабоват.
Может возникнуть скептический вопрос, и где используется REST на Facebook? Ну, например, там, где вам нужно получить один конкретный ресурс (например, пост по его ID) или выполнить простое действие. Здесь REST часто оказывается проще и легче в реализации, чем GraphQL.
Ошибка №3: «Перейти к графовому представлению данных»
Это самая тонкая ошибка. Переводчик возможно решил, что раз появился GraphQL, значит, компания «перешла к графовому представлению». Но данные в социальной сети изначально представляют собой граф.
Что такое граф в этом контексте? Это не диаграмма и не графики/диаграммы как в Excel. Это математическая модель: есть узлы (объекты: вы, ваш друг, фотография) и есть связи между ними (отношения: «дружит с», «лайкнул», «автор фото»). Все данные в соцсети образуют гигантский, сложный граф.
Проблема была не в данных, а в том, как их запрашивать. REST API не очень хорошо умеет работать с графами. Чтобы получить данные о вас, ваших друзьях и их фотографиях, ему нужно сделать много отдельных запросов. А GraphQL — это язык запросов, созданный специально для графов. Он позволяет одним запросом «вырезать» из огромного графа данных на сервере именно тот кусочек, который нужен клиенту.
************
В исправленном переводе нужно было отразить эти нюансы. То есть: не «обработка», а получение; не «отказаться», а пересмотреть; не «перейти к представлению», а осознать проблему получения уже существующих графовых данных.
В моем случае получилось так:
Эта работа заставила специалистов компании пересмотреть возможности REST API, когда требовалось получать по сети большие объёмы данных со сложными взаимосвязями.
Надеюсь, было полезно. Спасибо за внимание.