Bu Blogda Kullanacağımız Teknolojiler ve Neden Onları Seçtik

0. Günde bu blogun 9 aylık bir yol haritası olduğunu anlatmıştım: her ay siteye yeni bir özellik ekleyecek, her özellik bana yeni bir kavram öğretecekti. Ama bir şeyi henüz yapmadım: yol boyunca karşıma çıkacak araçların ne olduğunu ve neden onları seçtiğimi anlatmadım.

Bu yazı tam olarak bunun için. Aşağıda göreceğin isimlerin çoğu (LangChain, pgvector, OpenTelemetry gibi) ilk duyduğunda hiçbir şey ifade etmeyebilir — bende de etmiyordu birkaç ay öncesine kadar. O yüzden her birini, hiç bilmeyen birine anlatır gibi, önce günlük hayattan bir benzetmeyle, sonra da “bunu neden öğreneceğim” diye açıklayacağım.

Ama önce, zaten kullanmaya başladığımız bir şeyden başlayalım: Cloudflare.

Cloudflare nedir, biz onu ne için kullanıyoruz?

Bir web sitesinin çalışması için, dosyalarının internete bağlı, 7 gün 24 saat açık bir bilgisayarda durması gerekir. Bunu “sunucu” (server) diye adlandırıyoruz. Kendi bilgisayarını hep açık tutup, güvenliğini sağlayıp, bir yerlerde barındırmak zahmetli ve pahalı bir iş. Cloudflare gibi şirketler, bu işi senin yerine yapıyor: sen dosyalarını onlara veriyorsun, onlar da dünyanın dört bir yanındaki kendi bilgisayarlarında (buna “sunucu ağı” diyelim) barındırıp, isteyen herkese ulaştırıyor.

Buradaki önemli detay şu: Cloudflare, sitesini tek bir şehirde değil, dünyanın onlarca farklı noktasında aynı anda tutuyor. Bunu bir markanın tek bir merkez mağazası yerine, her şehirde küçük bir şubesi olmasına benzetebilirsin. Türkiye’den birisi sitene girdiğinde, dosyalar Amerika’dan değil, ona en yakın şubeden geliyor — bu da siteni daha hızlı açıyor. Buna “edge” (kenar/uç) mimarisi deniyor, ve bu terimi aşağıda tekrar göreceğiz.

Biz Cloudflare’i üç şey için kullanıyoruz: sitemizi barındırmak (şu an yaptığımız şey), alan adımızı yönetmek (DNS), ve ileride kuracağımız küçük programları (API’ler) dünyaya yaymak. Ücretsiz katmanı kişisel bir blog için fazlasıyla yeterli, bu yüzden seçtik.

Şimdi, önümüzdeki aylarda öğreneceğim teknolojileri üç ana başlıkta topladım. Her başlık, bir önceki başlığın üzerine inşa ediliyor.

Birinci Katman: Yapay Zekayı Koda Entegre Etmek

Bugün herkes ChatGPT ya da Claude gibi bir yapay zekaya soru sorabiliyor. Ama bir web sitesinin ya da uygulamanın içine yapay zekayı güvenilir bir şekilde yerleştirmek, sohbet etmekten çok daha farklı bir iş. Sohbet ederken bir cevap yanlış çıkarsa sen fark edip düzeltirsin; ama bir uygulamanın arka planında çalışan bir yapay zeka, kimse görmeden yanlış bir işlem yapabilir. Bu yüzden onu “güvenilir bir bileşen” haline getirmek gerekiyor. Bu başlık altındaki üç kavram, tam olarak bunu sağlıyor.

Agentic Framework’ler (LangChain / LlamaIndex): Bir yapay zeka modelini, düşünen ama elleri olmayan bir beyin gibi düşün. Sen ona bir soru sorduğunda cevap verebilir, ama kendi başına bir veritabanına gidip bilgi çekemez, bir dosya oluşturamaz, bir e-posta gönderemez — çünkü onun “elleri” yok. LangChain ve LlamaIndex gibi araçlar, bu beyne eller takıyor: ona hangi “araçları” (bir veritabanını sorgulamak, bir web sitesini okumak, bir hesaplama yapmak) kullanabileceğini tanımlıyorsun, o da bir soruyu cevaplamak için bu araçları sırayla kullanarak kendi kendine adım adım ilerliyor. Buna “Agent” (ajan) deniyor — tıpkı sana bir görev verilen ve o görevi tamamlamak için gereken adımları kendi başına planlayan bir stajyer gibi. Bu framework’ler, bu “stajyer” davranışını sıfırdan kodlamak yerine hazır bir iskelet olarak sunuyor.

