Покройте свой BaaS: Firebase, GraphQL и свой следующий проект

Покройте свой BaaS: Firebase, GraphQL и свой следующий проект

Firebase был запущен в 2011 году. Это было, по большинству показателей, более простое время: Node.js был не по годам развитым двухлетним ребенком, Вольф Блитцер никогда не произносил слово «киска» в эфире, а работа в Интернете в реальном времени была сложной задачей. . Firebase изменила одну из этих вещей и, таким образом, стала нарицательным для разработчиков, которые ищут серверную часть как услугу (BaaS) со святой троицей - быстрым, дешевым и простым.

Перенесемся в 2017 год, и Google (владеющий Firebase (владеющий рынком BaaS)) развивает свой продукт баз данных в полноценную (в основном мобильную) платформу для создания приложений. Поскольку большинство конкурирующих продуктов BaaS покинули эту смертельную катушку, варианты для начала нового проекта следующие: Сделайте массу вещей самостоятельно или используйте Firebase.

Но вещи, как они обычно делают, меняются: в динамичном мире 17-х годов у разработчиков есть варианты. В этом посте я собираюсь сравнить Firebase с одним из этих вариантов: платформой GraphQL как услуги под названием scaphold.io.

GraphQ-что?

Graph Query Language или GraphQL - это попытка Facebook устранить недостатки RESTful API. Этот пост не является подробным обзором GraphQL, но для целей сравнения представьте сервер GraphQL как старого телефонного оператора. Он располагается поверх серверной части вашего приложения (а не вместо нее, как я изначально думал) и знает, где найти различные сущности, составляющие схему вашего приложения (например, User, Group, PokeMan ¹.). Когда ваш клиент выполняет вызов, вместо того, чтобы напрямую обращаться к определенной конечной точке, он вызывает GraphQL, который направляет его вызов на нужные данные. Значение этого может быть неочевидным, но я думаю, что это станет более понятным при сравнении с Firebase.

Как и Firebase, GraphQL может снизить зависимость клиентов внешнего интерфейса от управления сервером. Однако, в отличие от Firebase, вам нужно создать сервер GraphQL, и именно здесь приходит новое поколение BaaS. По сути, GraphQL-aaS выполняет всю внутреннюю операцию, позволяя создавать клиенты GraphQL так же легко, как (или проще чем) Firebase будет.

Сравнение

Сравнения писать сложно, поэтому я сделаю их простыми и дам жесткие рекомендации для разных сценариев использования. В порядке добросовестности я создал ровно по одному приложению для Firebase и Scaphold.io (GraphQL-aaS).

(Примечание: Scaphold - не единственный GraphQL-as-a-Service в городе, это единственный, который я использовал. Их главный конкурент, Graph.cool, предлагает продукт, который отличается из Firebase так же, как и Скапхолд.)

Создаете приложение только для мобильных устройств? Firebase

За последние год или два Firebase добавила в свой продукт около полдюжины крутых новых функций: интегрированная аналитика, push-уведомления и даже A / B-тестирование приложений, и все это с вашей консоли Firebase. магазин, на который разработчик мог надеяться.

То есть мобильный разработчик. Если в вашем приложении есть значительный компонент веб-приложения (или, я думаю, Electron или React Native), большинство из этих функций вам не будут доступны. Учитывая параллельный толчок Google к прогрессивным веб-приложениям, вызывает разочарование то, насколько непрозрачным является Firebase в плане развития Интернета. Из-за этого недостатка функций веб-SDK разработчики веб-приложений, рассматривающие Firebase в 2017 году, по сути, рассматривают набор функций 2013 года. Если вы веб-разработчик, который ценит продукт, активно разрабатываемый его владельцами, это затрудняет продажу Firebase.

Но если вы являетесь мобильным разработчиком, переходите на Firebase. Хотя Скапхолд и другие делают мобильные устройства проще, чем делают это сами (например, push-уведомления на Android и iOS), сервисы меньше, моложе и, по крайней мере, по функциям, не могут удерживать (* кхм *) свечка в пользу Firebase (sry).

Есть реляционные данные? GraphQL

Спросите любого, кого когда-либо одевал какой-то парень по имени Уолтер ² на HackerNews или StackOverflow: в дебатах NoSQL против SQL вспыхивают страсти. Поскольку у меня есть кошка, которая зависит от меня, я не рискую своей шеей, чтобы поддержать то или другое здесь. Но, поскольку разновидность схемы NoSQL в Firebase создает довольно серьезные проблемы с реляционными данными, нам придется немного разобраться в этом моменте.

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

Firebase требует (и, таким образом, поощряет) другой подход: чтобы получить пользователей группы, вы должны получить эту группу по ее идентификатору, а затем в клиенте отправить новые запросы для профиля каждого пользователя. Как вы понимаете, после первых нескольких взаимосвязей в вашей схеме вы совершаете довольно много обращений к серверу (хотя Firebase работает быстро, и это, кажется, хорошо работает на практике).

Однако настоящая проблема заключается в управлении государством. Когда клиент несет ответственность за столь сложную логику выборки, пространство для ошибок значительно расширяется. Для меня это в конечном итоге было не так похоже на то, что Firebase абстрагируется от бэкэнда, а больше похоже на то, что он помещает бэкэнд в клиент.

