Переход Expo Home от прототипа к производству за несколько недель

Использование «самой крутой новинки» - не всегда лучшее инженерное решение. Практически все согласны с тем, что разумнее всего полагаться на проверенные временем и стабильные технологии. Что касается веб- или мобильной серверной части, мудрый совет - использовать реляционную базу данных, создавать RESTful API и вообще просто использовать то, что все знают и понимают; «Будь проще» - это согласованная мантра.

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

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

Б.А .: До Аполлона

В конце 2016 года одной из основных внутренних целей Expo было обновление нашего клиентского приложения - проекта, который мы с любовью называем Expo Home.

Предыдущая версия приложения была в основном просто программой просмотра проектов Expo. Вы могли просматривать свои недавние проекты, но не могли просматривать чей-то профиль с проектами, над которыми они работали.

Новое приложение

Помимо приятного визуального фейслифтинга (на фото ниже), наша цель с новой версией клиента заключалась в том, чтобы сделать ее более ориентированной на сообщество. У нас есть вход / регистрация, профили пользователей, способ изучения «избранных», «новых» и «лучших» проектов, а также поиск проектов / пользователей. У нас есть гораздо больше запланированных для Expo Home в будущем, но мы договорились, что эти функции станут нашим MVP для запуска в феврале 2017 года.

Перед запуском проекта у нас были некоторые, но не все необходимые данные, доступные через бесчисленное множество RESTful-конечных точек, предоставляемых нашим бэкэндом, которые мы использовали в других вспомогательных частях наших продуктов. Помимо того, что нам не были предоставлены необходимые данные и что она не была хорошо документирована, эта часть нашей кодовой базы также не была хорошо протестирована и поддержана. Мы не хотели строить будущее клиента Expo на этом шатком фундаменте, поэтому у нас было два варианта: изменить архитектуру и создать более удобный в обслуживании RESTful API или использовать совершенно другой подход.

До работы в Expo у меня была возможность поработать над несколькими приложениями, в которых использовались GraphQL и Relay, и я был очень впечатлен результатом и был особенно восторжен по поводу GraphQL. Как бэкэнд-инженер в этом проекте, я подумал, что было бы отличной идеей попробовать GraphQL для Expo Home и использовать Apollo во внешнем интерфейсе.

Нам нужно было создать массу новых функций, и какое-то время я хотел ввести GraphQL в стек технологий Expo. Этот проект казался идеальным, но мне нужно было продать его своей команде.

Почему GraphQL

Много было написано о GraphQL и REST, а также о проблемах, с которыми часто сталкиваются REST API. Я представил некоторые из этих аргументов команде, предлагая им использовать GraphQL для работы Expo Home.

Создание производительного, поддерживаемого RESTful-приложения абсолютно возможно. С другой стороны, сделать это быстро - совсем другое дело. У нас было меньше двух месяцев, чтобы выпустить первую версию нового мобильного приложения Expo, и поэтому важно было быстро работать.

Инженерное дело, как и большинство других вещей в жизни, - это компромисс. Некоторые соображения, которые я изложил команде:

  • Взаимодействие с пользователем - если мы потратим массу времени на то, чтобы сделать нашу логику получения данных в приложении действительно надежной, жертвуем ли мы пользовательским интерфейсом нашего приложения и совершенствуем пользовательский интерфейс?
  • Производительность и стабильность. Если мы тратим массу времени на доводку пользовательского интерфейса, делаем ли мы приложение медленным или не справляемым с ошибками?
  • Избыточная выборка - на бэкэнде мы могли бы потратить свое время, сосредоточившись на покрытии API и убедившись, что все, что может придумать интерфейсный инженер, покрывается API. Однако если мы это сделаем, создадим ли мы медленные конечные точки (предоставляя слишком много данных) или вызываем водопад запросов от наших клиентов, потому что они должны запрашивать множество ресурсов API для создания пользовательского интерфейса для одного экрана?
  • Технический долг. Что, если мы потратим время на создание индивидуальных API-интерфейсов, которые обеспечивают идеальное покрытие для данного экрана без избыточной или недостаточной выборки? Не заглядываем ли мы в угол реализации, что затрудняет управление всем, когда мы хотим добавить функцию?

С GraphQL и Apollo нам не пришлось идти на такие же компромиссы и мы могли создать быстрый и простой в обслуживании интерфейс и серверную часть с самого начала проекта.

Рабочий процесс разработчика и результаты, готовые к работе

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

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

В нашем случае было абсолютно необходимо, чтобы в сжатые сроки Брент Ватне и я могли работать параллельно, насколько это возможно. Оглядываясь назад на создание новой версии приложения Expo, я больше всего обращаю внимание на то, насколько плавным был рабочий процесс, когда мы с Брентом Ватне работали над приложением.

У нас с Брентом почти не было этого принудительного сотрудничества. Это произошло по двум причинам:

  1. Apollo и окружающие его инструменты упрощают использование фиктивных данных / фиктивного сервера, которые мы использовали с самого начала проекта.
  2. Graph i QL, встроенная в браузер среда IDE для изучения серверов GraphQL (на фото ниже) - просто потрясающий инструмент для просмотра API и изучения его возможностей.

Вместо того, чтобы тратить время на обсуждение дизайна API или того, какие данные должны быть в какой конечной точке, мы с Брентом смогли поговорить о том, как сделать продукт лучше и обеспечить удобство для пользователей.

Еще одна особенность опыта разработки GraphQL / Apollo, которая мне особенно запомнилась, заключается в том, что в конце концов у вас не останется ничего, что было бы легко начать, но не удовлетворяет производственным потребностям. Скорее наоборот - все, что мы построили, потому что мы использовали набор инструментов Apollo и следовали лучшим практикам GraphQL, было готово к производству с самого начала.

Будущее

Expo Home еще далека от завершения - на 2017 год запланировано множество улучшений.

Примером такого улучшения является функция, которая показывает текущий проект, который вы открыли в XDE, нашей настольной среде разработчика, на главном экране Expo Home. В этой функции есть несколько движущихся частей, но одна из частей, которые меня больше всего волнуют, - это использование подписок GraphQL для обновления интерфейса приложения.

graphql-tools package Apollo делает это довольно простым делом, и мы можем использовать PubNub в качестве бэкэнда, избавляя нас от реализации нашего собственного решения на основе WebSocket.

В Expo мы также работаем над тем, чтобы перенести элементы Expo Home в Интернет. Вся внутренняя работа Expo Home, в дополнение к разумному объему внешней работы, может быть повторно использована в этих усилиях. И по мере роста Expo, когда нам необходимо переместить части нашей инфраструктуры из нашего монолита в отдельные сервисы, веб-клиенты и мобильные клиенты могут оставаться нетронутыми, что позволяет нам быстро перемещаться во всех частях нашей инфраструктуры, не блокируя какую-либо конкретную команду или проект.

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

GraphQL и набор инструментов Apollo уже сыграли важную роль в нашей дорожной карте продукта в 2017 году, и мы лишь прикоснулись к их общему потенциалу.

Если вы хотите узнать еще больше о том, как мы используем GraphQL и Apollo на Expo, посмотрите мой доклад с Apollo Day 2017: