Как Apollo предоставит унифицированный, постепенно адаптируемый опыт на всех трех платформах

Ранее в этом месяце мы запустили Apollo Client 1.0, и это было очень захватывающе: было несколько замечательных комментариев в ветке Hacker News, множество новых загрузок, и многие новые разработчики присоединились к сообществу Apollo.

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

Хотя клиент Apollo для JavaScript является наиболее известным из проектов Apollo, у нас также есть два отличных, быстрорастущих нативных клиента для iOS и Android. Буквально на прошлой неделе мы анонсировали Apollo Android 0.3, первый релиз, готовый к общедоступному использованию!

Сегодня мы хотим рассказать вам об одной из самых интересных инициатив, над которыми мы работаем в ближайшие месяцы, и о том, как мы сотрудничаем с командами таких компаний, как Airbnb, New York Times, Shopify и Coursera, чтобы воплотить ее в жизнь: Унификация клиента Apollo для всех JavaScript и собственных платформ.

Читайте дальше, чтобы узнать, почему мы считаем важным кроссплатформенный клиент, как использовать такие команды, как Airbnb, и как вы можете принять участие.

Все на мобильных

В настоящее время в разработке веб-приложений наблюдаются две большие тенденции:

  1. Мобильные устройства сейчас являются доминирующей платформой. Фактически, в 2016 году использование телефонов и планшетов превысило использование настольных компьютеров.
  2. React Native становится все более популярным среди разработчиков мобильных приложений благодаря своей простоте, кроссплатформенной совместимости и возможностям отправки кода.

Это означает, что все больше и больше компаний создают приложения как минимум для трех платформ: Интернета, iOS и Android. Несмотря на то, что различные платформы концептуально представляют только одно приложение, они обычно заканчиваются тремя отдельными кодовыми базами. Наличие нескольких реализаций одного и того же всегда приводит к несогласованности. Это расстраивает пользователей, а для разработчиков это пустая трата времени и источник ошибок.

React Native помогает с фронтендной частью этого вопроса, поскольку позволяет вам обмениваться знаниями, кодом и, возможно, даже целыми компонентами пользовательского интерфейса на разных платформах. Но большинство мобильных приложений сегодня по-прежнему создаются с использованием собственных технологий, и совместное использование кода пользовательского интерфейса решает только половину проблемы. Другая половина - это загрузка данных и управление ими.

GraphQL: идеально подходит для кроссплатформенных приложений

Сообщество Apollo не существовало бы без GraphQL. Мы очень благодарны его создателям в Facebook и людям в предыдущие десятилетия, которые работали над технологиями, которые вдохновили его. Вот три вещи, которые меняют правила игры в GraphQL:

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

Глядя на эти преимущества, GraphQL не составляет труда для большинства команд, начинающих новые проекты, и все больше и больше команд постепенно добавляют его в свою существующую инфраструктуру. Поскольку все команды уникальны и не существует универсального решения, мы прилагаем все усилия, чтобы технологии Apollo были простыми в использовании, оставаясь при этом максимально гибкими и модульными. Совместимость и гибкость были в наших принципах дизайна с первого дня.

Улучшение существующих приложений с помощью GraphQL

Одна из лучших частей GraphQL заключается в том, что его можно постепенно добавлять поверх любого API или внутреннего источника данных. Компании, которые уже достигли такого масштаба и сложности, когда вы действительно начинаете чувствовать боль REST или специального API, могут добавлять GraphQL понемногу.

React Native может быть таким же - большинство компаний в настоящее время пишут по одной кодовой базе для Интернета, iOS и Android, но вы можете постепенно перемещать свои мобильные приложения в React, чтобы начать дублировать все меньше и меньше логики. Именно это делают Airbnb со своими мобильными приложениями, но, поскольку они начали делиться большей частью своей бизнес-логики и компонентов, они обнаружили, что по-прежнему имеет смысл реализовать некоторую инфраструктуру в собственном коде. Лиланд Ричардсон из Airbnb объяснил эту концепцию в своем выступлении в начале этого года на React Conf React Native in the Brown Field ».

Лиланд также анонсировал одну из новейших разработок Airbnb с открытым исходным кодом, Native Navigation - навигационный пакет для React Native, который позволяет как JS, так и собственный код взаимодействовать с навигацией, позволяя приложениям, в которых представления смешиваются между React и собственным кодом, по-прежнему иметь плавные переходы. между этими взглядами.

Вкратце о сценарии использования Airbnb

