Platformy wykonawcze zaczynają konkurować o wejście do łańcucha narzędzi z pełnym stosem

Gdy tylko projekt zacznie jednocześnie uwzględniać SSR, zadania w tle, przechowywanie obiektów i wdrażanie podglądu, narzędzie do kompilacji wkrótce ujawni swoje pierwotne granice. vite dev odpowiada za uruchomienie strony, zwrócenie zarządzania frameworkiem testowym, wdrożenie CLI do przejścia w tryb online i dodanie warstwy kleju do warstwy adaptacyjnej środowiska wykonawczego. Na początku ten zestaw rzeczy był do zaakceptowania, ale gdy w projekcie oddzielono lokalne debugowanie od środowiska produkcyjnego, zaczęły pojawiać się problemy: można było działać lokalnie, ale podgląd nie powiódł się; po uaktualnieniu wersji adaptera powiązania kolejek i pamięci masowej nie były już kompatybilne; polecenia były nadal takie same i już wiedziałem, że każda warstwa może mieć problemy niezależnie.

Najbardziej oczywistą zmianą w łańcuchu narzędzi w ciągu ostatnich dwóch lat jest to, że platforma nie jest już zadowolona z „ostatniego etapu wdrożenia”. Zaczęli iść do przodu, łącząc rozwój lokalny, symulację środowiska wykonawczego, opinie z testów i wydawanie poleceń w jednym łączu. W związku z niedawną fuzją VoidZero z Cloudflare tak naprawdę warto przyjrzeć się nie samym wiadomościom o przejęciu, ale wyraźniejszemu sygnałowi: platformy wykonawcze zaczynają bezpośrednio konkurować o wejście do łańcucha narzędzi z pełnym stosem.

Gdy narzędzie do kompilacji osiągnie środowisko wykonawcze, granica platformy przesuwa się do przodu

W tradycyjnym sensie obowiązki narzędzia do kompilacji są bardzo jasne: odczytaj kod źródłowy, wygeneruj pakiet i przekaż go kolejnemu systemowi do przetworzenia. Taki podział pracy już nie wystarczy. Dopóki aplikacja posiada routing po stronie serwera, bazy danych, kolejki, pamięć obiektową i funkcje brzegowe, zakończenie budowy nie oznacza zakończenia dostawy. Nadal pozostaje do wyrównania cała sekcja semantyki środowiska wykonawczego.

W przypadku tego rodzaju projektu najłatwiejszym miejscem do utknięcia nie jest to, czy program pakujący jest wystarczająco szybki, ale to, czy tym razem to, co działa lokalnie, jest tym samym środowiskiem wykonawczym ustawionym online. Dopóki odpowiedź brzmi nie, pętla rozwojowa będzie coraz cięższa. Aby wypełnić tę lukę, platforma z pewnością znajdzie sposób na wciągnięcie serwera deweloperskiego do własnego środowiska wykonawczego i połączenie „lokalnego pisania kodu” i „uruchamiania go online” w tym samym modelu.

Zatem zmiany, które teraz widzimy, nie polegają już tylko na tym, że platforma zapewnia adapter dla określonego środowiska, ale z kolei własny interfejs CLI platformy, wtyczki środowiska wykonawczego i środowisko lokalne są proaktywnie przekształcane w kształt łańcucha narzędzi, który programiści już znają. W ten sposób zmienia się wejście. Platforma nie czeka już na pojawienie się kroku deploy. Weszło już na rynek, począwszy od dev, build, test, a nawet w formacie monitu o błąd.

Agent wyolbrzymił wszystkie małe tarcia w łańcuchu narzędzi, które można było tolerować.

Kiedy sprawa ta znajduje się na etapie rozwoju czysto ręcznego, tempo nie jest tak pilne. Ludzie będą pamiętać, które polecenia należy wykonać więcej niż raz, które błędy wynikają po prostu z problemów środowiskowych, a które adaptery czasami powodują drgawki. Kiedy pojawia się Agent, te niejasności w zasadzie stają się kosztami.

Agent będzie wielokrotnie pobierał serwer deweloperski, ponownie uruchamiał test, czytał błędy, zmieniał kod i ponownie przeprowadzał weryfikację. Niespójne polecenia, nieregularne dzienniki i niespójne zachowanie środowiska wykonawczego. Te małe usterki, które wcześniej zostały rozwiązane przez doświadczenie, staną się bezpośrednio nieskończoną pętlą w pętli wykonawczej. Oczywiście szybkość kompilacji, szybkość testowania i szybkość lintowania są również ważne, ale ważniejsze jest to, czy całe łącze ma ujednolicone ograniczenia: ten sam zestaw interfejsu CLI, ten sam zestaw modeli konfiguracyjnych, ten sam typ wyjścia błędów oraz tę samą relację mapowania lokalnego i produkcyjnego.

