Cloudflare vinext: Next.js'i Yapay Zeka ile Bir Haftada Nasıl Yeniden İnşa Ettik?

Bu yazı, Cloudflare blogunda yayınlanan yazının Türkçe çevirisidir. Ayrıca, derleme süresi karşılaştırmalarındaki bir yazım hatasını düzeltmek için PT saatiyle 12:35’te güncellenmiştir.

Geçen hafta, bir mühendis ve bir yapay zeka modeli en popüler front-end framework’ünü sıfırdan yeniden oluşturdu. Ortaya çıkan sonuç, Next.js’in yerine doğrudan kullanılabilecek, Vite üzerine inşa edilmiş ve tek bir komutla Cloudflare Workers’a dağıtılabilen vinext (“vee-next” olarak okunur) oldu. İlk karşılaştırmalara göre, üretim uygulamalarını 4 kata kadar daha hızlı derliyor ve %57’ye kadar daha küçük istemci (client) paketleri üretiyor. Hatta şu anda bunu canlıda (production) kullanan müşterilerimiz bile var.

Tüm bu sürecin token maliyeti ise yaklaşık 1.100 dolar oldu.

Next.js’in Dağıtım (Deployment) Problemi

Next.js en popüler React framework’üdür. Milyonlarca geliştirici tarafından kullanılıyor. Üretimdeki web’in büyük bir bölümüne güç veriyor ve bunun iyi bir nedeni var: Geliştirici deneyimi birinci sınıf.

Ancak Next.js’in, daha geniş sunucusuz (serverless) ekosistemde kullanıldığında bir dağıtım problemi var. Araçlar tamamen bu sisteme özel tasarlanmış: Next.js, Turbopack’e büyük yatırım yaptı ancak uygulamanızı Cloudflare, Netlify veya AWS Lambda’ya dağıtmak isterseniz, bu derleme (build) çıktısını alıp hedef platformun çalıştırabileceği bir şeye dönüştürmek zorundasınız.

Eğer aklınızdan “OpenNext de tam olarak bunu yapmıyor mu?” diye geçiriyorsanız, haklısınız.

Aslında OpenNext‘in çözmek için oluşturulduğu problem tam olarak buydu. Bizim Cloudflare’de yaptığımız da dahil olmak üzere, birden fazla sağlayıcıdan OpenNext’e çok fazla mühendislik çabası aktarıldı. Çalışıyor ancak hızla bazı sınırlamalara çarpıyor ve sürekli baş gösteren hataları düzeltme oyununa (whack-a-mole) dönüşüyor.

Temel olarak Next.js çıktısının üzerine inşa etmek, zor ve kırılgan bir yaklaşım olduğunu kanıtladı. OpenNext, Next.js’in derleme çıktısında tersine mühendislik (reverse-engineering) yapmak zorunda olduğu için, sürümler arasında düzeltilmesi çok fazla iş gerektiren öngörülemeyen değişiklikler ortaya çıkıyor.

Next.js, birinci sınıf bir adaptör API’si üzerinde çalışıyor ve bu konuda onlarla işbirliği yapıyoruz. Bu hala erken aşamada bir çaba ama adaptörlerle bile hala o özel Turbopack araç zincirinin üzerinde inşa ediyorsunuz. Üstelik adaptörler sadece derleme ve dağıtım süreçlerini kapsıyor. Geliştirme (development) sırasında, next dev sadece Node.js içinde çalışıyor ve farklı bir çalışma zamanını (runtime) entegre etmenin bir yolu yok. Eğer uygulamanız Durable Objects, KV veya AI binding’leri gibi platforma özel API’ler kullanıyorsa, bazı geçici çözümler (workarounds) olmadan o kodu dev ortamında test edemezsiniz.

vinext ile Tanışın

