Quelle est la taille de Parse?

J’ai envisagé d’utiliser le service de Parse.com pour mon backend, mais je suis sceptique quant à son évolutivité.

Peut-il vraiment gérer plusieurs milliers d’utilisateurs simultanés? Si ce n’est pas le cas, y a-t-il une bonne façon de s’en éloigner?

Je sais que la question est peut-être ancienne, mais je voulais donner mes 2 cents pour les autres qui envisagent peut-être l’parsing …

Dans le plus simple des scénarios, l’parsing peut bien fonctionner. Dès que vous avez besoin de passer à des requêtes plus complexes, je n’ai personnellement trouvé que des maux de tête.

  1. Les requêtes sont limitées à 1000 enregistrements. Initialement, vous pouvez penser que ce n’est pas un problème jusqu’à ce que vous commenciez à traiter des sous-requêtes et que vous réalisiez que des données étranges sont renvoyées car la sous-requête coupe les enregistrements sans avertissement ni erreur. (FYI, la valeur par défaut est 100 enregistrements, sauf si vous spécifiez une limite allant jusqu’à 1000, le problème est encore pire si vous ne faites pas attention).

  2. Pour une raison étrange, il existe une limite au nombre de fois où vous pouvez émettre une requête de comptage en min. (et cette limite semble être vraiment faible). Soyez prêt à essayer de limiter votre code afin de ne pas atteindre cette limite, sinon des erreurs sont générées.

  3. Les tâches en arrière-plan ne sont pas exécutées de manière fiable. J’ai eu un job en tâche de fond à exécuter toutes les 5 minutes, et il faut parfois plus de 20 minutes avant que le job ne soit lancé.

  4. Beaucoup de timeouts. C’est celui qui me donne le plus de brûlures d’estomac. R. Si vous avez une fonction cloud qui prend du temps à traiter, vous avez environ 6 ou 7 secondes pour le faire ou cela vous coupe la parole.
    B. J’ai l’impression qu’il y a une instabilité générale avec le système. Périodiquement, je rencontre des problèmes qui semblent durer environ une heure environ, où les délais d’attente se produisent plus fréquemment (et avec des fonctions relativement simples qui devraient revenir immédiatement).

Je regrette totalement ma décision d’utiliser l’parsing, et je fais tout mon possible pour que l’application rest en vie assez longtemps pour que nous puissions obtenir un financement, afin que nous puissions quitter la plateforme. Si quelqu’un a de meilleures alternatives pour parsingr, je suis tout ouïe.

[Edit: après trois années incroyables avec l’équipe, j’ai décidé de passer à autre chose et je ne suis plus un employé de Parse ou de Facebook. L’équipe est entre de bonnes mains et a fait des choses incroyables. L’ensemble du backend a été réécrit pour améliorer considérablement les performances et la fiabilité. La feuille de route est incroyable et j’attends de grandes choses de la part de l’équipe. Au moment de mon départ, Parse a alimenté plus de 600 000 applications et servi chaque jour un nombre impressionnant de demandes. Si chaque message devait être envoyé à une personne unique, ils pourraient former le quasortingème plus grand pays du monde en une journée. Pour une aide future avec Parse, veuillez envoyer des questions ici avec la balise parse.com ou publier des messages dans le groupe Google de développeurs d’parsing.]

Divulgation complète: je suis un ingénieur de Parse.

Parse héberge déjà des milliers d’ applications , sans parler des utilisateurs. Lorsque nous avons quitté la version bêta fin mars, nous avons annoncé plus de 10 000 applications exécutées sur Parse avec un taux de croissance mensuel de 40%. Parse est dirigée par une équipe de classe mondiale, avec de nombreuses années d’expérience dans le domaine du Big Data et du trafic à haut volume.

Nous accueillons votre trafic à arm ouverts; vous serez en compagnie de grandes équipes comme Band of the Day et Hipmunk . Nous sums tellement confiants dans nos services que nous avons conçu notre système d’ exportation en un seul clic pour que les gens comme vous puissent essayer Parse sans risque. Si vous pensez que Parse ne répond pas à vos attentes en matière de performance, nous vous enverrons volontiers toutes vos données intactes.

Nous avons choisi Parse comme backend pour notre application. Conclusion: À NE PAS FAIRE

