Post #755

Нашел отличный кейс по интеграциям, всем теперь рассказываю: как Netflix перешел c REST на GraphQL. История вообще мощная, особенно если начать издалека. Вначале у Netlix было API, оно было REST, и оно было одно на всех (как и положено REST API). Потом они выяснили, что у них больше 800 разных типов устройств, на которые они могут стримить (не знаю, откуда столько, видимо, включая утюги и зажигалки). И всем нужно разное. Где-то какие-то функции есть, где-то нет. У кого-то огромный экран, а у кого-то еле влезает кнопка "Play". Кто-то умеет обрабатывать большие древообразные структуры данных, а кому-то только небольшие плоские подходят. В принципе, они все делают примерно одно и то же, но каждому клиенту нужен немного кастомизированный эндпоинт. И они сделали конструктор API (это 2012, все что-нибудь изобретали). А потом, в 2015, как приличные люди, они придумали свой вариант переосмысления REST: библиотеку Falcor. Правда, не так далеко ушли, как, например, создатели GraphQL. Больше всего Falcor похож на внутреннее решение по вытаскиванию произвольных данных из одной большой модели. Я такие видел, только не все выползают наружу (многим просто стыдно показывать). Тут нужно понимать основное назначение Netflix для пользователя: найти и посмотреть фильм. А искать его можно очень по-разному, и из разных точек: то ли с жанра начать, то ли с года, то ли все фильмы определенного режиссера вытащить, то ли те, где играл какой-то актер, или всё это сразу. А ещё есть рекомендации и рейтинги. В общем, всё со всем связано, и потянуть можно за любую ниточку. Получается граф. В Falcor он тоже получается, JSON Graph. Причем со встроенными функциями для работы с ним, это уже остроумно. В общем, с этим Falcor'ом Netflix жил до 2020 года. Но проблема в том, что архитектурно Falcor — монолит. При том, что внутри вся архитектура давно на микросервисах. И скорость изменений микросервисов стала опережать возможности команды, поддерживающей монолитный API-сервер. И тут они стали смотреть в сторону GraphQL, потому что там есть federation. Логично: одну монолитную модель данных делим на много частных моделей, за которые отвечает своя команда. А GraphQL всё собирает автомагически. Переход на GraphQL сначала случился в Netfilx Studio — той части, где идёт производство фильмов и сериалов — одно из крупнейших в мире. А потом уже и для всех клиентов. Причем сначала это была просто прокладка перед старым монолитным API, чтобы перевести клиентов на новую технологию, но принципиально не менять модели. А дальше аккуратно, без даунтайма(!), всех перевели на федеративную структуру. Так что сейчас у них есть федеративный GraphQL на фронте, в котором удовлетворяются потребности и всех возможных клиентов, и асинхронная эволюция разных сервисов на бэке; gRPC для связи между микросервисами внутри (тоже довольно хитро докрученные), и ещё где-то там Kafka. Вот такой стек сейчас в высоконагруженных крупных сервисах. И такие вопросы решаются. Поэтому выбор технологии, вообще говоря, стратегическое решение. Один аналитик, сам по себе, не может его сделать. Но знать про нюансы и оценить разные варианты может — это как раз инструментарий системного анализа в исходном смысле.