Dlatego zmienia się status narzędzi takich jak Vite. Pierwotnie były one po prostu najbardziej przydatnym sprzętem w warstwie konstrukcyjnej front-endu, ale teraz stopniowo stały się domyślną bazą dla Agenta, na której najłatwiej jest stabilnie prowadzić. Szybki, prosty i szeroko kompatybilny. Te zalety służyły głównie doświadczeniu programistycznemu, ale teraz bezpośrednio służą niezawodności wykonania. Dopóki platforma dołączy swoje możliwości wykonawcze do tej domyślnej pętli, nie tylko zyska cel wdrożenia, ale także cały zestaw nawyków związanych z generowaniem i weryfikacją aplikacji.

Naprawdę cenne nie jest dopasowanie frameworka, ale to, kto usuwa domyślny przepływ pracy.

Już na podstawie doniesień prasowych łatwo zinterpretować takie działania jako inwestycję ekologiczną, czy też jako platformę chcącą skierować ruch na własne usługi hostingowe. Bardziej wrażliwe zmiany w inżynierii zachodzą w rzeczywistości na innym poziomie: gdy domyślne rusztowanie projektu, domyślne lokalne środowisko wykonawcze, domyślna pętla testowa i domyślne polecenia wydania znajdą się w tym samym łańcuchu narzędzi, jednostka konkurencji między platformami zmieni się z „czyja maszyna jest tańsza” na „kto pierwszy definiuje sposób tworzenia aplikacji”.

Ta różnica nie jest mała. Ceny można porównywać poziomo. Gdy przepływ pracy zostanie zapisany w hurtowni, skryptach, CI i nawykach zespołu, rzadko jest łatwo go zmienić. Jeśli platforma może przejąć dopiero ostatni etap wdrożenia, próg migracji nie jest wysoki; jeśli platforma przejęła całą ścieżkę od dev do deploy, migracja będzie miała wpływ na środowisko lokalne, nawyki poleceń, łącza podglądu, metody debugowania i skrypty wykonywania agentów. Często to właśnie ta warstwa tak naprawdę tworzy lepkość.

Ta ostatnia fala ruchów ukazuje także inną rzecz: łańcuch narzędzi z pełnym stosem na nowo definiuje „neutralność”. W przeszłości neutralność oznaczała raczej to, że była niezależna od frameworka i działała na różnych pakietach. Obecnie wymogi neutralności są bardziej rygorystyczne. Możliwości platformy muszą być podłączone, ale samego łańcucha narzędzi nie można przekształcić w protokół prywatny dla platformy. Ktokolwiek potrafi zachować warstwę abstrakcji niezależną od dostawcy, jednocześnie czyniąc własną implementację domyślną, będzie miał większe szanse na otrzymanie kolejnej rundy premii wejściowych.

Ta ścieżka jest odpowiednia tylko dla zespołów, które powstrzymywały się od złożoności realizacji

Nie wszystkie projekty muszą uwzględniać tego rodzaju rywalizację o wejście. W przypadku witryn statycznych, małych backendów lub usług z jednym formularzem wdrożenia może nie zaszkodzić dalsze oddzielenie konstrukcji, testowania i wdrażania. Gdy skala projektu jest duża, szybko pojawią się tego typu problemy:

• Różnice między programowaniem lokalnym a środowiskiem wykonawczym online zaczęły wielokrotnie pochłaniać czas rozwiązywania problemów
• SSR, kolejka zadań, pamięć obiektów i powiązanie z bazą danych pojawiają się w tym samym magazynie — Zespoły już korzystają ze środowisk podglądu, poleceń tworzenia szkieletów i szablonów CI do wspólnego dostarczania
• Agenci biorą udział w kodowaniu, naprawianiu błędów i testowaniu, a stabilność łańcucha narzędzi zaczyna bezpośrednio wpływać na wyniki.

Na tym etapie jest już trochę za późno na traktowanie narzędzia do kompilacji jako komponentu warstwy front-end. Staje się już częścią punktu wejścia aplikacji, połączonego ze środowiskiem wykonawczym, stroną wdrożeniową i stroną wykonawczą. Połączenie VoidZero i Cloudflare tylko rozjaśnia tę kwestię: kolejna runda rywalizacji platform będzie coraz bardziej przypominać rywalizację o domyślny przepływ pracy. Kto najpłynniej zamknie ten łańcuch, będzie miał większą szansę na podjęcie decyzji, na jakim fundamencie będzie rozwijana aplikacja jako pierwsza.