Das Versprechen der Edge ist einfach und wahr: Code nah bei der Nutzerin ausführen, den Roundtrip sparen. Was dabei unter den Tisch fällt: Die meisten Anfragen warten gar nicht auf den Code. Sie warten auf die Datenbank, und die steht in Zürich, ob es einem passt oder nicht.
Die Rechnung#
Eine Nutzerin in Genf, eine Datenbank in Zürich. Funktion in Zürich: ein kurzer Sprung zu den Daten. Funktion auf der Edge in Genf: Die Anfrage kommt schneller an und macht danach für jede einzelne Abfrage einen langen Sprung.
| Aufbau | Nutzerin → fn | fn → db | Total (3 Abfragen) |
|---|---|---|---|
| Funktion neben den Daten | ~24 ms | ~2 ms | ~30 ms |
| Funktion auf der Edge | ~4 ms | ~24 ms | ~76 ms |
Was bei uns auf der Edge läuft#
- Routing-Entscheidungen: Weiterleitungen, Spracherkennung, A/B-Zuteilung. Kein Datenzugriff, und sie laufen vor dem Cache.
- Gecachte und personalisierte Antworten: dort, wo die Nutzlast statisch ist und nur ein Header oder ein Fragment variiert.
- Bot- und Missbrauchsprüfungen: die billigstmögliche Abweisung, so weit vom Ursprung entfernt wie möglich.
Was bei uns auf Node bleibt#
Alles, was die Datenbank liest oder schreibt, alles, was mit einem Zahlungsanbieter spricht, und alles, was eine für Node geschriebene Bibliothek braucht. In einem normalen Produkt also das meiste.
Der Teil, der nie auf der Folie steht#
Eine Edge-Runtime ist eine andere Runtime, ein zweiter Satz beweglicher Teile, mit allem, was das kostet. Ihre Abhängigkeiten laufen darin oder eben nicht, der Fehlerfall zeigt sich meistens erst beim Deploy, und eine Bibliothek zu debuggen, die Node-APIs voraussetzt, ist keine gute Verwendung für einen Dienstag. Diese Kosten sind real, und bezahlt werden sie von der Person im Pikett, nicht von der, welche die Runtime ausgesucht hat.