Постоянно меняющийся мир фронтенд-разработки продолжает развиваться и внедрять множество различных библиотек для решения ваших задач. Поскольку популярность GraphQL продолжает расти, инструменты и библиотеки, окружающие его, также меняются. Недавно я помогал писать новое приложение, которое взаимодействовало исключительно с серверной частью GraphQL, и использовал для взаимодействия клиент Apollo (AC) вместо Redux в нашем внешнем приложении React. Ранее я написал много приложений на javascript с помощью Redux, и вот некоторые выводы из моего опыта.

Отказ от ответственности: при сравнении двух библиотек предполагается, что вы работаете с серверной частью GraphQL. Клиент Apollo не работает с другими типами бэкендов и в этом случае не является жизнеспособной альтернативой Redux.

Встроенное управление жизненным циклом

AC имеет множество удобных состояний, встроенных в его useQuery и useMutation функции, которые Redux либо требует вручную, либо требует дублирования библиотеки.

// Apollo's built in loading/data/error responses 
const [getData, { loading, data, error }] = useQuery(MY_QUERY)

Хотя в Redux они не встроены, вы можете либо создавать состояния в своих редьюсерах и действиях, либо использовать некоторые из множества плагинов, доступных для редукции.

Строгая форма данных

Основное преимущество AC заключается в том, насколько близко он отслеживает ваш магазин GraphQL и его форму. Это означает, что нет необходимости создавать редукторы и определять форму вашего магазина. AC дает вам уверенность в том, что форму вашего магазина нельзя изменить без обновления типов GraphQL или ваших политик типов. Redux достаточно свободен в своих требованиях, где вы можете изменить состояние по своему усмотрению, если вы не следуете хорошим практикам.

Типизированный характер хранилища AC также обеспечивает некоторые уровни безопасности типов. В моем случае мы использовали интерфейс React + Javascript, однако безопасность типов также может быть достигнута с помощью Typescript на вашем интерфейсе.

Плохая поддержка плагинов

В настоящее время AC не поддерживает плагины, в то время как Redux имеет довольно надежную экосистему плагинов. Однако, по моему опыту, библиотека не оставила много пробелов, которые необходимо было заполнить. Распространенным плагином в Redux является thunk, который обеспечивает возможность асинхронного взаимодействия с вашим магазином. Благодаря использованию AC хуков и различных состояний ответа (загрузка, данные, ошибка и даже оптимистичный пользовательский интерфейс) многие из общих требований к современному интерфейсному приложению выполняются.

Зрелость

AC новый, проекта давно нет, и он тесно связан с другой новой технологией (GraphQL). Учитывая эти два ограничения, в результате общая потенциальная база разработчиков становится меньше. Это означает, что документация не так распространена, сообщество все еще растет, и, самое главное, сама библиотека все еще претерпевает изменения. Redux старше, работает с более широким спектром бэкендов и благодаря этому имеет сильное сообщество. Для тех, кто начинает разработку внешнего интерфейса, выбор Redux может быть лучшим путем просто из-за объема доступной поддержки.

У AC более высокий барьер для входа, так как его не так просто раскрутить. Вы не можете просто взять любой интерфейс и подключить его к любому серверу, Redux предоставляет вам эту свободу, поскольку он не такой самоуверенный, как AC.

Сводка

Redux, вероятно, никуда не денется в ближайшее время. Это широко известный и широко используемый фреймворк во множестве интерфейсных фреймворков. Это дает ему огромное преимущество, однако для хорошей работы требуется дополнительная настройка и управление. AC решает множество распространенных проблем внешнего интерфейса, но тесно связывает вас с внутренним интерфейсом GraphQL. В следующий раз, когда у вас будет приложение, которое вы собираетесь написать, если вам посчастливилось взаимодействовать только с бэкэндом GraphQL, стоит попробовать AC.

Спасибо за прочтение!
Пэт