Google App Engine против Firebase

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

Вариант 1 - Google App Engine с использованием Cloud Endpoints и Cloud Datastore
Плюсы:

  • Способна построить API так, как хотелось бы.
  • Масштабируемость

Минусы:

  • Больше работы по внедрению системы уведомлений. (Который в конечном итоге будет Firebase Cloud Messaging)

Вариант 2 - Firebase
Плюсы:

  • Возможность использования базы данных Firebase, аутентификации пользователей Firebase, облачных сообщений Firebase (уведомлений)
  • Подробная статистика использования для всех устройств

Минусы:

  • Нет API

Вариант 3 - Можно ли совместить конечные точки Google и Firebase?

Ответы

Ответ 1

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

enter image description here

Мои личные мнения (Обновлено):

Вариант 1 - Google App Engine с использованием Cloud Endpoints и Cloud Datastore
Плюсы:

  • Вы узнаете намного больше о спокойном шаблоне, пишущем ваш собственный API. Вы также будете вынуждены научиться делать спокойные звонки api (с iOS или Android), и это очень ценное умение в отрасли. Firebase делает все для вас, и вы никогда не узнаете этого.
  • Вы должны написать это самостоятельно, но вы можете стать действительно творческими с помощью методов API и облачных сообщений Google и типа методов, которые вы создаете. Они могут действительно что-то делать и подключаться к любой базе данных (например, MySQL, SQL Server, Datastore). В Firebase вы должны использовать свою базу данных на основе json. Я не рекомендую использовать базу данных SQL для приложения, но разные люди имеют разные потребности.

Минусы:

  • Это требует больше работы, и обертывание головы вокруг хранилища данных может быть затруднено вначале. Это не похоже на реляционную базу данных, такую как SQL.
  • Также я чувствую, что есть несколько областей, где вы можете "стрелять себе в ногу", создавая методы и запросы, которые очень неэффективны и, следовательно, занимают много времени.
  • Одна вещь, которая раздражает новые приложения, - это автоматическое масштабирование в GAE. Короче говоря, если никто не нападает на ваш API около 15 минут, все экземпляры отключены. После создания нового вызова требуется значительное количество времени, чтобы запустить резервное копирование экземпляра и выполнить свой метод API. Это может раздражать новые приложения, потому что новые пользователи могут что-то не так с этим приложением, и, следовательно, могут перестать его использовать. Вы можете делать ручное масштабирование, но тогда это стоит денег, чтобы иметь экземпляр все время (на момент написания около 27 долларов США в месяц из моих выставленных счетов). См. Мой пост здесь для получения дополнительной информации по этому вопросу и решения, которые я придумал.

Вариант 2 - Firebase
Плюсы:

  • Это сделано для того, чтобы быть легким в использовании для новичков, и есть обширные учебники/курсы по Firebase, чтобы делать те популярные вещи, которые вы хотите сделать, например, отправлять push-уведомления и синхронизировать данные.
  • В отличие от GAE, он быстро выходит из строя. Нет обстрелов. Это отлично подходит для новых приложений, которые хотят поразить пользователей своими быстрыми данными.
  • Вы можете обойти изучающие сложные вещи, такие как адаптеры (Android) и сети (в мобильных приложениях), и просто полагаться на классы Firebase. Может быть, это немного дружелюбнее? Опять же, документация отличная и готовая, я думаю, что есть меньше шансов застрелить себя в ноге, написав неэффективные запросы.

Минусы:

  • Firebase сильно зависит от кода клиента. Если вы хотите Android и приложение для iOS, вам нужно написать много клиентского кода для обоих. В GAE большая часть этой логики абстрагируется в приложении GAE. Но это может быть преимуществом, если вы действительно не хотите, чтобы администраторы баз данных находились в вашем приложении, и у меня есть только разработчики Android iOS +, которые знают Firebase. Но для меня это был большой поворот.
  • Что, если Firebase идет по пути Parse.com... Где Facebook объявила, что больше не будет ее поддерживать. Это действительно сосать! Вы были бы заперты в Firebase и не разработали какие-либо знания в программировании о том, как создать надежный API. Однако из-за того, что Google тяжело инвестировал в Firebase и теперь обновляет GCM до Firebase Cloud Messaging, ясно, что у них большие планы для Firebase, и он никуда не денется. Поэтому я не думаю, что это считается "кон", но помните об этом?

Подробнее см. В ссылке, чтобы, возможно, объединить их.

Ответ 2

Я озадачен тем, что многие обсуждения Firebase (включая вопрос и ответ выше) не могут упомянуть, что для меня очень важная разница: цена.

Вот график цен Firebase.

Вот цены Datastore и GAE.

Это может быть сложно сравнить, но моя интерпретация заключается в том, что Firebase очень дорогая.

И это не должно удивлять. GAE и хранилище данных должны конкурировать с аналогичными услугами от Amazon, Microsoft и т.д., И конкуренция жесткая. Да, эти службы не такие общие, как инфраструктура и SQL, конечно, но они кажутся достаточно близкими, чтобы цены оставались конкурентоспособными.

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

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

2017-10 Дополнение:

Я снова посмотрел на Firebase с недавним выпуском Firestore.

Я думаю, что важно знать другую проблему: использование Firestore для Android-приложения означает использование клиентской библиотеки Firebase, которая сильно зависит от сервисов Google Play, а это значит, что вы не можете развернуть их на устройствах, отличных от Google, включая табло Amazon Fire и (Я считаю) весь китайский рынок.

Ответ 3

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

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