Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Le problème des tableaux de bord qui cachent votre consommation réelle
Un tableau de bord d'utilisation est censé répondre à tout moment à une question simple : où en suis-je en ce moment ? Bon nombre de tableaux de bord répondent plutôt à une question légèrement différente : où en étiez-vous lors du dernier rapprochement de l'utilisation par notre système de facturation, ce qui remonte peut-être à une heure, peut-être à ce matin, et, lors d'un pic de trafic, c'est exactement l'écart qui transforme une situation gérable en dépassement surprise ou en quota gratuit épuisé de façon inattendue.
Nous pensons que le tableau de bord n'est pas le bon endroit pour placer cette information comme unique source de vérité, non pas parce que les tableaux de bord sont mauvais, mais parce qu'un tableau de bord est par nature éloigné d'un cran de la requête qui compte réellement. La réponse à cette requête précise est le seul endroit garanti pour refléter votre situation exacte à cet instant exact, car elle est générée au moment même où la requête est comptabilisée. C'est pourquoi chaque réponse de My Geocode contient directement des en-têtes de quota : votre limite, ce que vous avez utilisé, votre quota gratuit restant, l'utilisation de votre réseau, le crédit prépayé restant et le moment de réinitialisation du quota. Vous n'avez pas à ouvrir un onglet séparé en espérant qu'il soit à jour.
Cela compte surtout dans les situations où un tableau de bord en retard échoue le plus : un pic soudain de trafic, une tâche par lots qui consomme rapidement une grande partie du quota, ou un jour de lancement où l'utilisation ne ressemble en rien à une journée normale. Un tableau de bord en différé continuera d'afficher un chiffre confortable bien après que le chiffre réel est devenu urgent. Les en-têtes de la réponse que vous venez de recevoir ne peuvent pas prendre de retard de la même façon, car ils ne sont pas un système de reporting séparé qui essaie de rattraper son retard. Ils sont générés dans le cadre de la réponse à la requête elle-même.
Un tableau de bord garde une vraie valeur pour observer les tendances dans le temps, consulter l'historique ou gérer des informations de compte qui ne changent pas d'une requête à l'autre. Nous ne soutenons pas que les tableaux de bord ne devraient pas exister. Nous soutenons qu'ils ne devraient pas être le seul endroit, ni le principal, où un développeur apprend qu'il est sur le point d'épuiser son quota ou son crédit. Cette information doit être disponible au moment où l'on peut agir, c'est-à-dire au moment de la requête, et non plus tard, lorsque le cycle d'actualisation du tableau de bord finit par la refléter.
Le problème plus profond d'un tableau de bord en retard, c'est qu'il peut créer un faux sentiment de sécurité, pire que l'absence totale de visibilité. Un développeur qui consulte un tableau de bord, voit un chiffre confortable et poursuit en toute confiance a été activement induit en erreur par un outil censé éviter exactement ce résultat. Une information en temps réel dans la réponse elle-même évite entièrement ce piège, car il n'existe aucun système séparé dont il faudrait prendre en compte le retard avant de se fier au chiffre.