Постоянно меняющийся мир фронтенд-разработки продолжает развиваться и внедрять множество различных библиотек для решения ваших задач. Поскольку популярность 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.
Спасибо за прочтение!
Пэт