Peki ya Next.js çıktısını uyarlamak yerine, Next.js API yüzeyini doğrudan Vite üzerinde yeniden uygulasaydık? Vite, Astro, SvelteKit, Nuxt ve Remix gibi framework’lere güç veren, Next.js dışındaki front-end ekosisteminin büyük kısmı tarafından kullanılan bir derleme (build) aracıdır. Sadece bir sarmalayıcı (wrapper) veya adaptör değil, temiz bir yeniden uygulama. Dürüst olmak gerekirse, işe yarayacağını düşünmemiştik. Ama yıl 2026 ve yazılım geliştirmenin maliyeti tamamen değişti.

Beklediğimizden çok daha ileri gittik.

npm install vinext

Script’lerinizdeki next ibaresini vinext ile değiştirin, diğer her şey aynı kalır. Mevcut app/, pages/ ve next.config.js dosyalarınız olduğu gibi çalışır.

vinext dev          # HMR destekli geliştirme sunucusu
vinext build        # Üretim (production) derlemesi
vinext deploy       # Cloudflare Workers'a derleme ve dağıtım

Bu, Next.js ve Turbopack çıktısının etrafına sarılmış bir yapı değildir. API yüzeyinin alternatif bir uygulamasıdır: yönlendirme (routing), sunucu tarafı render (SSR), React Server Components (RSC), sunucu eylemleri (server actions), önbellekleme (caching), middleware. Hepsi bir eklenti olarak Vite’ın üzerine inşa edilmiştir. En önemlisi, Vite çıktısı, Vite Environment API sayesinde her platformda çalışır.

Rakamlar

İlk karşılaştırmalar oldukça umut verici. Paylaşılan 33 rotalı bir App Router uygulamasını kullanarak vinext ile Next.js 16’yı karşılaştırdık.

Her iki framework de aynı işi yapıyor: derleme, paketleme ve sunucu taraflı render edilen rotaları hazırlama. Next.js derlemesinde TypeScript tip kontrolünü ve ESLint’i devre dışı bıraktık (Vite derleme sırasında bunları çalıştırmaz) ve Next.js’in statik rotaları önceden render etmek için fazladan zaman harcayarak rakamlarını haksız yere yavaşlatmasını engellemek için force-dynamic kullandık. Amaç, başka hiçbir şeyi değil, sadece paketleyici (bundler) ve derleme (compilation) hızını ölçmekti. Karşılaştırmalar, main dalına yapılan her birleştirmede (merge) GitHub CI üzerinde çalıştırıldı.

Üretim (Production) derleme süresi:

Framework	Ortalama (Mean)	Next.js’e Kıyasla
Next.js 16.1.6 (Turbopack)	7.38s	temel (baseline)
vinext (Vite 7 / Rollup)	4.64s	1.6x daha hızlı
vinext (Vite 8 / Rolldown)	1.67s	4.4x daha hızlı

İstemci (Client) paketi boyutu (gzipped):

Framework	Gzipped	Next.js’e Kıyasla
Next.js 16.1.6	168.9 KB	temel (baseline)
vinext (Rollup)	74.0 KB	%56 daha küçük
vinext (Rolldown)	72.9 KB	%57 daha küçük

Bu karşılaştırmalar, üretimde sunum (serving) performansını değil, derleme ve paketleme hızını ölçmektedir. Test fikstürü, tüm üretim uygulamalarını temsil eden bir örneklem değil, yalnızca 33 rotalı tek bir uygulamadır. Bu üç proje gelişmeye devam ettikçe bu rakamların da değişmesini bekliyoruz. Tüm metodoloji ve geçmiş sonuçlar herkese açıktır. Bunları kesin doğrular olarak değil, yol gösterici olarak kabul edin.

Ancak gidişat cesaret verici. Vite’ın mimarisinin ve özellikle Rolldown‘un (Vite 8 ile gelecek olan Rust tabanlı paketleyici), derleme performansında burada açıkça görülen yapısal avantajları var.

Cloudflare Workers’a Dağıtım

vinext, ilk dağıtım hedefi olarak Cloudflare Workers ile oluşturulmuştur. Tek bir komut sizi kaynak kodundan çalışan bir Worker’a götürür:

vinext deploy

