Vercel Fluid vs Cloudflare Workers. 💬"Z moich ustaleń, Vercel jest od 1,2x do 5x szybszy niż CloudFlare w przypadku renderowania po stronie serwera." Bardzo, bardzo poważnie podeszliśmy do Workers, gdy badaliśmy runtime / świat edge. Nie ma "konfliktu", musieliśmy się przenieść z powodów technicznych. Aby być fair wobec nich, wprowadzili nowe pomysły na rynek. Na przykład, ceny oparte na CPU były dobre, a Vercel Fluid również je ma. Główne problemy, na które natrafiliśmy: 1️⃣ Zła wydajność CPU, niska pojemność, bardzo nieregularna i skokowa latencja. Benchmarki to pokazują. 2️⃣ Runtime jednego dostawcy. Nie możesz uruchomić "Node.js 24". Uruchamiasz "cokolwiek ci dadzą, co próbuje wyglądać jak Node.js, ale nie jest" 3️⃣ Naprawdę zła łączność z chmurami. Mierzyliśmy czas okrężny między AWS a CF Workers jako wynoszący od niskich 10 do 100 milisekund. Wynikiem naszej migracji było wdrożenie Fluid. Płacisz za CPU, obsługuje współbieżność jak serwer (opłacalne), kontrolujesz rozmiar / pamięć funkcji, masz pełne, otwarte runtime'y jak @nodejs i Python, masz 1ms latencji do usług chmurowych… Większość ludzi dzisiaj korzysta z Fluid i nawet tego nie zauważa, ponieważ po prostu działa® z całym ekosystemem. Oto benchmarki, które przeprowadził @theo:

Niektórzy ludzie pytali o 3️⃣. Jeśli twoja funkcja jest połączona z bazą danych (Supabase, PlanetScale, Neon) lub usługą (Stripe), to wyniki byłyby jeszcze bardziej dramatyczne. Zaleta opóźnienia w chmurze jest ogromna. „Edge” był błędem nie tylko w czasie wykonywania, ale także w lokalizacji obliczeń dla logiki głównej aplikacji. Problem jest dwojaki: wodospady (I/O) i CPU.