Il n'y a pas de limite stricte, mais brainCloud encourage les développeurs à travailler avec nous pour que les scripts restent précis et efficaces. C'est la principale raison pour laquelle nous facturons par appel d'API: plus vous pouvez garder les choses précises et efficaces, moins l'utilisation de votre application vous coûtera cher.
Les scripts sont plus efficaces que les appels d'API complets. Ils sont donc encouragés.
frais de brainCloud:
1 API Count pour appeler le script
Vous obtenez 2 appels API du script gratuitement
À partir de là, chaque appel d'API ne représente plus que la moitié d'un nombre d'API
Dans l’ensemble, effectuer un ensemble d’opérations à partir d’un script (au lieu de le faire à distance depuis le client) est:
Une meilleure expérience utilisateur (l'utilisateur final n'a pas besoin d'attendre que toutes les demandes et réponses individuelles fassent des allers-retours vers/depuis l'appareil distant)
Utilise moins de traitement serveur (la réception et le décryptage des messages constituent l'une des charges les plus importantes du système)
Coûte moins cher au développeur (en raison des règles de comptage des API ci-dessus)
C'est gagnant-gagnant-gagnant !
Il n'existe aucune limite spécifique au nombre d'appels d'API que vous pouvez effectuer. Nous avons des temporisateurs de surveillance sur les scripts, pour nous assurer que les choses ne tournent pas mal. Le délai d'expiration par défaut est de 10 secondes (bien qu'honnêtement, la plupart des scripts prennent moins de 100 ms pour s'exécuter).
Cela dit, bien sûr, plus vous faites d'appels, plus vos scripts vous coûteront cher et plus vos clients passeront de temps à attendre la réponse du script.
De plus, les délais d'attente du client peuvent parfois interférer. Si vous avez augmenté le délai d'attente de votre script à 20 secondes pour lui permettre d'effectuer une opération importante, mais que les délais d'attente de votre client sont définis sur la valeur par défaut de 15 secondes, il arrive souvent que votre client expire avant que le script ne soit terminé, et vous provoquerez un trafic serveur supplémentaire lorsque votre client réessaiera automatiquement.
Autre observation: la plupart des problèmes rencontrés par les utilisateurs avec les scripts sont davantage liés à la manière dont ils accèdent aux données qu'au script lui-même. Il s'agit moins du nombre d'API que de la manière dont vous utilisez les entités, en particulier les entités globales, dont les performances peuvent vraiment ralentir si vous en avez trop (c'est-à-dire des milliers) ou si des entités sont écrites par trop de personnes simultanément.
Ok, laissez-moi résumer cela en quelques points simples:
Il n'y a pas de limites spécifiques sur le nombre d'appels d'API effectués à partir de scripts
Les applications sont facturées par appel d'API, il est donc préférable pour tous de maintenir un nombre inférieur
Les scripts sont cependant plus efficaces (et moins coûteux) que les appels effectués depuis le client. Par conséquent, en cas de doute, il est préférable d'effectuer des appels supplémentaires dans les scripts plutôt que des appels supplémentaires depuis le client.
Le véritable point à surveiller est l'accès efficace aux données. Les entités globales doivent être utilisées avec précaution - les entités utilisateur et les entités personnalisées avec des index appropriés sont beaucoup plus sûres.
En général, gardez les scripts avec un temps d'exécution bien inférieur à 1 seconde pour de meilleures performances.
Les scripts avec 3 à 8 appels d'API sont généralement les plus performants (je me souviens tout à fait). Si vous recevez plus de 20 appels d'API, vous devrez probablement repenser le script, à moins qu'il ne s'agisse d'une sorte de script d'arrière-plan périodique (c'est-à-dire planifié, et non issu du client).