Bu komut her şeyi halleder: uygulamayı derler, Worker yapılandırmasını otomatik olarak oluşturur ve dağıtır. Hem App Router hem de Pages Router, tam istemci tarafı hidrasyonu, etkileşimli bileşenler, istemci tarafı gezinme ve React state’i ile Workers üzerinde çalışır.

Üretim ortamında önbellekleme (caching) için vinext, size varsayılan olarak ISR (Artımlı Statik Yeniden Oluşturma - Incremental Static Regeneration) sağlayan bir Cloudflare KV önbellek işleyicisi içerir:

import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache";

setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));

KV, çoğu uygulama için iyi bir varsayılandır ancak önbellekleme katmanı eklenebilir/çıkarılabilir (pluggable) olacak şekilde tasarlanmıştır. Bu setCacheHandler çağrısı, uygulamanız için hangi backend mantıklıysa onu değiştirebileceğiniz anlamına gelir. Büyük önbelleğe alınmış veritabanlarına veya farklı erişim kalıplarına sahip uygulamalar için R2 daha iyi bir uyum sağlayabilir. Ayrıca, daha az yapılandırma ile güçlü bir önbellekleme katmanı sağlaması gereken Cache API’mizdeki iyileştirmeler üzerinde de çalışıyoruz. Amaç esnekliktir: uygulamanıza uyan önbellekleme stratejisini seçin.

Şu anda çalışan canlı örnekler:

• App Router Playground
• Hacker News klonu
• App Router minimal
• Pages Router minimal

Ayrıca, tüm uygulama artık hem dev hem de deploy aşamalarında workerd‘de çalıştığından, getPlatformProxy gibi geçici çözümlere gerek kalmadan bir Next.js uygulamasında çalışan Cloudflare Agents’ın canlı bir örneğine de sahibiz. Bu, Durable Objects, AI binding’leri ve Cloudflare’e özgü diğer tüm hizmetleri ödün vermeden kullanabilmek anlamına gelir. Buradan inceleyebilirsiniz.

Framework’ler Bir Takım Oyunudur

Mevcut dağıtım hedefi Cloudflare Workers, ancak bu resmin sadece küçük bir kısmı. vinext’in %95 gibi bir oranı saf Vite’tır. Yönlendirme (routing), modül shim’leri, SSR pipeline’ı, RSC entegrasyonu: hiçbirinin Cloudflare’e özgü bir yapısı yoktur.

Cloudflare, müşterileri için bu araç zincirini benimsemek adına diğer barındırma sağlayıcılarıyla birlikte çalışmayı planlıyor (zahmet minimumdur — 30 dakikadan kısa sürede Vercel üzerinde çalışan bir kavram kanıtı elde ettik!). Bu açık kaynaklı bir projedir ve uzun vadeli başarısı için, devam eden yatırımı sağlamak amacıyla ekosistemdeki iş ortaklarıyla birlikte çalışmamızın önemli olduğuna inanıyoruz. Diğer platformlardan gelecek olan PR’lara her zaman açığız. Bir dağıtım hedefi eklemekle ilgileniyorsanız, bir issue açın veya bizimle iletişime geçin.

Durum: Deneysel (Experimental)

Açık olmak istiyoruz: vinext deneyseldir. Henüz bir haftalık bile değil ve büyük ölçekte anlamlı bir trafikle henüz savaş testinden (battle-tested) geçmedi. Eğer bunu bir üretim uygulaması için değerlendiriyorsanız, uygun bir dikkatle ilerleyin.

Bununla birlikte, test paketi oldukça kapsamlıdır: doğrudan Next.js test paketinden ve OpenNext’in Cloudflare uyumluluk paketinden taşınan testler de dahil olmak üzere 1.700’den fazla Vitest testi ve 380 Playwright E2E testi bulunmaktadır. vinext’i Next.js App Router Playground’a karşı doğruladık. Kapsama alanı, Next.js 16 API yüzeyinin %94’ünde bulunuyor.

