Процесс разработки GraphQL-First
В прошлом месяце мы с Сашко выступили на первом GraphQL Summit, где рассказали о нашей философии разработки GraphQL-First: новом рабочем процессе, который мы создали после сборки. с нуля сами с GraphQL и сотни бесед с разработчиками, которые делают то же самое.
Помимо других преимуществ, мы обнаружили, что этот рабочий процесс заставляет команды внешнего интерфейса и внутреннего интерфейса больше сообщать о спецификациях продукта и схемах данных заранее, что позволяет им затем создавать приложение параллельно с более высокой вероятностью успеха при соединении двух компонентов вместе.
В нашем выступлении были обобщены уроки, которые мы извлекли из создания инструментов с открытым исходным кодом для сообщества GraphQL, и наш опыт перехода от нуля к graphql в двух рабочих приложениях, включая Optics, инструмент аналитики GraphQL, над которым я работал в течение последнего. несколько месяцев.
В этом посте я подробно расскажу о рабочем процессе GraphQL-first вместе с реальными примерами в четырех разделах:
- Разработка вашей схемы
- Оптимизация рабочего процесса
- Загрузка данных в ваш пользовательский интерфейс
- Мониторинг ваших приложений в производстве
Давай займемся этим!
1. Разработка схемы
Первым шагом разработки GraphQL First является определение вашей схемы. Он становится контрактом между вашими фронтенд-разработчиками и бэкэнд-разработчиками и является фундаментом, на котором будет построена остальная часть вашей разработки.
Если вы создаете приложение с нуля, строго типизированная природа схемы позволяет более эффективно распараллеливать разработку. Frontend-разработчики точно знают, какие данные им следует ожидать, а backend-разработчики имеют полную спецификацию для разработки. Используя инструменты фиксации GraphQL и разработку на основе компонентов, вы можете создать интерфейс до того, как у вас будет реальный бэкэнд, и безболезненно соединить их, когда будете готовы.
В качестве альтернативы, если у вас уже есть серверные модули и REST API, вы можете воспользоваться этой возможностью, чтобы изменить свой уровень данных и получить API, который вы всегда хотели.
Наш опыт
У нас был опыт выполнения обеих этих задач в наших двух производственных приложениях Galaxy и Optics.
В Galaxy у нас есть, в частности, одна страница, на которой очень много данных (см. Ниже). На странице представлены графики, в которых в реальном времени представлена статистика из Amazon DynamoDB. Для типичного приложения страница может легко отображать 30 графиков обновления в реальном времени, каждый из которых выполнял собственную выборку данных из DynamoDB и MongoDB. Неудивительно, что у пользователей были проблемы с производительностью этой страницы, а код нашего приложения для визуализации графиков был очень сложным.
Мы смогли адаптировать GraphQL специально для этой страницы и абстрагироваться от сложности нашего внешнего кода на уровне GraphQL. Это позволило нам объединить то, что раньше было множественной выборкой на стороне клиента, в один более эффективный запрос GraphQL. В итоге мы значительно улучшили производительность страницы и сделали наш интерфейсный код более удобным в сопровождении.
Благодаря оптике у нас была возможность создать приложение с нуля, используя GraphQL. Мы начали процесс разработки с разработки схемы на основе наших макетов и знания требований к данным приложения. Как только схема была согласована, наши фронтенд и бэкэнд команды разрабатывали отдельно в течение нескольких недель. Когда все было готово, мы смогли легко подключить две системы менее чем за два дня.
Один вопрос: владение схемой
Интересно, что когда вы сначала разрабатываете схему приложения, вы сталкиваетесь с вопросом: кому на самом деле принадлежит схема?
Процесс разработки схемы - это переговоры между интерфейсной и серверной командами, у которых разные приоритеты. Наша схема оптики находится где-то в середине спектра, но если вы последуете мантре GraphQL-First, вы столкнетесь с аналогичным вопросом. Вы должны принять правильное решение в своей ситуации.
Теперь, когда вы разработали схему GraphQL, пора создать свое приложение.
2. Оптимизация рабочего процесса
Традиционную разработку приложений с использованием REST API бывает сложно распараллелить, потому что для написания и поддержки фиктивных данных для каждой конечной точки требуется много работы. Это означает, что разработка внешнего интерфейса часто блокируется прогрессом внутреннего интерфейса, и эти два процесса не могут происходить одновременно.
К счастью, GraphQL значительно упрощает этот процесс, потому что создавать и поддерживать фиктивные данные просто с помощью системы статических типов. В GraphQL данные имитируются для каждого распознавателя, а не для каждой конечной точки. Таким образом, если одно из полей вашей схемы изменяется во время разработки, все, что вам нужно сделать, это изменить один преобразователь с вашего макетного сервера GraphQL. Если вы имитировали данные для REST API и перенесли одно из полей своей базы данных, вам пришлось бы пойти и обновить каждую логику для каждого написанного вами макета конечной точки, что является гораздо более громоздким и менее удобным в обслуживании. Прочтите этот пост, чтобы узнать больше о имитации сервера с помощью GraphQL.
Когда мы создавали Optics, возможность параллельно разрабатывать интерфейс и серверную часть имела решающее значение. Используя подход GraphQL First, мы смогли безболезненно адаптироваться к изменениям схемы, подключить интерфейс и серверную часть менее чем за 2 дня и разработать все приложение с нуля менее чем за 3 месяца.
Все это стало возможным благодаря инструментам с открытым исходным кодом, над которыми мы работали, таким как graphql-tools и Apollo Client.
graphql-tools: включение разработки GraphQL-First
Одна из самых важных задач команды Apollo - создание инструментов, упрощающих разработку приложений с помощью GraphQL. Первый из них - это метко названные графические инструменты.
Это пакет npm, который позволяет вам использовать язык схемы GraphQL напрямую для реализации сервера GraphQL и имитации данных для этого сервера. Фрагмент кода в правой половине слайда выше - это все, что вам нужно для реализации работающей схемы GraphQL с помощью инструментов graphql.
Легко имитировать данные - еще один важный компонент разработки GraphQL-First. После того, как вы согласовали схему, которая представляет собой контракт между вашим интерфейсом и серверной частью, вы можете реализовать обе функции параллельно, и для этого вам понадобится инструмент, позволяющий имитировать данные серверной части. graphql-tools использует преимущества системы типов GraphQL, позволяя имитировать данные для каждого типа или для каждого преобразователя.
Самое захватывающее в создании программного обеспечения GraphQL с открытым исходным кодом - это сотрудничество с сообществом. Эти инструменты стали возможными благодаря большим запросам на вытягивание, например этот, сделанный itajaja в августе, чтобы включить насмешку для типов union и interface. Есть также замечательные люди, которые придумывают новые и захватывающие способы использования технологии, такие как этот замечательный доклад Ника Нэнса из Credit Karma об управлении схемами GraphQL с помощью инструментов graphql.
После того, как вы разработали схему и сможете имитировать данные сервера, пора реализовать интерфейс и серверную часть параллельно. В этом выступлении мы сосредоточимся на интерфейсе.
3. Загрузка данных с помощью запросов GraphQL.
Схема - это то, что делает GraphQL отличным инструментом для работы при определении данных, доступных в вашем бэкэнде. Но именно запросы делают его таким замечательным для создания пользовательского интерфейса на основе этих данных.
Отправить запрос GraphQL на сервер и получить ответ в формате JSON просто: вы можете просто отправить HTTP-запрос, как описано на сайте graphql.org. Но благодаря особым функциям GraphQL вы получите некоторые преимущества от использования более изящного инструмента, который мы назовем Caching GraphQL client - он отслеживает данные, которые вы уже загрузили в свой пользовательский интерфейс, и позволяет вам читать и манипулировать этими данными по-разному.
Таким образом, хотя данные GraphQL легко загрузить с помощью простой HTTP-выборки, и это отличный вариант для простых приложений, в более сложном приложении вам понадобится мощность, обеспечиваемая более умным клиентом, таким как Apollo или Relay.
Когда мы впервые начали работать с GraphQL, мы потратили много времени на изучение различных требований, которые люди предъявляют к клиенту GraphQL. Мы видели это в наших собственных производственных приложениях, а также поговорили с сотнями разработчиков об их опыте работы с GraphQL. Вот некоторые выводы, к которым мы пришли:
Клиенты должны поддерживать постепенное внедрение
Поскольку GraphQL лучше всего проявляет себя при добавлении его к существующей сложной архитектуре с уже существующими множественными источниками данных и клиентами, постепенное внедрение имеет первостепенное значение. Это проявлялось тремя способами:
- GraphQL на клиенте должен быть совместим с существующими инвестициями, такими как Redux, React-Router и другими технологиями. Даже если вы создаете с нуля, вы никогда не знаете, когда вам нужно будет добавить что-то новое в свой стек, и важно, чтобы GraphQL хорошо с этим работал.
- Передовые методы работы со схемами GraphQL еще недостаточно хорошо известны, и если у вас уже есть существующий бэкэнд, вам нужно будет согласовать схему GraphQL с этими данными. По этой причине мы пришли к выводу, что клиенты GraphQL не должны относиться к бэкэнд-схеме самоуверенно.
- Для постепенного внедрения во внешний интерфейс очень важно, чтобы GraphQL можно было внедрять в приложение по одной странице или компоненту за раз.
Вышеупомянутые моменты возникали снова и снова, пока мы думали о внедрении GraphQL в наши собственные приложения и разговаривали с другими разработчиками.
Запросы должны генерироваться статически
Возник еще один вопрос: должны ли запросы создаваться динамически во время выполнения или объявляться статически и встраиваться в приложение? После более чем года использования GraphQL ответ теперь для нас очевиден: статические запросы - это лучший способ. Для получения более подробной информации посетите:
- В нашем блоге 5 преимуществ статических запросов GraphQL
- Выступление Джо Савоны Лучшие практики для клиентов GraphQL
Еще одно большое преимущество декларативных запросов - это возможность использовать инструменты разработчика GraphQL для генерации статических типов, интеграции IDE и проверки запросов. Узнайте больше о генерации кода в Apollo-iOS и ознакомьтесь с apollo-codegen, чтобы внести свой вклад в усилия по Flow и TypeScript!
Клиент Apollo
По всем вышеперечисленным и другим причинам мы работаем с сообществом более 9 месяцев над созданием, поддержкой и улучшением одного из самых популярных сегодня клиентов GraphQL, Apollo Client. Версия 0.5 была выпущена недавно и является кульминацией более чем 6-месячной работы более чем 100 человек, с особой благодарностью Джеймсу Бэксли III, Робину Рикарду, Джон Пинкертон, Абхи Айер и Камил Кизиела.
Мы действительно гордимся тем, как далеко продвинулся Apollo Client, и не собираемся сбавлять обороты. Мы продолжим продвигать футуристические функции GraphQL, такие как подписки и инструменты разработчика нового поколения, чтобы сделать создание приложений с помощью GraphQL проще, чем когда-либо.
Теперь, когда вы разработали схему и параллельно создали пользовательский интерфейс и серверную часть, вам нужно запустить приложение в производственной среде. Какие преимущества может принести GraphQL?
4. Мониторинг вашего приложения в производственной среде
Если вы собираетесь запускать приложение в производственной среде, первое, что вам нужно будет настроить, - это некоторые инструменты мониторинга производительности, чтобы отслеживать такие вещи, как загрузка сервера, использование конечных точек и другие классические вопросы. Одна из наших любимых особенностей GraphQL заключается в том, что он не только дает вам больше контроля над вашим API, но также дает вам более подробное представление о производительности вашего API.
С GraphQL вы можете задавать вопросы о производительности, о которых вы никогда раньше не задумывались. Например, поскольку API-интерфейсы GraphQL точно знают, какие поля запрашивают их пользователи, вы можете спросить: какие поля не используются - могу ли я отказаться от них? Вы не могли сделать это с REST, потому что можете ' t сказать, какие конкретные данные от конечной точки клиенты фактически используют. Однако с некоторыми базовыми инструментами сервера GraphQL на этот вопрос легко ответить.
Поскольку запросы GraphQL выполняются по одному полю за раз, вы можете легко определить горячие точки производительности, точно отслеживая, сколько времени требуется для разрешения каждого поля в вашей схеме. Кроме того, поскольку вы знаете, кто использует какие поля и когда, вы можете обнаруживать критические изменения схемы, например, какие интерфейсы делают неправильные запросы, или будет ли изменение бэкэнда сломать какого-то клиента в этой области.
Есть много других подобных вопросов о сервере GraphQL, которые мы только начинаем изучать.
Наш опыт
В качестве доказательства концепции мы оснастили Galaxy прототипом нашего инструмента мониторинга и смогли сразу определить области, в которых мы могли бы улучшить его производительность.
На следующем рисунке показана подробная трассировка таймингов преобразователя для запроса, который извлекает метрики для списка контейнеров. Быстрый взгляд покажет вам, что он запрашивает информацию из каждого контейнера поочередно. Мы это увидели и сразу поняли, что процесс выполнения запроса нужно распараллеливать. Благодаря этому изменению мы повысили производительность этого запроса на 200 миллисекунд.
Распараллеливание процессов, подобных этому, является ключом к поддержанию производительности производственного приложения и обеспечению хорошего взаимодействия с пользователем. Если бы мы не сделали нашу собственную аппаратуру для Galaxy, мы, возможно, не определили бы эту область для улучшения.
Аполлон Оптика
GraphQL открывает мир новых вопросов по мониторингу производительности, которые мы очень рады изучить. Наш новый инструмент мониторинга производительности GraphQL, Apollo Optics, теперь доступен для серверов JavaScript и Ruby GraphQL, и он может помочь вам задать те же вопросы о ваших собственных приложениях.
Обновление: Вышла новая версия Оптики! Apollo Engine имеет все, что делает Optics, плюс отслеживание ошибок, кеширование запросов и многое другое. Движок бесплатен на 1 миллион запросов в месяц!
Подводя итоги, мы были очень довольны тем, как GraphQL предоставляет разработчикам возможности. Мы думаем, что лучший способ разработки GraphQL - это сначала спроектировать вашу схему, которая затем действует как контракт между вашими интерфейсными и серверными командами. Мы неустанно работали над созданием как инструментов с открытым исходным кодом для разработки GraphQL, так и инструментов мониторинга для производственных приложений. Нам было приятно провести эту конференцию, и мы действительно с нетерпением ждем, когда 2017 год приведет сообщество GraphQL.
Если вы хотите работать с нами над созданием более крутых инструментов GraphQL, мы нанимаем!
