Решение не использовать GraphQl @ defty Engineering - 3 вещи, которые мы обнаружили

Что мы создаем

В defty мы стремимся революционизировать создание веб-сайтов для миллионов малых предприятий с помощью самого простого в мире конструктора веб-сайтов.

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

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

Сосредоточение внимания на панели инструментов

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

В начале планирования приборной панели мы начали изучать потенциальные реализации, на этом этапе у нас уже были определены начальный набор функций и технические возможности. Пока мы выбрали React, для внешнего интерфейса, серверной части Node / Express и базы данных Postgres это должно было быть простое приложение CRUD, написанное на Javascript, которое будет обрабатывать биллинг, домены, поддержку и аутентификацию пользователей.

Мы определили, как может выглядеть наш бэкэнд, и мы выбрали два основных варианта: бэкэнд REST и бэкэнд GraphQL. REST существует уже некоторое время и работает, но GraphQL - это новая технология для нас, и в этом плане она очень интересна, поэтому мы посмотрели, чего мы от нее хотели.

Преимущества GraphQL для панели инструментов

  • Быстрое развитие - гибкость внешнего интерфейса. Мы хотели упростить разработку внешнего интерфейса, упростив получение данных и потоки состояний.
  • Отсутствие избыточного соответствия и недостаточной выборки - GraphQL решает проблему избыточной и недостаточной выборки ресурсов в API. Мы хотели использовать эту модель, чтобы иметь эффективные вызовы API с минимальными затратами на полосу пропускания.
  • Богатая экосистема и сообщество. С момента своего выпуска в 2015 году GraphQL собрал огромное количество поклонников, он использовался в производстве некоторыми из крупнейших компаний мира, Facebook, Twitter, Pinterest и т. Д. Были разработаны различные инструменты, облегчающие жизнь. Такие инструменты, как Apollo и Relay, предоставляют множество функций, таких как кэширование из коробки, а другие инструменты, такие как Prisma и graphql-yoga, позволяют быстро настроить схему и сервер GraphQL. Мы хотели воспользоваться преимуществами этих мощных готовых инструментов для создания, имитации и мониторинга.
  • Сильная типизация - GraphQL реализован с использованием строго типизированной схемы, которая имеет много преимуществ, например, позволяет API быть информативным, что позволяет клиенту знать, какие данные доступны и в какой форме они существуют, а также позволяет автоматически -сгенерированная документация. Мы хотели использовать эти функции, чтобы ускорить документирование и уменьшить количество ошибок потребителей API в целом.

Мы разобрали его и задали несколько важных вопросов

Решение использовать ли GraphQL - важное решение, которого нам потенциально придется придерживаться в течение долгого времени. Мы уделили этому достаточно времени и внимания.

Мы взяли потенциальную реализацию GraphQL, состоящую из React, клиента и сервера Apollo, graphql-yoga (включая Prisma) и Postgres, и исследовали ее приложение.

Сначала мы поняли плюсы и минусы нашей реализации GraphQL и исследовали компромиссы. Мы задавали себе важные вопросы, изучая определенные болевые точки и варианты использования.

В результате возникло несколько важных вопросов:

Насколько усложняем серверную часть, чтобы упростить интерфейс?

Как остановить DoS-атаки с помощью неограниченного дерева запросов? Как мы справляемся с проблемой N + 1?

Как мы будем поддерживать эту архитектуру в будущем?

Мы прошли несколько итераций исследовательских вопросов и пришли к ответам, пока не достигли точки, в которой нам было комфортно с тем, что мы нашли, и мы могли сделать вывод.

Что мы узнали

1. Для дополнительной сложности нам не потребовалась такая гибкость.

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

2. Оптимизация и безопасность усложнили ситуацию

  • Решение проблемы данных N + 1. Проблема N + 1 - это распространенная проблема, обнаруживаемая в GraphQL. В рамках нашего исследования мы обнаружили, что решение этой проблемы можно было бы использовать с помощью чего-то вроде загрузчика данных Facebook, однако он также добавляет дополнительный уровень сложности и времени разработки для проекта, который должен быть относительно простым.
  • Безопасность. Мы обнаружили, что реализация защиты от DoS-атак с использованием неограниченного количества деревьев запросов добавляет еще один уровень сложности. Есть несколько простых в реализации решений, таких как ограничение глубины и количества. Однако для обеспечения полной защиты от злоумышленников нам необходимо реализовать анализ стоимости запросов. Для этого нам нужно будет потратить много времени на измерение стоимости каждой перестановки запроса и установку правил для стоимости сложности, что еще больше увеличит время разработки и сложность.

3. Несоответствие инженерной подгонки

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

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

Заключение

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

Это не значит, что мы не сможем использовать его в будущем.

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

TL;DR

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

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

Мы нанимаем! Хотите иметь возможность принимать подобные важные инженерные решения в самом начале существования компании? Посетите https://defty.com/jobs.html, чтобы узнать, как присоединиться к команде, и узнать о больших преимуществах, которые мы предлагаем.