Gerçek dünyadaki müşterilerden elde edilen ilk sonuçlar cesaret verici. Beta sitelerinden biri olan CIO.gov‘da, her devlet arayüzünü modernize etmeyi hedefleyen bir ekip olan National Design Studio ile birlikte çalışıyoruz. Derleme sürelerinde ve paket boyutlarında anlamlı iyileştirmelerle vinext’i halihazırda üretimde çalıştırıyorlar.

README dosyamız, neyin desteklenmediği ve desteklenmeyeceği ile bilinen sınırlamalar konusunda dürüsttür. Aşırı vaatlerde bulunmak yerine en baştan açık olmayı tercih ediyoruz.

Peki ya Pre-rendering (Önceden İşleme)?

vinext, varsayılan olarak Incremental Static Regeneration’ı (ISR) halihazırda destekliyor. Herhangi bir sayfaya yapılan ilk istekten sonra, tıpkı Next.js gibi arka planda önbelleğe alınır ve yeniden doğrulanır. Bu kısım bugün çalışıyor.

vinext henüz derleme (build) zamanında statik pre-rendering’i desteklemiyor. Next.js’te, dinamik verisi olmayan sayfalar next build sırasında render edilir ve statik HTML olarak sunulur. Eğer dinamik rotalarınız varsa, hangi sayfaların önceden oluşturulacağını belirtmek için generateStaticParams() kullanırsınız. vinext bunu yapmıyor… henüz.

Bu, lansman için kasıtlı olarak alınmış bir tasarım kararıydı. Bu özellik yol haritamızda var, ancak siteniz tamamen statik içerikli %100 önceden derlenmiş (prebuilt) HTML ise, bugün vinext’ten çok fazla fayda görmeyebilirsiniz. Bununla birlikte, eğer bir mühendis 1.100 dolar değerinde token harcayarak Next.js’i yeniden oluşturabiliyorsa, siz de muhtemelen 10 dolar harcayarak Astro gibi statik içerikler için özel olarak tasarlanmış Vite tabanlı bir framework’e geçiş yapabilirsiniz (ki bu da Cloudflare Workers’a dağıtılabilir).

Ancak tamamen statik olmayan siteler için, her şeyi derleme zamanında önceden render etmekten daha iyi bir şey yapabileceğimizi düşünüyoruz.

Trafiğe Duyarlı Pre-Rendering (TPR) ile Tanışın

Next.js, generateStaticParams() içinde listelenen her sayfayı derleme sırasında önceden render eder. 10.000 ürün sayfasına sahip bir site, bu sayfaların %99’u hiçbir zaman bir istek almayacak olsa bile, derleme zamanında 10.000 render işlemi anlamına gelir. Derlemeler, sayfa sayısıyla doğrusal olarak ölçeklenir. Bu yüzden büyük Next.js siteleri 30 dakikalık derleme süreleriyle karşı karşıya kalır.

Bu yüzden Traffic-aware Pre-Rendering (Trafiğe Duyarlı Pre-Rendering - TPR) geliştirdik. Bugün için deneysel, ancak arkasında daha fazla gerçek dünya testi olduğunda bunu varsayılan yapmayı planlıyoruz.

Buradaki fikir oldukça basit. Cloudflare zaten siteniz için reverse proxy konumundadır. Trafik verilerinize sahibiz. Hangi sayfaların gerçekten ziyaret edildiğini biliyoruz. Bu nedenle, her şeyi önceden render etmek ya da hiçbirini etmemek yerine, vinext dağıtım (deploy) sırasında Cloudflare’in zone analitiklerini sorgular ve yalnızca önemli olan sayfaları önceden render eder.

vinext deploy --experimental-tpr

  Building...
  Build complete (4.2s)

  TPR (experimental): Analyzing traffic for my-store.com (last 24h)
  TPR: 12,847 unique paths — 184 pages cover 90% of traffic
  TPR: Pre-rendering 184 pages...
  TPR: Pre-rendered 184 pages in 8.3s → KV cache

  Deploying to Cloudflare Workers...