Вот где сияет GraphQL. Запрос GraphQL для группы и всех ее пользователей очень прост:

group {
  users {
   edges {
     node {
       firstName
       lastName
       email
      }
    }
  }
}

Не позволяйте отступу ввести вас в заблуждение: это не ад обратного вызова. Вместо этого, верный своему тезке, GraphQL позволяет вам концептуализировать вашу схему как реальный граф, где сущности (User, Group) являются узлами, а отношения - границами. За один проход к серверу вы можете пересечь границы взаимосвязи и получить точно данные, которые вам нужны.

Проекты только начинают использовать возможности, которые это дает клиентским технологиям. Например, с помощью Facebook Relay вы просто указываете свое приложение на конечную точку GraphQL и объявляете, какие части данных нужны каждому компоненту, позволяя библиотеке обрабатывать все остальное. Представьте себе: получение данных для всего вашего приложения без написания ни одной строчки асинхронного кода.

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

Итак, любое приложение с реляционной схемой должно придерживаться GraphQL-aaS.

Нужен запрос? GraphQL

Проект Firebase - это не набор документов JSON, а один большой JSON (1BAJ). В терминах Javascript вместо этого:

Users: [
 { id: 1, name: 'brandon' },
 { id: 2, name: 'emily' }
]

У вас есть это:

Users: { 
  1: {
    name: 'brandon'
  },
  2: {
    name: 'emily'
  }
}

Это несколько влияет на опыт разработки. Во-первых, возможности запросов Firebase ограничены. Если позаимствовать из их документов, если у вас есть коллекция динозавров со свойством height, наиболее близким к query будет сортировка коллекции по высоте и получение n лучших результатов. Если вам нужно больше, вам нужно будет загрузить данные в состояние клиента и запросить его локально - другими словами, больше места для ошибки. Хотя возможность сортировать динозавров по высоте составляет около 80% моих запросов, это делает последние 20% сложными.

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

Сравнивая Scaphold или GraphQLaaS, писать особо нечего, потому что запросы к простому SQL так же мощны, как и раньше. Фильтровать, сортировать и агрегировать записи так же просто, как написать любой другой запрос. Более того, GraphQL не ограничивается выборкой данных из базы данных, поэтому можно интегрировать другие API в ваши вызовы выборки данных - например, получение координат и их разрешение на адрес через API Google Places в одном запросе вашего GraphQL. конечная точка.

Если ваши запросы выходят за рамки определения 5 самых высоких динозавров, используйте GraphQLaaS.

Хотите типобезопасность? Вероятно, GraphQL

Этот момент ближе к жеребьевке, чем несколько предыдущих. С одной стороны, система авторизации и проверки Firebase довольно мощная. Используя язык, подобный Javascript, вы можете определить, разрешена ли операция чтения / записи, на основе любого количества произвольных критериев. Является ли значение какого-либо поля в другой части базы данных 5, а должно быть 6? В чтении отказано. Представляет ли этот пользователь строку из 17 символов, а вы хотели 16? В записи отказано. Это так просто.

Scaphold, с другой стороны, не предлагает особых возможностей для проверки данных, кроме примитивных типов (число, логическое значение и т. Д.), Базовых структур (например, JSON, List) и перечислений строк ('CAT' или 'DOG'). При наличии и ролевых, и реляционных разрешений на уровне строк авторизации должно хватить для большинства нужд, но она все же не такая гибкая, как Firebase.

Тем не менее, с учетом всего сказанного, я думаю, что в данном случае рекомендую GraphQLaaS. Хотя система проверки / авторизации Firebase определенно более мощная, она также (а) сложнее в реализации и (б) необязательна.

Ожидается сложность, учитывая, что это проприетарный язык. Но графический интерфейс построения схем Scaphold упрощает реализацию достаточно хорошей проверки / авторизации. Тем не менее, поскольку это не является обязательным, я предполагаю, что в среднем он обеспечивает большую стабильность, чем система Firebase.

Как говорят о разработке или модульном тестировании: лучшая система - это та, которую вы будете использовать, а обязательная типизация GraphQLaaS - лучший вариант для большинства, чем сложность и необязательность Firebase.

Нужен в реальном времени? Firebase

Хотя Scaphold и другие GraphQL-aaS поддерживают подписки в реальном времени (которые, следует отметить, не то же самое, что запросы в реальном времени), простота пока не может сравниться с Firebase. Это неудивительно: команда Firebase создала продукт с нуля с учетом подписок, тогда как GraphQL стремился решить более широкий круг проблем.

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

Вывод

Для Wayhome, Scaphold и GraphQL были легким выбором. Наши данные были слишком реляционными, чтобы надежно управлять ими на клиенте, даже с такими мощными инструментами, как Redux и MobX. В сочетании с Relay GraphQL позволяет нам избавиться почти от всего нашего управления состоянием на стороне клиента, существенно снижая риск скрытых ошибок.

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

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

1:… [sic]. назад
2: То, что Уолту не хватает в социальной милости, он восполняет СТАВОЙ репутацией ³. назад
3: И отредактировано 143 412 сообщений! назад