Vector Database’ler (pgvector / Pinecone / Qdrant): Bu biraz daha soyut ama çok önemli bir kavram. Bir yapay zeka modeli, eğitildiği veriyi “ezberlemiyor”, onun yerine kelimelerin ve cümlelerin anlamını bir dizi sayıya çeviriyor (buna “embedding” deniyor). Bu sayı dizisini bir tür “anlam koordinatı” gibi düşünebilirsin — benzer anlamlı iki cümlenin koordinatları birbirine yakın çıkıyor, alakasız iki cümlenin koordinatları birbirinden uzak. Vector database, işte bu koordinatları saklayıp, “bu cümleye anlamca en yakın olanlar hangileri?” sorusunu çok hızlı cevaplayabilen özel bir veritabanı türü. Bunu neden istiyoruz? Çünkü bir yapay zekaya kendi verilerini (mesela senin blogundaki yazıları) “öğretmek” istediğinde, tüm o metni modelin hafızasına zorla sokamazsın; onun yerine yazılarını bu anlam koordinatlarına çevirip saklarsın, kullanıcı bir soru sorduğunda önce anlamca en yakın yazıları bulursun, sonra yapay zekaya “cevabını bu yazılara dayandırarak ver” dersin. Buna RAG (Retrieval-Augmented Generation, yani “önce bul, sonra bu bulduğunla cevap ver”) deniyor. pgvector’ı özellikle seçme sebebim şu: zaten kullanacağımız Postgres veritabanının içine bu özelliği ekleyen bir eklenti, yani ayrı bir sistem kurmama gerek kalmıyor — tek bir veritabanı hem normal verilerimi hem de bu “anlam koordinatlarını” tutuyor.

LLM Gateway ve Observability (Helicone / LangSmith / Portkey): Bir yapay zeka modeline her “soru sorduğunda” (buna “çağrı” ya da “call” deniyor), bu işlemin bir maliyeti oluyor — tıpkı elektrik kullandıkça sayacın dönmesi gibi. Bir uygulamada bu çağrılar günde binlerce kez tekrarlanabiliyor, ve eğer bunu izlemezsen, faturanın nereden şiştiğini ya da bir hatanın nerede oluştuğunu bilemezsin. Bu araçlar, tam olarak elektrik sayacı ve sigorta kutusu gibi çalışıyor: her çağrının ne kadara mal olduğunu, ne kadar sürdüğünü, nerede hata verdiğini ve gereğinden fazla kullanıldığında devreyi kesip kesmeyeceğini (rate limiting) gösteriyor. Önceden tanıdığın PostHog’un kullanıcı davranışını izlemesi gibi, bunlar da yapay zeka çağrılarını izliyor diyebiliriz.

İkinci Katman: Performans ve Maliyeti Yöneten Altyapı

Yapay zeka katmanını bir eve monte edeceksen, önce sağlam bir temel lazım. Bu ikinci katman, o temeli oluşturuyor: sitenin/uygulamanın hızlı çalışması ve maliyetlerin makul kalması için gereken altyapı.

Cold Start problemi ve neden önemli: Klasik “sunucusuz” (serverless) sistemlerde, bir fonksiyon kullanılmadığı zaman “uyur”, biri ona istek gönderdiğinde önce “uyanması” gerekir — bu uyanma anına “cold start” (soğuk başlangıç) deniyor ve birkaç saniyeye kadar sürebilir. Bunu, hiç kullanılmayan bir dizel jeneratörün çalıştırılması gibi düşünebilirsin: anahtarı çevirirsin ama motor hemen değil, birkaç saniye sonra devreye girer. Kullanıcı için bu birkaç saniyelik gecikme, siteyi “yavaş” hissettirir.

Cloudflare Workers / Hono.js: Cloudflare Workers, yukarıda bahsettiğim “edge” mimarisini kullanarak bu cold start sorununu neredeyse ortadan kaldırıyor. Klasik jeneratör yerine, her an hazır bekleyen bir ışık anahtarı gibi düşün — anahtara bastığın anda ışık yanıyor, motor ısınmasını beklemiyorsun. Bunu, “V8 Isolate” denen, çok hafif ve anında başlayabilen küçük çalışma birimleri sayesinde yapıyor. Hono.js ise, bu Workers üzerinde küçük programlar (API’ler) yazmamı kolaylaştıran hafif bir araç seti — büyük ve karmaşık bir yazılım paketi yerine, sadece ihtiyacım olan temel parçaları içeren, hızlı ve sade bir araç kutusu gibi düşünebilirsin.

Serverless veritabanları (Neon Postgres / Supabase / Turso): Bir veritabanını klasik yöntemle çalıştırmak, sürekli açık, senin bakımını yaptığın bir jeneratör işletmek gibidir — kullanmasan da elektrik (ve para) harcar. Serverless veritabanları ise, tıpkı şehir şebekesinden elektrik almak gibi çalışır: sadece kullandığın kadar ödersin, kullanılmadığında sistem kendini “uyutur”, ihtiyaç olduğunda otomatik büyür. Firebase’i zaten biliyorsun; o “NoSQL” dediğimiz, esnek ama ilişkisel sorgulama gücü sınırlı bir sistem. Neon ve Supabase gibi araçlar ise Postgres tabanlı, yani verilerin birbiriyle ilişkili olduğu durumlarda (bir kullanıcının birden fazla yazısı, bir yazının birden fazla yorumu olması gibi) çok daha güçlü ve standart bir çözüm sunuyor.