100.000 ürün sayfası olan bir site için güç yasası (power law), trafiğin %90’ının genellikle 50 ila 200 sayfaya gittiği anlamına gelir. Bunlar saniyeler içinde önceden render edilir. Geri kalan her şey talep üzerine (on-demand) SSR’a geri döner ve ilk istekten sonra ISR aracılığıyla önbelleğe alınır. Her yeni deploy, seti mevcut trafik modellerine göre günceller. Viral olan sayfalar otomatik olarak yakalanır. Tüm bunlar, generateStaticParams() kullanmadan ve derlemenizi üretim veritabanınıza bağlamadan çalışır.

Next.js Zorluğunu Üstlenmek, Ancak Bu Sefer Yapay Zeka İle

Böyle bir proje normalde bir mühendis ekibinin yıllarını değilse de aylarını alırdı. Çeşitli şirketlerdeki birkaç ekip bunu denedi ve kapsamı gerçekten devasa. Cloudflare’de de bir kez denedik! İki yönlendirici (router), 33+ modül shim’i, sunucu render pipeline’ları, RSC akışı (streaming), dosya sistemi tabanlı yönlendirme (file-system routing), middleware, caching, static export. Kimsenin bunu başaramamasının bir nedeni var.

Bu kez bunu bir haftadan kısa bir sürede yaptık. Yapay zekayı yöneten tek bir mühendis (teknik olarak bir mühendislik yöneticisi).

İlk commit 13 Şubat’ta geldi. Aynı günün akşamında hem Pages Router hem de App Router, middleware, sunucu eylemleri (server actions) ve streaming ile birlikte temel SSR özelliklerine sahipti. Ertesi gün öğleden sonra, App Router Playground 11 rotanın 10’unu render ediyordu. Üçüncü günde, vinext deploy komutu tam istemci (client) hidrasyonuyla uygulamaları Cloudflare Workers’a gönderiyordu. Haftanın geri kalanı ise sağlamlaştırma çalışmalarıyla geçti: edge case’leri düzeltmek, test paketini genişletmek ve API kapsamını %94’e çıkarmak.

Önceki denemelerden bu yana ne değişti? Yapay zeka çok gelişti. Hem de çok fazla.

Bu Problem Neden Yapay Zeka İçin Biçilmiş Kaftan?

Her proje bu şekilde ilerlemez. Bu projenin böyle ilerlemesinin nedeni, birkaç şeyin doğru zamanda aynı hizaya gelmesiydi.

Next.js iyi bir şekilde belirtilmiştir (well-specified). Kapsamlı dökümantasyonları, devasa bir kullanıcı tabanı ve yıllara yayılan Stack Overflow cevapları ve eğitimleri var. API yüzeyinin tamamı eğitim verilerinde bulunuyor. Claude’dan getServerSideProps‘u uygulamasını veya useRouter‘ın nasıl çalıştığını açıklamasını istediğinizde, halüsinasyon görmez. Next’in nasıl çalıştığını bilir.

Next.js ayrıntılı bir test paketine sahiptir. Next.js reposu, her özelliği ve edge case’i kapsayan binlerce E2E testi içerir. Testleri doğrudan onların paketinden taşıdık (kodda atıfları görebilirsiniz). Bu bize mekanik olarak doğrulayabileceğimiz bir spesifikasyon sağladı.

Vite mükemmel bir temeldir. Vite front-end araçlarının zor kısımlarını halleder: hızlı HMR, yerel ESM, temiz bir eklenti API’si, üretim paketleme. Bir paketleyici (bundler) inşa etmek zorunda kalmadık. Sadece ona Next.js dilini konuşmayı öğretmemiz gerekiyordu. @vitejs/plugin-rsc henüz erken aşamada, ancak bize sıfırdan bir RSC uygulaması oluşturmak zorunda kalmadan React Server Components desteği sağladı.

