Я люблю, когда переводчик избавляет читателя от необходимости читать многословность американских авторов. По этой причине я даже внутренне слегка порадовался, как переводчик уплотнил это предложение из книги по стилям API:
The GraphQL service defines the interface, which can interact with any backend (database, legacy system, or external APIs), and the GraphQL client utilizes this interface to interact with the service.
В варианте переводчика перевод получился таким:
Интерфейс API GraphQL позволяет клиентам взаимодействовать c любым бэкендом (базой данных, legacy-системой или внешними API).
Однако меня остановило то, что у слова define тут получалась какая-то «размытая» роль. Я не понимал, стоит ли за этим глаголом что-то технически существенное, или он тут просто для красоты поставлен, как это англоязычные авторы, бывает, любят делать со всякими фразами типа strategy или approach. Пришлось останавливаться и закапываться в матчасть.
Отмечу, само слово define — один из неудобнейших для перевода глаголов в том смысле, что, даже если он поставлен в тексте не просто так, то нужно четко понимать — он тут «определяет» в смысле «описывает, дает словарное определение» или в смысле «устанавливает правила, требования, критерии, настройки»?
Для того чтобы понятны были дальнейшие пояснения, необходимо немного проговорить, что такое GraphQL как стиль API.
API: GraphQL vs REST
Вообще, в силу профдеформации мне всё время кажется, что идею API знает каждый школьник — но почти на каждом курсе по ИТ-переводу, который я веду, это понятие встречается в текстах и набирается до половины группы тех, кто даже такую аббревиатуру не слышал и уж тем более не понимает, зачем она нужна.
Самый простейший пример API (application programming interface, дословно «программируемый интерфейс приложения») — это пульт от телевизора.
Вы с этого пульта сможете общаться только с телевизором. Вы не сможете включить с телевизионного пульта свет, чайник, микроволновку или пылесос — для них, вероятно, будут другие пульты. Но на пульте от телевизора есть свой набор команд, которые понятны телевизору, и телевизор знает, что свои команды он будет слушать/считывать только со своего пульта (а не с пульта от пылесоса).
Вот эта точка обмена командами в установленной форме и ответ/реакция устройства в установленной форме — это обмен данными по API. API — это окошко, через которое передаются команды и через которое возвращается результат.
Похожая схема в ресторане: для того, чтобы заказать блюдо, вам не надо идти на кухню, вам нужно дождаться официанта (API), который даст вам меню (API-спецификацию), и вы по ней закажете блюда (только те, которые там указаны, а не, например, уши африканского слона с гречневой кашей, которых в меню нету).
Официант примет ваши команды и унесет их на кухню (сервер), где их обработают, и результат вам вернут на стол (например, в браузер).
Надеюсь, с сутью API стало немного понятнее.
Теперь представим, что мы идем в ресторан быстрого питания, а там такое дежурное меню:
- Бургер-комбо: бургер + картошка + кола.
- Пицца-комбо: пицца + фанта + кетчуп.
- Салат-комбо: цезарь + хлеб + селедка под шубой.
Если вам захочется цезарь, пиццу и колу, то придется заказывать все три блюда, причем по очереди, потому что блюда не дробятся, все стандартизовано и шаблонизировано. И не дай бог, вам захочется убрать зелень из пиццы — такая кастомизация не предусмотрена даже близко. Покупайте все комбо, и ковыряйтесь в нем, как хотите.
Этот стиль с очень ограниченным набором команд и стандартизованными ответами называется REST. Возможно, вам все же попадалась на глаза такая аббревиатура — REST API. Это API простое, как солдатская песня, — и оно многим разработчикам нравится за то, что оно такое простое, понятное и предсказуемое.
Но есть нюанс. Оно хорошо работает, если у вас очень толстый канал связи и достаточно мощный процессор. Когда у вас в руках мобильный телефон, с которого вы пытаетесь сделать запрос в соцсеть, и вам на мобильник валится из-за специфики этого REST API куча ненужной, но включенной в стандартные ответы информации — то вы лишний раз задумаетесь, а надо ли заходить в соцсеть, если сейчас опять всё будет тормозить.
Именно с этой проблемой столкнулись разработчики одной известной соцсети, которая начинается на «Fa» и заканчивается на «cebook» — пользователи просто хотят посмотреть фамилию знакомого своего знакомого, а там по умолчанию подтягивается всё его генеалогическое древо. Разработчики решили, что с такими шаблонными ответами надо что-то делать, и они пришли к другому дизайну обмена данными через API — GraphQL.
Если мы вернемся к нашей аналогии с рестораном, то GraphQL — это меню, где официант принимает запросы в таком виде:
Я хочу:
[✓] Бургер
[✓] Без лука
[✓] Двойной сыр
[✓] Картошка фри (маленькую порцию)
[ ] Кола (не отмечаю — не хочу)
[✓] Салат
[✓] Только томаты и огурцы
[ ] Без соуса
С точки зрения оптимизации обмена данными — это прорыв. У тебя просто очищается и канал связи от избыточного трафика, и смартфон не вешается от того, что ему нужно обработать и в конечном итоге отбросить массу ненужных данных.
И когда вы отправляете такой оптимизированный запрос на сервер, поддерживающий GraphQL — то там на сервере в этом самом API GraphQL уже все распланировано, какому вспомогательному сервису какую часть запроса сгрузить, чтобы тот через связанный с ним сервис подтянул нужный кусочек данных.
Вернемся на исходную позицию
Итак, напомню оригинал и предложенный перевод
The GraphQL service defines the interface, which can interact with any backend (database, legacy system, or external APIs), and the GraphQL client utilizes this interface to interact with the service.
...
Интерфейс API GraphQL позволяет клиентам взаимодействовать c любым бэкендом (базой данных, legacy-системой или внешними API).
Так вот опираясь на описанную выше логику, ошибка переводчика начинает потихоньку проявляться.
Дело в том, что при проектировании GraphQL API описывается, какие данные он может выдавать в целом, и какой компонент за какой кусочек данных отвечает.
Иными словами GraphQL API как бы описывает таблицу (или точнее схему) соответствий запрашиваемых данных и ответственных за эти данные компонентов — они называются резолверы сервиса.
Вместе эти резолверы представляют собой API, т.е. интерфейс сервиса сервера через который уже общается ваш браузер или клиентское приложение вашего мобильника.
Сколько этих резолверов будет на сервере — мобильное приложение совершенно не интересует, ибо для него точка коммуникации всегда будет одна (а не 100500, как у REST, где одно комбо заказываешь в одном окошке, а другое — в другом).
Таким образом, по смыслу у нас получается, исходя из английского предложения, что на сервере работает некий сервис с GraphQL API. В этом API расписаны (вот оно — ОПРЕДЕЛЕНЫ!) по зонам ответственности резолверы, и вот их должно быть достаточно в той мере, чтобы ни один запрос не ставил API в тупик — будь это запрос к базе данных, к старому сервису (к переделке которого у разработчиков никак руки дойти не могут) или к другому сервису, которому по эстафете через API нужно делегировать часть запроса.
Важно, что ваш мобильник/браузер/клиентское приложение напрямую ни к чему из вышеупомянутого не обращаются — вся коммуникация строго через сервис, на котором работает GraphQL API.
Таким образом, в исправленном виде наш перевод мог бы выглядеть так:
Сервис GraphQL определяет интерфейс, способный взаимодействовать с любым компонентом бэкенда (базой данных, унаследованной системой или внешними API), а клиент GraphQL использует этот интерфейс для взаимодействия с самим сервисом.
А на этом у меня все.
Спасибо за внимание :).