Путь к GraphQL
Когда REST не вывозит
Уже более 20 лет прошло с момента появления концепции REST. За это время крупные корпорации и Open Source сообщество разработали огромное количество инструментов для REST API, предоставляя решения из коробки для быстрой и удобной разработки.
REST API стал доминировать как решение для монолитных систем. И когда началась новая волна - микросервисная архитектура, многие по инерции продолжили использовать REST API.
Традиционная модель архитектуры выглядела приблизительно так:
С одной стороны, количество сервисов обычно растет с невероятной скоростью, что уже создает проблему для клиентских приложений, которым иногда приходиться вызывать десятки API только при загрузке. Если браузеры еще справляются, то мобильным приложениям и смарт устройствам уже становиться плохо.
Но появилась проблема и с другой стороны - фрагментация клиентов. Помимо традиционных браузеров появились как минимум две основные мобильные платформы, множество платформ для смарт устройств и ТВ. Да и сами клиенты часто разделены на несколько независимых приложений, и не вся функциональность доступна одинаково на различных платформах.
Эти две проблемы и дали толчок новому поиску подходящей архитектуры.
За острый край
Чтобы как-то облегчить разработку клиентов, появилась архитектура, которая не полагалась на единый унифицированный набор API, а создавала агрегационный уровень для каждого класса клиентов. Появились BFF (Backend For Frontend) - бэк-енды для фронт-ендов. Сервисы, чье назначение было транслировать множество вызовов API в меньшее количество, перевариваемое клиентом.
Это отчасти привело к развитию Edge вычислений (или serverless), когда сервис уже не представляет никакой инфраструктуры, даже облачной, а всего лишь набор кода.
Архитектура стала выглядеть примерно так:
Однако это решает только часть проблемы. Другая часть - это оптимизация загрузки на самом клиенте. К тому же такая архитектура переносит фрагментацию из клиентов на уровень дальше, но не избавляется от неё.
Единый граф
One graph to rule them all
В 2015 году Facebook публикует спецификацию GraphQL которую они использовали для внутренней разработки инструментов с 2012 года. GraphQL представляет собой одновременно язык запросов и описания схемы данных. А также описания операций, доступных для этих данных.
GraphQL позволяет описать все сущности, связи и операции предметной области вашего бизнеса в виде цельного графа, что раньше могли сделать только бизнес-аналитики на специальных диаграммах. При этом этот граф и есть ваше API, которое могут использовать все приложения, как собственные, так и сторонние (если это, конечно, нужно).
Такой подход помогает решить проблему фрагментации клиентов и избавляет от необходимости иметь десятки BFF. Теперь каждый клиент может запрашивать только те данные, которые ему нужны, из единого графа данных организации.
Интересный факт, что компания Netflix почти одновременно в 2015 году создает Falcor - фреймворк, который позволяет представлять данные для клиентов в виде единого связанного графа сущностей. Ничего не напоминает? К сожалению, такой популярности он не завоевал.
Новая архитектура стала выглядеть примерно так:
Это очень упрощенный вариант, и сегодня GraphQL позволяет создавать гораздо более оптимизированные решения, проникая глубже в архитектуру, позволяя сшивать и делегировать запросы для под-графов на сами микросервисы. (Про GraphQL Federation мы расскажем в следующих статьях)
Так как GraphQL - это не конкретная библиотека или фреймворк, а открытая спецификация, появилась достаточно большая экосистема реализаций. Одна из самых популярных из них - это семейство решений от Apollo.
Apollo предоставляет готовые решения из коробки для клиентов, серверов, инструменты разработки, визуализации, мониторинга и многое другое.
Стоит ли начинать
Возможно, после небольшого экскурса в историю вы задались вопросом: стоит ли начинать разработку новой информационной системы или даже просто нового сервиса с использованием GraphQL сегодня?
Ответом будет - да.
С точки зрения бизнеса, если вы хотите, чтобы ваша информационная система развивалась долгие годы, прибавляя в функциональности, при этом не наступая на те же грабли, через которые уже прошли десятки и сотни компаний по всему миру за последние 10 лет, то ответом будет - однозначно, да!.
Есть ряд факторов, которые могут вызвать вопросы. Например, недостаточное количество разработчиков, которые хорошо разбираются в данной технологии. В этом плане будет становиться лучше, т.к. популярность GraphQL растет, и с каждым днем все больше компаний и специалистов появляются на рынке.
Кстати, мы одни из них - эксперты по GraphQL и Apollo с многолетним практическим опытом!