La stabilité est un désastre, la performance est également un désastre, tout comme le support (probablement parce qu’ils ne peuvent pas vraiment vous aider car tous les problèmes ne sont pas reproductibles).

Exécuter même la plus simple des fonctions peut conduire à des délais aléatoires dans Parse (je parle par exemple de simples appels de connexion à PFUser):

Error: Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo=0x17e42480 {NSErrorFailingURLSsortingngKey=https://api.parse.com/2/client_events, NSErrorFailingURLKey=https://api.parse.com/2/client_events, NSLocalizedDescription=The request timed out., NSUnderlyingError=0x17d10e60 "The request timed out."} (Code: 100, Version: 1.2.20) 

Nous rencontrons des délais d’attente quotidiennement, et c’est avec une application que nous testons avec 10 utilisateurs maximum!

C’est le retour typique que nous obtenons tout le temps, à des moments complètement arbitraires et impossibles à reproduire. Appel d’une fonction Cloud Code qui effectue quelques requêtes et quelques insertions:

  {"code":124,"message":"Request timed out"} 

Essayez la même chose 10 minutes plus tard et elle fonctionne en moins d’une seconde. Réessayez 20 minutes plus tard et 30 secondes sont nécessaires.

Comme il n’y a pas de transactionnalité, c’est vraiment très amusant lorsque vous stockez par exemple 3 objects dans 1 fonction Cloud Code, où Parse décide de sortir de la fonction aléatoirement après avoir par exemple enregistré 2 des 3 objects. Idéal pour garder votre firebase database cohérente.

Les “meilleurs” que nous ayons obtenus Attention, il s’agit des données réelles provenant d’une fonction Cloud Code:

  {"code":107,"message":"Received an error with invalid JSON from Parse: \n\n\n We're sorry, but something went wrong (500)\n \n\n\n\n \n 
\n

We're sorry, but something went wrong.

\n

We've been notified about this issue and we'll take a look at it shortly.

\n
\n\n\n"}

Ce que je décris ici n’est pas quelque chose qui arrive une fois dans une lune bleue dans notre projet. À l’exception des 500 erreurs (que j’ai rencontrées deux fois par mois), toutes les autres sont vues quotidiennement.

Donc, oui, il est très facile de démarrer, mais vous devez prendre en compte le fait que vous travaillez sur une plate-forme instable, alors assurez-vous d’avoir vos tentatives et vos systèmes de sauvegarde exponentiels, car vous en aurez besoin!

Ce qui m’inquiète le plus, c’est que je n’ai aucune idée de ce qui arriverait une fois que 20 000 personnes utiliseraient mon application sur ce backend.

modifier:

En ce moment, j’ai ceci quand je fais un login PFUser:

 Error: Error Domain=PF_AFNetworkingErrorDomain Code=-1011 "Expected status code in (200-299), got 502" UserInfo=0x165ec090 {NSLocalizedRecoverySuggestion=

502 Bad Gateway

The server returned an invalid or incomplete response. , PF_AFNetworkingOperationFailingURLResponseErrorKey= { URL: https://api.parse.com/2/get } { status code: 502, headers { "Cache-Control" = "no-cache"; Connection = "keep-alive"; "Content-Length" = 107; "Content-Type" = "text/html; charset=utf-8"; Date = "Mon, 08 Sep 2014 13:16:46 GMT"; Server = "nginx/1.6.0"; } }, NSErrorFailingURLKey=https://api.parse.com/2/get, NSLocalizedDescription=Expected status code in (200-299), got 502, PF_AFNetworkingOperationFailingURLRequestErrorKey= { URL: https://api.parse.com/2/get }} (Code: 100, Version: 1.2.20)

N’est-ce pas génial?

Si vous écrivez une petite application simple (ou un prototype jetable) avec peu ou pas de logique sur le backend, allez-y, mais pour quelque chose de plus grand / évolutif, mieux vaut l’éviter, je peux le dire directement. Tout fonctionne bien avec la gestion des utilisateurs, les notifications push, le stockage abstrait et ce qui ne l’est pas. A savoir que je développais le backend pour une application sur Parse, les clients étaient tellement intéressés car cela sonnait cool et prometteur (marketing fort je suppose), acheté par Facebook, mais quelques semaines dans la production de problèmes majeurs avec la plate-forme a commencé à apparaître, ce qui devrait être une application simple s’est avéré être un cauchemar à développer et à mettre à l’échelle.

Le résultat / la conclusion du projet: – brisé la fenêtre temporelle pour une application relativement simple – il aurait dû durer 2 à 3 mois, il a duré près d’un an et n’est toujours pas stable / fiable, si nous l’utilisions d être fait dans la fenêtre de temps pour une raison certaine j’ai fait un projet de démonstration similaire en 5-10 jours avec une stack de nœuds personnalisée – perdu la confiance du client, ils sont en train de refaire l’application avec une autre équipe qui utilisera une stack personnalisée – des tonnes d’argent perdues pour avoir brisé la fenêtre de temps et essayer de le faire fonctionner – ont fait tellement d’heures supplémentaires que cela a commencé à réfléchir sur ma santé – ne jamais utiliser une plate-forme / solution qui promet de tout avoir / essayé stack

Premièrement, les problèmes de stabilité et les défaillances constantes de la plate-forme telles que les temps d’arrêt des serveurs et les erreurs aléatoires, mais tout est réglé (début 2014), mais les problèmes suivants persistent:

  • vous ne pouvez pas déboguer votre code, du moins pour le moment (il existe des moyens de le faire fonctionner avec un serveur de noeud supplémentaire et une bibliothèque obscure)
  • les limites sont ridicules, une plate-forme évolutive capable de faire 50 à 60 API par seconde (ou plus selon votre abonnement), ce qui n’est pas aussi bas que cela jusqu’à ce que vous commenciez à faire des tests de contrainte. va constamment échouer
  • Les appels d’API sont mesurés comme suit: appel d’une fonction serveur (travail de Parse) – 1 appel, interrogation de la firebase database – 1 appel, autre requête (car ils ne disposent pas d’un système de requête avancé / complexe) schéma de firebase database, vous réaliserez très vite ce que je veux dire) – 1 appel, si vous avez besoin de plus de 1000 requêtes, devinez quoi – interrogez à nouveau, etc., interrogez le compte (vous devez le faire comme une requête séparée) qui est non fiable (tend à renvoyer une approximation pour quelques milliers d’entrées)
  • créer / sauvegarder ~ 1000 objects simples est une contrainte pour la plate-forme / firebase database, supprimant plus de 1000 objects, ce qui est ridiculement rapide pour les bases de données normales, mais sur Parse, cela prend généralement 5 à 10 minutes il supprime de plus près 20 objects par lot)
  • pas moyen d’utiliser la plupart des paquets npm (seulement les plus purs en incluant la source directement)
  • Si vous allez lire les forums Parse, vous verrez les utilisateurs baisser constamment la note de l’équipe Parse pour le manque de fonctionnalités de la plate-forme et avoir besoin de passer par des implémentations de logique arbitraire comme chercher des entrées aléatoires et similaires
  • ils supportent l’intégration de Ssortingpe, mais si vous voulez utiliser Paypal ou un autre service de paiement (nous avons décidé d’utiliser Paypal parce qu’il offre un support pays supérieur à Ssortingpe), vous ne pouvez pas le faire sur Parse. utiliser un serveur séparé pour le retirer
  • pas de moyen facile de synchroniser les utilisateurs et de gérer les problèmes de concurrence, vous devez utiliser des hacks et une logique amusante que vous n’utiliseriez pas ou admettre ne jamais utiliser nulle part
  • voulez plus de 100, sans parler de 1000 utilisateurs simultanés, bonne chance
  • Lorsque vous souhaitez connaître le nombre d’entrées dans une table, vous pouvez limiter la possibilité d’appeler la requête count, ce qui est amusant, non documenté et totalement ridicule, et renvoie finalement un nombre approximatif
  • la modularité est étrangère à la plate-forme, les fonctions que vous appelez à partir de vos tâches ne peuvent durer plus de quelques secondes (7 secondes, je pense) et lorsque vous prenez en compte le temps de requête, une logique complexe
  • Vous pouvez avoir quelque chose comme des tâches Cron mais elles ne peuvent pas durer plus de 15 minutes (en raison de la faible performance de la plate-forme comme plusieurs requêtes très, très courtes), elles sont limitées à 2-3-4 tâches simultanées selon votre frais d’abonnement, et avoir un système de planification très limité / médiocre en place (par exemple, vous ne pouvez pas le modifier à partir de votre code, il est très limité, donc vous devez utiliser des hacks pour exécuter le même travail à deux moments précis de la journée ou quelque chose de similaire) , il ne peut pas regarder pour gagner du temps, etc.)
  • Lorsque vous obtenez une erreur sur le serveur, il peut être totalement trompeur, consultez les forums pour cela, ne vous souvenez plus de rien
  • Les notifications push sont régulièrement en retard jusqu’à 20-30 minutes

Un exemple arbitraire: vous voulez extraire un élément aléatoire de leur firebase database, votre application appelle un travail qui le fournira (1 appel API), le travail interroge la firebase database, mais vous devez effectuer 2 appels, d’abord à obtenir le compte des éléments (1 appel API) puis un second pour obtenir un élément aléatoire (1 appel API), il s’agit de 3 appels API pour cette fonctionnalité, et avec 60 demandes par seconde, 20 utilisateurs peuvent effectuer cet appel à un certain temps avant d’atteindre la limite de la demande et la plate-forme tourne mal, après avoir inclus d’autres utilisateurs parcourant les écrans des applications, vous voyez où cela mène …

Si c’était une bonne chose, ne serait-ce pas Facebook qui l’aurait acheté à chaque fois qu’il l’utilisait pour certaines de leurs applications? Je suggérerais 3 choses: – Premièrement – n’écoutez pas le gars de Parse, c’est sa plate-forme, il doit la promouvoir, écouter les gens qui l’utilisent pour l’utiliser.
– deuxièmement – si vous avez besoin d’une plate-forme sérieuse et évolutive et que vous ne voulez pas vous lancer dans la personnalisation, optez pour les services Amazon Cloud ou quelque chose de similaire testé et fiable – restz loin de la plate-forme si vous n’allez pas alors embaucher un développeur backend pour le projet, il sera moins cher et vous aurez une solution de travail à la fin

J’ai passé la journée à regarder parse.com et voici mon opinion actuelle basée sur ce que j’ai trouvé (gardez à l’esprit que je n’ai qu’une expérience très courte du développement avec le SDK pour le moment).

Parse.com a clairement des points positifs très intéressants, ce qui explique pourquoi je me suis penché sur la question, mais pour des raisons de débats, je me concentrerai sur le fait que les points positifs sont tous sur leur site Web. (Bravo parse.com pour avoir tenté de résoudre un si grand problème!) …

  • Dans les témoignages, Hipmunk est le plus grand nom que je dirais. Il est répertorié comme une application qui utilise la partie données du SDK. Sans approcher les développeurs de Hipmunk, je ne peux pas savoir avec certitude, mais je ne peux pas les imaginer stocker TOUTES leurs données dans le cloud parse.com.
  • Après avoir essayé et parcouru la plupart des applications répertoriées. Aucun ne se démarque vraiment comme étant extrêmement dépendant d’un serveur principal, il est donc impossible de savoir si l’évolutivité a été résolue à l’aide de parse.com.
  • Le site Web indique 40 000 applications et comptage. Je pense (mais je ne sais pas) que, sur la base de la galerie d’applications, ce chiffre est basé sur la quantité d’applications dans leur base d’utilisateurs, et non pas de véritables applications de production en direct dans les magasins d’applications. La galerie d’applications comporterait beaucoup plus de grands noms si de nombreuses applications utilisaient parse.com.

Parse.com est un concept très nouveau et très différent même pour ses plus proches rivaux. Donc, sans preuve concrète de son évolutivité et de sa stabilité (et de tout le rest), il est très difficile pour un développeur de projet d’envisager de s’y engager, car les enjeux sont trop importants.

J’ai effectué des tests pour ma propre réponse à une question similaire et cela peut être TRÈS, TRÈS RAPIDE. Cependant, les résultats que vous obtenez peuvent dépendre des détails de votre implémentation …

Test comparant Android SDK à Android en utilisant une stack HTTP native faisant des appels Parse / REST …

Détails du test:

Environnement de test – la dernière version d’Android sur un téléphone vieux de 10 mois via une connexion WIFI rapide.

(téléchargez 63 images avec une taille de fichier avg = 80K)

test 1 en utilisant Android SDK RESULT = Performance lente

test 2 en utilisant les appels REST natifs sur Android RESULT = VERT FAST

–EDIT– comme il y a de l’intérêt ici ….

En ce qui concerne http thruput, le SDK (Android) et la performance, il se peut que parse.com n’ait pas optimisé les performances de la manière dont ils implémentent Android asyncTask () dans le SDK parse.android? Comment le travail qui a nécessité 8 min. sur pars.sdk pourrait être fait en 3 secondes sur un framework REST, DIY optimisé (voir les liens pour plus de détails sur les implémentations), je ne sais vraiment pas. Si l’parsing n’a pas corrigé l’implémentation de son SDK depuis l’exécution de ces tests de comparaison, vous ne voudrez probablement pas que ses trucs SDK asnycTask par défaut fassent une véritable charge de travail sur le réseau.

La grande attraction de Parse (et de SaaS similaires) est que vous pouvez économiser des dizaines de milliers de dollars sur les coûts de développement back-end. Étant donné que le back-end est souvent l’aspect le plus coûteux d’une application Web; ce mal de tête est soudain poof .

Le problème avec Parse et la plupart des SaaS (tous) est que la région, l’alimentation, la mémoire, la bande passante, l’évolutivité, les seuils, les alertes et diverses actions sont hors de votre contrôle.

Même avec Shopify. C’est une excellente solution avec un contrôle complet des produits, des commandes, des stocks et de l’esthétique, mais sans aucun contrôle sur la machine. Donc, le SaaS d’aujourd’hui n’est pas très différent de celui de Godaddy. Ils vendent invariablement leurs machines ou en dépensent au maximum pour gagner de l’argent; et vous êtes coincé si vous vous souciez vraiment de la performance de coups de pieds. Vous ne pouvez même pas acheter ce niveau de service.

Je voudrais quelque chose au moins aussi puissant et complet que la console AWS. La plupart des techniciens connaissent et acceptent que Heroku et Parse soient tous deux hébergés sur AWS. On s’en fout. Donc, facturez plus pour le service ajouté, mais ne refusez pas l’access aux outils de bas niveau critiques qui font un site et une application, ainsi que l’expérience utilisateur. Astuce pour les employés de Parse.

En tout cas, en réponse à la question:

L’API Parse est un simple JSON. Vous pouvez donc pomper les données dans le même format JSON que celui attendu par une application Parse.

Vous pourriez même être en mesure d’utiliser leur PFObject (iOS). À un moment donné, toute cette API de haut niveau passe à une requête / réponse HTTP commune. La bonne chose à propos de la généralité de REST est la communité; des choses comme http, url, chaînes et utf. Pas de funky Orb ici.

Parse est idéal pour commencer, en particulier les fonctions d’assistance concernant la gestion des utilisateurs. Mais j’ai commencé à rencontrer des problèmes.

Longue exécution / temps de ping, limite de 1000 objects INCLUANT les sous-requêtes, pas de datacenters en europe (pour autant que je sache)

C’était une plate-forme divine s’ils pouvaient sortinger les problèmes de performance et de stabilité. Je regrette en quelque sorte de développer avec, mais j’ai mis plus de 5000 lignes de code, donc je vais m’en tenir à cela.

Peut-être devraient-ils séparer leurs applications DEV et environnements d’applications PROD, et autoriser uniquement les applications PROD après une certaine forme de supervision, ou créer un environnement différent avec uniquement des clients payants?

Nous sums en 2014, les serveurs de 20 $ / mois peuvent gérer des sites Web non optimisés (60 requêtes de firebase database non mises en cache sur la page d’accueil) avec 1 million de visites / mois, cela ne devrait pas être si difficile pour Parse!

C’est bien pour le prototypage des applications, surtout si le développeur iOS / Android ne sait pas construire lui-même un backend DB / API.

Ce n’est pas correct du tout quand il s’agit de développer une application avec une logique qui nécessite des requêtes plus complexes que:

 SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100; 

Les requêtes associées et les jointures internes n’existent pas sur Parse. Et bonne chance pour mettre à jour / supprimer 320 000 enregistrements si vous en avez besoin (c’est le nombre avec lequel je travaille actuellement).

La seule chose réellement utile est la gestion des utilisateurs via le SDK. Si je pouvais trouver un bon documentaire ou même un didacticiel sur la façon de gérer / créer des utilisateurs via des applications iOS / Android en utilisant Django et DRF / Tastypie, je convertis instantanément tout ce qui est en cours de développement dans notre entreprise.