У Airbnb есть настольное веб-приложение, использующее React и мобильные приложения для iOS и Android. Части этих приложений начинают переходить на React Native, что позволяет им разрабатывать намного быстрее и совместно использовать больше кода между платформами. Это означает, что в их приложениях React Native и собственный код работают бок о бок и должны легко интегрироваться. Эта интеграция также должна распространяться на загрузку и кеширование данных: если представление React Native загружает данные в кеш GraphQL, им необходимо, чтобы эти данные были доступны в собственных представлениях и наоборот.

Представьте, например, естественное представление, которое отображает списки квартир в городе вместе с изображением, ценой и некоторым текстом предварительного просмотра. Когда вы нажимаете на список, вы попадаете в подробное представление, написанное на React Native. Приложение уже загрузило достаточно данных, чтобы показать вам хороший предварительный просмотр (изображение, цена, заголовок) при получении полного списка, но оно может сделать это только в том случае, если представление React Native имеет доступ к данным, загруженным в собственном представлении.

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

С помощью разработчиков из Airbnb, Shopify, The New York Times и всего сообщества Apollo в настоящее время мы улучшаем все три клиентских проекта и реализации Apollo для удовлетворения этих требований. Ядро архитектуры, которую мы создаем, - это чистый API хранилища GraphQL, который позволяет нам совместно использовать подключаемый кеш между тремя платформами.

Единый API хранилища GraphQL Apollo

Сердцем единой клиентской архитектуры будет общий глобальный кеш. Он хранит все нормализованные данные и имеет стандартизированный API для чтения и записи данных. Хранилище состоит из двух уровней: более высокий уровень, который мы в настоящее время называем хранилищем Apollo, обеспечивает безопасность потоков и методы для управления данными с использованием примитивов GraphQL, а нижний уровень, нормализованный кэш, представляет собой подключаемое хранилище значений ключей. используется для сохранения отдельных записей. Эта архитектура будет одинаковой для всех платформ:

Наличие четкого контракта между хранилищем, нормализованным кешем и остальной частью клиентской реализации позволяет легко подключить любое хранилище: SQLite, IndexedDB, Realm, Mobx, Redux, NgRX, простой словарь в памяти или что-то еще что соответствует вашим потребностям.

Такой дизайн упростит совместное использование кеша между нативным и React Native. В типичном мобильном приложении с React Native мы ожидаем, что собственный клиент будет обрабатывать постоянное хранилище, а клиент JavaScript будет взаимодействовать с собственным хранилищем через мост React Native для чтения и записи данных. Мы считаем, что это приведет к множеству положительных аспектов даже для приложений, полностью построенных на React Native, включая простое управление данными в автономном режиме, более плавный пользовательский интерфейс от разгрузки работы от JS и предварительную выборку данных из собственного кода до того, как React Native даже завершит инициализацию.

Этот новый API-интерфейс с независимым кешем лежит в основе новой клиентской архитектуры, но является лишь частью нашего единого плана загрузки данных. Мы также работаем над тем, чтобы политики выборки и стратегии аннулирования / удаления кеша были согласованы на разных платформах. Нам нужна эта симметрия, чтобы гарантировать, что представления или логику управления данными можно перемещать через границу платформы, не приводя к непредсказуемым ошибкам. Но на более базовом уровне мы обнаружили, что люди, участвующие в различных реализациях клиентов, много узнают о пространстве дизайна GraphQL-клиента, делясь проектами, основанными на преимуществах и ограничениях трех очень разных платформ.

Примите участие

Я очень воодушевлен будущим Apollo и GraphQL. Я думаю, что новая модульная архитектура и подключаемый API хранилища GraphQL, над которым мы работаем, обеспечат большую гибкость, не усложняя использование клиента Apollo Client. Вы по-прежнему сможете начать работу с всего лишь нескольких строк кода, а затем извлекать пакеты из экосистемы, чтобы расширить клиент Apollo с улучшенной интерактивностью, автономными данными и т. Д.

Если вам нравятся Apollo и GraphQL, дайте нам знать в комментариях и присоединяйтесь к нашему активному сообществу в Slack! Помимо всех участников Apollo, есть масса разработчиков, которые хотят поговорить о GraphQL и помочь новым разработчикам начать работу.

Есть идея, как улучшить Apollo? Нашли ошибку или у вас есть свободное время, чтобы поделиться с сообществом? Тогда присоединяйтесь к нашему каналу #contributors в Slack, сообщите о проблеме или сделайте PR прямо на GitHub (JS, iOS, Android)!