La réalité du démarrage à froid
Même si le secteur a fait d’énormes progrès en matière de réduction des temps d’initialisation, en particulier avec les réseaux de périphérie légers, les fonctions sans serveur traditionnelles basées sur Node.js subissent toujours des démarrages à froid. Si une fonction n’a pas été invoquée récemment, ou si des pics de trafic nécessitent le lancement simultané d’une nouvelle instance, la première requête subira une latence notable à mesure que le conteneur s’approvisionne et que le code se charge.
API au lieu de RAM
Dans un environnement de serveur traditionnel, vous pouvez stocker des données transitoires dans la RAM globale, permettant aux requêtes ultérieures d’accéder instantanément au contexte partagé. Dans le modèle sans serveur, chaque requête peut atteindre un nouveau conteneur. Donc, tous le contexte partagé doit être externalisé. Bien que Firestore serve brillamment de gestionnaire d’état, le fait de s’appuyer sur une base de données pour la mise en cache éphémère à haute fréquence, inférieure à la milliseconde, introduit une latence du réseau et des coûts par opération. Cela dit, utiliser un état de RAM partagé sur un serveur n’est pas non plus trivial, sauf si vous utilisez un seul serveur d’applications et une seule VM (car les exigences de haute disponibilité ou de basculement réduiront le gain de RAM sur un serveur traditionnel).
Réglage de la vitesse et du contrôle
Chaque décision architecturale est un compromis. Il n’existe pas de choix gratuits. En adoptant la pile GitHub, Vercel et Firestore, vous maximisez explicitement la vitesse des fonctionnalités grâce à un contrôle précis.
