Google App Engine vs Firebase
J'essaie de décider quelle option choisir. (ou un autre si c'est mieux) Ceci est pour une application de type messagerie où le volume de notifications et d'écritures dans la base de données sera élevé.
Option 1 - Google App Engine utilisant des points de terminaison cloud et des banques de données cloud
Avantages:
- Capable de construire une API comme je le voudrais.
- Évolutif
Les inconvénients:
- Plus de travail pour mettre en place un système de notification. (Ce qui finira par être Firebase Cloud Messaging)
Option 2 - Firebase
Avantages:
- Capable d'utiliser la base de données Firebase, l'authentification utilisateur Firebase, la messagerie Cloud Firebase (notifications)
- Statistiques d'utilisation détaillées pour tous les appareils
Les inconvénients:
- Aucune API
Option - Serait-il possible de combiner Google Cloud Endpoints et Firebase?
Tout d'abord, jetez un coup d'œil au tableau ici des documents Google pour une comparaison et un contraste remarquables des différents services de back-end pour applications mobiles proposés. Voici le tableau:
Mes opinions personnelles sont (Mise à jour):
Option 1 - Google App Engine utilisant des noeuds finaux Cloud et un magasin de données Cloud.
Avantages:
- Vous en apprendrez beaucoup plus sur le modèle reposant qui écrit votre propre API. Vous serez également obligé d'apprendre à passer des appels api reposants (avec iOS ou Android), une compétence très précieuse dans le secteur. En quelque sorte, Firebase fait tout pour vous et vous ne l'apprendrez jamais.
- Vous devez l'écrire vous-même, mais vous pouvez être vraiment créatif avec vos méthodes d'API, Google Cloud Messaging et le type de méthodes que vous créez. Ils peuvent vraiment tout faire et se connecter à n’importe quelle base de données (par exemple, MySQL, SQL Server, Datastore). Dans Firebase, vous devez utiliser leur base de données json. Je ne recommande pas d'utiliser une base de données SQL pour une application, mais différentes personnes ont des besoins différents.
Les inconvénients:
- Cela prend plus de travail et il peut être difficile au début de passer à la vitesse supérieure. Ce n'est pas comme une base de données relationnelle comme SQL.
- En outre, j’ai le sentiment qu’il existe quelques domaines dans lesquels vous pouvez vous "tirer une balle dans le pied" en créant des méthodes et des requêtes très inefficaces et prenant donc beaucoup de temps.
- Une chose qui est ennuyeuse pour les nouvelles applications est la mise à l'échelle automatique dans GAE. En bref, si personne ne frappe votre API pendant environ 15 minutes, toutes les instances sont fermées. Une fois qu'un nouvel appel est effectué, la sauvegarde d'une instance et l'exécution de votre méthode API prend un temps considérable. Cela peut être gênant pour les nouvelles applications, car les nouveaux utilisateurs peuvent penser qu'il y a quelque chose qui ne va pas dans l'application et donc qu'ils peuvent ne plus l'utiliser. Vous pouvez effectuer une mise à l'échelle manuelle, mais cela coûte de l'argent d'avoir une instance tout le temps (à l'heure actuelle, environ 27 €/mois de mes applications facturées). Voir mon post ici pour plus d'informations sur cette question et un solution je suis venu avec.
Option 2 - Firebase
Avantages:
- Il est conçu pour être facile à utiliser pour les débutants et il existe de nombreux tutoriels/cours sur Firebase pour effectuer les tâches courantes que vous souhaitez effectuer, telles que l’envoi de notifications Push et la synchronisation des données.
- Contrairement à GAE, il est rapide. Aucune instance de mise à feu. Cela le rend idéal pour les nouvelles applications qui veulent impressionner les utilisateurs avec leurs données rapides.
- Vous pouvez apprendre à vous familiariser avec des choses complexes comme les adaptateurs (Android) et les réseaux (dans les applications mobiles) en vous fiant aux classes Firebase. Peut-être que c'est un peu plus sympathique? Encore une fois, la documentation est excellente et prête à l'emploi. Je pense qu'il y a moins de chances de se tirer une balle dans le pied en écrivant des requêtes inefficaces.
Les inconvénients:
- Firebase est lourd sur le code client. Si vous voulez un Android et une application iOS, vous devez écrire beaucoup de code client pour les deux. Dans GAE, une grande partie de cette logique est abstraite dans l'application GAE. Mais cela pourrait être un avantage si vous ne voulez pas vraiment que les administrateurs de bases de données soient dans votre application et que vous ayez juste iOS + Android qui connaissent Firebase. Mais pour moi, c’était un coup d'arrêt.
- Et si Firebase suivait le chemin de Parse.com ... où Facebook a annoncé qu'il ne le supporterait plus. Ce serait vraiment nul! Vous seriez bloqué dans Firebase et n’auriez développé aucune connaissance en programmation sur la création d’une API reposante. Cependant, en raison des investissements importants de Google dans Firebase et de la mise à niveau de GCM vers Firebase Cloud Messaging, il est clair qu'ils ont de grands projets pour Firebase et cela ne va nulle part. Donc, je ne pense pas que cela compte comme un "con" mais gardez cela à l'esprit?
Lisez plus dans le lien pour éventuellement les combiner.
Je suis surpris que de nombreuses discussions sur Firebase (y compris la question et la réponse ci-dessus) ne mentionnent pas ce qui, à mes yeux, constitue une différence très importante: le prix.
Voici le prix Firebase calendrier.
Il peut être difficile de les comparer, mais mon interprétation est que Firebase est très coûteux.
Et cela ne devrait pas surprendre. GAE et le magasin de données doivent concurrencer des services similaires d'Amazon, Microsoft, etc., et la concurrence est féroce. Oui, ces services ne sont bien sûr pas aussi génériques que l'infrastructure et le SQL, mais ils semblent être suffisamment proches pour que les prix restent compétitifs.
Firebase, d’autre part, est un service premium qui rivalise avec d’autres services d’arrière-plan tels que Parse, et une fois que vous aurez décidé de l’utiliser, je pense qu’il serait très difficile de changer de fournisseur. Il n’est donc pas surprenant que Google pousse si durement Firebase: ils vont probablement gagner beaucoup d’argent car ils peuvent le payer à un prix aussi élevé.
À mon avis, le résultat de ceci est que Firebase est un bon choix pour les services à faible volume et à marge élevée, mais si vous envisagez de créer un service typique, axé sur le consommateur et financé par la publicité, qui dépendrait d'un volume important pour gagner de l'argent, alors le coût de Firebase peut tuer votre profit.
Ajout 2017-10 :
J'ai de nouveau regardé Firebase avec la sortie récente de Firestore.
Je pense qu’il est important de prendre conscience d’un autre problème: utiliser Firestore pour un Android app signifie utiliser la bibliothèque cliente Firebase, qui dépend fortement des services Google Play, ce qui signifie que vous ne pouvez pas effectuer de déploiement. appareils non Google, y compris les tablettes Amazon Fire et (je crois) tout le marché chinois.
Une chose que j’ai récemment apprise alors que je me débattais pour trouver une solution, c’est que firebase n’offre aucune solution de contournement des notifications de périphérique à périphérique; Bien qu'il offre une notification Push de serveur à périphérique et qu'il est assez facile à configurer. Mais l’ancienne absence de fonctionnalités est très importante et il existe une théorie du complot selon laquelle ils essaient de vous pousser à utiliser d’autres produits Google.
Ou peut-être, comme il n'a pas été développé au début, ils l'ont gardé. J'ai pensé que le moteur d'applications est un moyen de connecter la base de feu et les périphériques à cet effet. Je m'approcherais donc de la combinaison de Firebase et d'autres produits Google dans ce cas moteur d'application . Si vous envisagez de faire davantage de traitement d’arrière-plan, tel que le traitement d’images, etc., alors vous vous penchez sur moteur de l’application et moteur de calcul à coup sûr, ce qui pourrait être intégré à Firebase, ce qui donnerait une solution dorsale extrêmement puissante.