Modeller arayı kapattı. Birkaç ay önce bile bunun mümkün olabileceğini sanmıyoruz. Önceki modeller bu boyuttaki bir kod tabanında tutarlılığı sürdüremiyordu. Yeni modeller tam mimariyi bağlam (context) içinde tutabiliyor, modüllerin nasıl etkileşime girdiği hakkında mantık yürütebiliyor ve momentumu devam ettirecek sıklıkta doğru kod üretebiliyor. Zaman zaman bir hatayı bulmak için Next, Vite ve React iç yapılarına indiğini gördüm. Son teknoloji modeller etkileyici ve giderek daha da iyileşiyorlar.

Tüm bunların aynı anda gerçekleşmesi gerekiyordu. İyi belgelenmiş hedef API, kapsamlı test paketi, altta yatan sağlam bir derleme aracı ve karmaşıklıkla gerçekten başa çıkabilecek bir model. Bunlardan herhangi birini çıkardığınızda bu iş bu kadar iyi yürümezdi.

Bunu Gerçekte Nasıl İnşa Ettik

vinext’teki kodların neredeyse her satırı yapay zeka tarafından yazıldı. Ancak asıl önemli olan şu: her satır, insan tarafından yazılmış bir koddan bekleyeceğiniz kalite kapılarından (quality gates) geçiyor. Projede 1.700+ Vitest testi, 380 Playwright E2E testi, tsgo aracılığıyla tam TypeScript tip kontrolü ve oxlint aracılığıyla linting bulunuyor. Sürekli entegrasyon (CI), her pull request’te bunların tümünü çalıştırır. İyi bir sınır/koruma (guardrails) seti oluşturmak, bir kod tabanında yapay zekayı üretken kılmak için kritik öneme sahiptir.

Süreç bir planla başladı. Mimarinin ana hatlarını (neyin inşa edileceği, hangi sırayla yapılacağı, hangi soyutlamaların kullanılacağı) belirlemek için OpenCode‘da Claude ile birkaç saat boyunca ileri geri konuşarak vakit harcadım. Bu plan kutup yıldızımız oldu. Oradan itibaren iş akışı oldukça basitti:

1. Bir görev tanımla (“usePathname, useSearchParams, useRouter ile next/navigation shim’ini uygula”).
2. Yapay zekanın uygulamayı ve testleri yazmasına izin ver.
3. Test paketini çalıştır.
4. Testler geçerse merge et. Geçmezse, yapay zekaya hata çıktısını ver ve tekrar denemesini (iterate) sağla.
5. Tekrarla.

Kod incelemesi (code review) için de yapay zeka ajanlarını (agents) entegre ettik. Bir PR açıldığında, bir ajan onu inceliyordu. İnceleme yorumları geldiğinde, başka bir ajan bu yorumlara yanıt veriyordu. Geri bildirim döngüsü büyük ölçüde otomatikleştirildi.

Her zaman kusursuz çalışmadı. Tamamen yanlış olan PR’lar da vardı. Yapay zeka, doğru gibi görünen ama gerçek Next.js davranışıyla uyuşmayan şeyleri kendinden emin bir şekilde uygulayabiliyordu. Düzenli olarak rotayı düzeltmek zorunda kaldım. Mimari kararlar, önceliklendirme, yapay zekanın ne zaman çıkmaz sokağa girdiğini bilmek: tüm bunlar bana aitti. Yapay zekaya iyi bir yönlendirme, iyi bir bağlam ve iyi sınırlandırmalar verdiğinizde, çok üretken olabilir. Ancak direksiyonda yine insanın olması gerekiyor.

Tarayıcı seviyesindeki testler için, asıl render edilen çıktıyı, istemci tarafı navigasyonu ve hidrasyon davranışını doğrulamak üzere agent-browser kullandım. Birim testleri (unit tests) tarayıcıdaki birçok ince hatayı kaçırır. Bu yöntem onları yakaladı.

Projenin seyri boyunca, OpenCode’da 800’den fazla oturum çalıştırdık. Toplam maliyet: Claude API token’ları için kabaca 1.100 dolar.