Üçüncü Katman: Kod Kalitesini Koruyan Yapılar

Yapay zeka ile hızlı kod yazmak harika, ama hız kontrolsüz olursa kod hızla dağılabilir, hatalar fark edilmeden üretime sızabilir. Bu üçüncü katman, bu riski azaltan güvenlik mekanizmaları.

Type-Safe API’ler (tRPC / Prisma / Drizzle ORM): “Type” (tip), bir verinin ne tür olduğunu tanımlar — bir sayı mı, bir metin mi, bir tarih mi. Bunu, farklı şekillerdeki elektrik fişleri gibi düşün: yuvarlak pimli bir fiş, kare yuvaya sığmaz, ve bu uyumsuzluk fişi takmaya çalıştığın anda belli olur, cihazı çalıştırıp “neden yanmıyor” diye uğraşmana gerek kalmaz. Type-safe araçlar da böyle çalışıyor: frontend (kullanıcının gördüğü kısım) ile backend (arka planda çalışan kısım) arasında hangi verinin hangi biçimde gideceğini baştan tanımlıyor, ve eğer bir yerde uyumsuzluk varsa bunu kod çalışmadan önce, yazarken haber veriyor. Prisma ve Drizzle, veritabanı yapını kod içinde tanımlamanı ve bu tanıma göre otomatik kontrol yapılmasını sağlıyor; tRPC ise frontend ile backend’in aynı “dili” konuştuğundan emin oluyor.

AI Coding Agent’lar ve CI/CD Reviewer’lar (Claude Code / Cursor / CodeRabbit): Claude Code’u zaten tanıyorsun, bu blogu onunla kuruyoruz. CI/CD ise, her yeni kod değişikliğinde otomatik olarak devreye giren bir kalite kontrol hattı — bir fabrikadaki üretim bandının sonunda duran, hatalı bir parçayı fark edince bandı otomatik durduran kontrol istasyonu gibi düşünebilirsin. Kodun her değiştiğinde otomatik olarak test ediliyor, kontrol ediliyor, sorun yoksa yayına alınıyor. CodeRabbit gibi araçlar ise, bu kontrol istasyonuna ek olarak, her değişikliği okuyup “burada bir sorun olabilir” diye uyaran, yorulmayan bir ikinci göz gibi çalışıyor.

OpenTelemetry (OTel): Sentry’yi zaten biliyorsun — o bir duman dedektörü gibi, bir şey “yanınca” (yani sistemde hata/çökme olunca) seni uyarıyor. OpenTelemetry ise bundan daha fazlasını yapıyor: bir uçağın kara kutusu gibi, bir kullanıcı isteğinin sistem içinde attığı her adımı kaydediyor — hangi servisten hangi servise geçti, her adımda ne kadar sürdü, nerede yavaşladı. Sentry sana “bir şey koptu” der, OTel ise “işte tam olarak nerede, ne zaman ve nasıl koptu” der. Sistemler büyüyüp birden fazla parçadan oluşmaya başladığında (mesela bir API başka bir servise, o da veritabanına bağlanıyorsa), bu izleme kritik hale geliyor.

Bu üç katman neden bu sırayla?

Bir binayı düşün: önce temel (ikinci katımdaki edge ve veritabanı altyapısı), sonra o temel üzerine sağlam bir iskelet (üçüncü katmandaki kod kalitesi araçları), en son da içine taşınacak akıllı sistemler (birinci katmandaki yapay zeka araçları) gelir. Ben bu yazıda katmanları mantıksal önem sırasına göre anlattım, ama 0. Gündeki yol haritamda göreceğin gibi, gerçekte önce temeli (Faz 1-4), sonra yapay zeka katmanını (Faz 5) kuracağım. Sağlam bir temel olmadan yapay zeka eklemek, çürük bir zemine akıllı ev sistemi kurmaya benzer — çalışıyormuş gibi görünür, ama ilk sorunda her şey birlikte çöker.

Sırada ne var?

Bir sonraki yazıda, bu blogun ilk üç haftasını — Git’i kurmaktan alan adını bağlamaya, Astro’ya geçerken yaşadığım karışıklıklara kadar, hiçbir şey bilmeyen birine anlatır gibi — adım adım anlatacağım. Yukarıda okuduğun kavramların çoğu henüz elle tutulur değil; ama önümüzdeki aylarda her biri, bu sitenin içinde gerçek, çalışan bir özelliğe dönüşecek.