Rychlost requestu určuje první vrstva, která na něj umí odpovědět
Představa „edge = kód běží blízko uživatele" vede ke špatným rozhodnutím. Přesnější model je, že request prochází řadou vrstev a každá z nich může odpovědět sama, nebo ho poslat dál. Čím dřív se odpoví, tím kratší cesta. Jenže každá vrstva umí odpovědět jen s tím, co má k dispozici.
Na Vercelu ta řada vypadá takhle: ingress, firewall, routing, správa provozu, cache, výpočet. Podobný tvar mají i jiné platformy, liší se v detailech.
Vrstvy, které nepotřebují tvoje data
Request dorazí do nejbližšího Point of Presence. Těch je 126, a podle dokumentace PoP „ukončí TCP a pošle request do nejbližšího regionu" po privátní síti v řádu jednotek milisekund. TLS se ukončuje až v regionu. Už tohle boří obraz edge jako jednoho místa: blízko uživatele je jen první skok.
Pak firewall. Zablokované requesty se k routingu ani cache nikdy nedostanou. Pak routing, a ten se vyhodnotí dřív, než se sáhne do jakékoli cache: redirecty, rewrity, hlavičky. Pokud sedí redirect, CDN odpoví hned. Následuje volba deploymentu, tedy skew protection, rolling release a směrování mezi micro-frontendy.
Všechny tyhle vrstvy spojuje jedna věc. Rozhodují jen podle requestu: cesty, hlaviček, cookie, geolokace. Proto můžou běžet všude. I Routing Middleware Vercel nasazuje do všech regionů bez ohledu na to, kde máš funkce.
Cache odpovídá jen tomu, co umí rozlišit
Další jsou dvě vrstvy cache. CDN cache blízko návštěvníka, řízená hlavičkami Cache-Control, které vrací tvoje funkce. Za ní trvalá ISR cache v regionu funkcí, kde obsah vydrží až 31 dní. Souběžné requesty na stejnou ISR cestu se slijí do jednoho volání funkce.
Hustota sítě tady jde proti intuici. Vercel záměrně drží „méně, ale hustších regionů", protože víc uzlů znamená, že se tentýž obsah rozprostře do víc cache a každá má nižší šanci na zásah. Víc míst blízko uživatele tak nemusí znamenat víc odpovědí blízko uživatele.
A cache odpoví jen tehdy, když se dva requesty dají považovat za stejné. Od 30. září Vercel CDN přestal ukládat odpovědi s Vary: Cookie, protože cookie nese hodnoty konkrétního návštěvníka a každá kombinace vytváří vlastní, skoro nikdy znovu nepoužitý záznam. Pokud odpověď na cookie nezávisí, Cookie z Vary odstraň. Pokud závisí, nastav Cache-Control: private.
Výpočet patří k datům
Když žádná cache nemá odpověď, request dojde k funkci. Ta defaultně běží v iad1 ve Washingtonu, protože tam podle dokumentace leží většina externích datových zdrojů. Doporučení je přímé: funkce mají běžet ve stejném regionu jako databáze, nebo co nejblíž.
Důvod je aritmetika. Uživatel v Praze a databáze ve Virginii. Render ve Frankfurtu znamená jeden krátký skok k uživateli a pak každý dotaz přes Atlantik. Při pěti sekvenčních dotazech je to pět oceánských round-tripů. Render ve Virginii zaplatí oceán jednou, na cestě odpovědi zpátky. Render blízko uživatele se vyplatí jen tehdy, když jsou blízko uživatele i data.
Odtud dělení práce. Na okraji dělej rozhodnutí, která vystačí s requestem: přesměrování, rewrite, A/B rozřazení, odmítnutí, kontrolu podpisu tokenu. Do regionu u dat pošli všechno, co do dat sahá. Funkci, která čte z evropské databáze, stačí v konfiguraci přesunout do cdg1 nebo fra1.
I pojmenování se posouvá. Vercel letos přejmenoval „Edge Requests" na „CDN Requests", což tenhle posun od místa k vrstvě dobře vystihuje.
Co si z toho odnést
Při návrhu cesty requestu se u každé odpovědi ptej, kterou nejranější vrstvu by mohla obsloužit a co by k tomu ta vrstva potřebovala vědět. Redirect patří do routingu, sdílená stránka do cache, personalizovaná odpověď do funkce u dat.
Klíč cache drž tak úzký, jak to obsah dovolí, jinak vrstva, která by mohla odpovědět, jen přeposílá. A region funkcí volíš podle databáze, ne podle uživatelů. Blízko uživatele má být síť a cache, výpočet má být blízko dat.