Bunun Yazılım İçin Anlamı

Yığın (stack) içinde neden bu kadar çok katmanımız var? Bu proje beni bu soru üzerinde derinlemesine düşünmeye zorladı. Ve yapay zekanın bu cevabı nasıl etkilediğini göz önünde bulundurmaya.

Yazılımdaki çoğu soyutlama (abstraction), insanların yardıma ihtiyacı olduğu için var. Sistemin tamamını kafamızda tutamadığımız için, karmaşıklığı bizim yerimize yönetecek katmanlar inşa ettik. Her katman bir sonraki kişinin işini kolaylaştırdı. Framework’lerin üzerine framework’ler, sarmalayıcı (wrapper) kütüphaneler, binlerce satır bağlayıcı (glue) kod ile karşılaşmanızın nedeni budur.

Yapay zekanın aynı sınırlaması yok. Sistemin tamamını bağlam (context) içinde tutabilir ve sadece kodu yazabilir. Organize kalmak için ara bir framework’e ihtiyacı yoktur. Sadece bir spesifikasyona ve üzerine inşa edeceği bir temele ihtiyacı vardır.

Hangi soyutlamaların gerçekten temel, hangilerinin ise insan algısı için sadece birer koltuk değneği olduğu henüz belli değil. Bu çizgi önümüzdeki birkaç yıl içinde çok değişecek. Ancak vinext bir veri noktası. Bir API kontratı, bir derleme (build) aracı ve bir yapay zeka modeli aldık ve yapay zeka aradaki her şeyi yazdı. Herhangi bir ara framework’e gerek kalmadı. Bu kalıbın birçok yazılımda tekrarlanacağını düşünüyoruz. Yıllar boyunca oluşturduğumuz katmanların hepsi varlığını sürdüremeyecek.

Teşekkürler

Vite ekibine teşekkürler. Tüm bu yapının üzerinde durduğu temel Vite‘tır. @vitejs/plugin-rsc hala erken günlerinde, ancak anlaşmayı bozabilecek bir durum olan sıfırdan oluşturmak zorunda kalmadan bana RSC desteği verdi. Eklentiyi daha önce hiç test edilmediği bir bölgeye doğru iterken Vite maintainer’ları duyarlı ve yardımcı oldular.

Ayrıca Next.js ekibine de teşekkür etmek istiyoruz. React geliştirmenin nasıl görünebileceği konusunda çıtayı yükselten bir framework oluşturmak için yıllarını harcadılar. API yüzeylerinin bu kadar iyi belgelenmiş olması ve test paketlerinin bu kadar kapsamlı olması, bu projeyi mümkün kılan en büyük etkenlerden biridir. vinext, onların belirlediği standart olmadan var olamazdı.

Deneyin

vinext, geçiş işlemlerini sizin için halleden bir Agent Skill (Ajan Yeteneği) içerir. Claude Code, OpenCode, Cursor, Codex ve diğer onlarca yapay zeka kodlama aracıyla çalışır. Yükleyin, Next.js projenizi açın ve yapay zekaya migrate etmesini söyleyin:

npx skills add cloudflare/vinext

Ardından Next.js projenizi desteklenen herhangi bir araçta açın ve şunu söyleyin:

migrate this project to vinext

Bu “skill”, uyumluluk kontrolü, bağımlılıkların (dependency) yüklenmesi, yapılandırma (config) oluşturma ve geliştirme sunucusunun (dev server) başlatılması işlemlerini yönetir. vinext’in neleri desteklediğini bilir ve manuel müdahale gerektiren herhangi bir şeyi işaretler.

Ya da manuel yapmayı tercih ederseniz:

npx vinext init    # Mevcut bir Next.js projesini migrate et
npx vinext dev     # Dev sunucusunu başlat
npx vinext deploy  # Cloudflare Workers'a gönder

Kaynak kod github.com/cloudflare/vinext adresindedir. Issue’lar, PR’lar ve geri bildirimlerinizi bekliyoruz.