iToverDose/Yazılım· 6 MAYIS 2026 · 00:07

Kotlin ve Next.js ile çok dilli AI araçları dizini nasıl inşa ettim: 6 aylık acı dolu dersler

Tek başınıza bir AI araçları dizini inşa etmek zordur — mimari seçimlerden SEO tuzaklarına kadar her adımda beklenmedik engellerle karşılaşırsınız. Fransızca-İngilizce destekli bu proje, 1.400'den fazla aracı bir araya getirirken, 37 kategori altında karşılaşılan teknik ve stratejik zorlukları gözler önüne seriyor.

DEV Community4 dk okuma0 Yorumlar

Küçük bir takımla çalışmaya alışkınken, tek başıma geliştirme yaptığımda karşılaştığım ilk zorluk, insanların sürekli sorduğu bir soruya yanıt bulmaktı: "Neden Kotlin ve Next.js?"

Projenin adı AI Explorer — çok dilli bir AI araçları dizini. Sadece bir karşılaştırma sitesi değil; aynı zamanda 37 farklı kategoride 1.424 aracın yer aldığı, Fransızca ve İngilizce destekleyen bir platform. Peki neden bu kadar özel? Çünkü mevcut birçok AI dizini ABD merkezli ve içeriklerini genellikle Google Translate ile çeviriyor. Oysa ben, yerel kullanıcıların ihtiyaçlarına odaklanan, uzun kuyruklu kategorilerde de derinlemesine arama yapılabilen bir yapı kurmayı hedefledim.

Projeye başlarken, karşılaşacağım teknik zorlukları kestiremiyordum. Ama altı ayın sonunda, mimari seçimlerimden SEO stratejilerime kadar her adımda öğrendiklerim, gelecekteki projelerim için değerli bir rehber oldu.

Kotlin’in ardındaki mantık: Neden tercih ettim?

Backend için Kotlin ve Ktor kullanmaya karar verdim. Bu seçim, çoğu geliştiriciyi şaşırtan bir tercihti.

  • "Neden Node.js değil? Tek bir dilde kalabilirdin."
  • "Go daha hızlı ve basit olurdu."
  • "Python kullanmaz mısın? AI dünyasında herkes Python kullanıyor."

Aslında cevap basitti: Kotlin’de üretkendim. Yıllardır profesyonel olarak Kotlin kullanıyordum ve bu dili tercih etmemin en büyük nedeni, verimliliğimdi. Ktor ile birlikte Exposed ORM ve HikariCP kullanarak, Node.js prototipinde zorlandığım tip güvenliği ve eşzamanlılık kontrolü konusunda önemli avantajlar elde ettim. Özellikle, birden fazla API’ye (zenginleştirme, resim işleme, veritabanı yazmaları) aynı anda yapılan isteklerde coroutine’lerin ne kadar güçlü olduğunu gördüm.

Ancak dürüst olmak gerekirse, ilk günden itibaren Kotlin’e odaklandım ve başka bir seçeneği düşünmedim. Bazen doğru teknoloji, üzerinde çalıştığınız ve tamamladığınız teknolojidir.

Teknik detaylara gelirsek:

  • Veritabanı: PostgreSQL (Flyway ile migrations)
  • JVM ayarları: -Xms1g -Xmx3g -XX:+UseG1GC
  • Barındırma: OVH VPS (24 GB RAM, 8 vCore, yaklaşık 24 Euro/ay)

Tabii ki, maliyetleri daha da düşürmek mümkün. Alternatif olarak, 200 Euro/ay gibi bir bütçeyle Vercel’de de çalıştırabilirdim. Ama benim için önemli olan, kontrolü elimde tutmaktı.

Gelecekteki bir hedefim var: Tüm AI API’lerini bırakıp, yerel olarak çalışan bir sunucuya geçmek. Mistral, Qwen, Llama gibi modelleri tamamen kendi sunucumda çalıştırmak istiyorum — bu sayede platform bağımlılığından kurtulmuş, hız sınırlaması olmayan bir sistem kurabilirim. OVH’nin sunduğu Ryzen + 64 GB RAM + 4090 sınıfı GPU’ya sahip bir sunucu yaklaşık 200-400 Euro/ay tutuyor. Gelir yeterli olmadığı için şimdilik bekliyorum, ama donanım meraklısı olarak bu fikir beni çok heyecanlandırıyor.

Next.js App Router tuzağı: Veri getirme ve caching stratejisi

Next.js App Router’ı kullanmaya karar verdiğimde, bunu yaptığım için mutluydum — ta ki üretim ortamında karşılaştığım performans sorunlarına kadar.

App Router, sunucu bileşenlerinde veri getirmeyi ve doğrudan render etmeyi çok kolay hale getiriyor. Geliştirme aşamasında her şey güzel görünüyordu. Ama yayınladığımda, her sayfa istekinin backend API’sine giderek veriyi yenilediğini ve TTFB’nin (Time to First Byte) "utandırıcı" seviyelere düştüğünü fark ettim.

İki hafta boyunca, `revalidate`, ISR (Incremental Static Regeneration) ve Cloudflare düzeyinde edge caching stratejilerini optimize etmekle uğraştım. Next.js belgeleri basit görünse de, gerçek dünyada işler karmaşıklaşıyor. Örneğin:

  • Bazı sayfaların günlük, bazılarının haftalık, bazılarının ise sadece kullanıcı içerik eklediğinde güncellendiğini düşünün.
  • Bu durumda, cache invalidation (önbellek geçersiz kılma) sistemi kurmanız gerekiyor — ve herkes bilir ki, cache yönetimi yazılım mühendisliğinin en zor problemlerinden biridir.

Eğer tekrar yapma şansım olsaydı, veri tazeliği gereksinimlerini haritalamak için bir gün harcardım. Bu, ileride haftalarca sürecek baş ağrılarından kurtarırdı.

Kendim yaptığım SEO faciası: Nasıl düzelttim?

Bu kısım benim için en acı olanıydı.

Üç hafta öncesine kadar, "LLM Sayfaları" adı altında bir özellik vardı. Temelde, HuggingFace’ten alınan her AI modeli için ayrı bir sayfa oluşturuyordum. Mantıklı görünüyordu, ama kısa sürede 3.000 adet ince içerikli sayfa ortaya çıktı ve arama motoru indeksimi kirletmeye başladı.

Bu sayfaları kaldırmaya karar verdim ve 410 Gone (Sayfa kalıcı olarak silindi) yanıtı verdim, sitemap’i güncelledim ve robots.txt dosyasını düzenledim. Her şeyi doğru yaptım — ama Google’ın algoritmasının tepkisini tahmin edemedim.

İki hafta içinde, 7.500 olan indekslenmiş sayfa sayım 954’e düştü. Önce panik yaptım ve algoritmik bir cezalandırma yaşadığımı düşündüm. Gece geç saatlerde Search Console’u sürekli yeniledim. Sonunda anladım ki, Google, silinen içerikleri çok hızlı bir şekilde indeksinden çıkarırken, yeni içeriklerin keşfini de yavaşlatıyordu.

Bu durumun geçici olduğunu anlamak için birkaç gün beklemem gerekti. Sabırlı olmak zorundaydım.

Bu deneyimden çıkardığım ders: İçerik silerken, sadece teknik olarak doğru işlem yapmak yetmez — arama motorlarının algısını da yönetmek gerekir.

Geleceğe bakış: Ne öğrendim ve neler değişecek?

Altı ay boyunca süren bu yolculukta, mimari seçimlerimden içerik stratejilerime kadar her adımda öğrendiklerim, gelecekteki projelerim için değerli bir rehber oldu.

  • Kotlin ve Ktor, verimlilik ve kontrol açısından doğru tercihti — ama donanım maliyetleri ve yerel AI çalıştırma fikri, hala aklımı kurcalıyor.
  • Next.js App Router, geliştirmeyi kolaylaştırırken, caching stratejisi konusunda dikkatli olmak gerekiyor.
  • SEO, sadece teknik bir konu değil — içerik yönetimi ve algoritmik tepkiler de büyük önem taşıyor.

Gelecekte, AI araçlarını tamamen yerel olarak çalıştıran bir sistem kurmayı hedefliyorum. Bu, platform bağımlılığından kurtulmanın yanı sıra, performansı ve gizliliği de artıracak. Ayrıca, dizini daha da genişleterek AI’nin yerel uygulamalarda nasıl kullanılabileceğine dair daha fazla içerik üretmeyi planlıyorum.

Tek başına çalışmak zorlu olabilir — ama her adımda yeni bir şey öğrenmek, bu zorlukları bir nebze olsun hafifletiyor.

Yapay zeka özeti

Tek başına Kotlin ve Next.js kullanarak çok dilli bir AI araçları dizini inşa etmek ne kadar zor? 6 aylık deneyimlerden çıkan mimari, SEO ve donanım dersleri.

Yorumlar

00
YORUM BIRAK
ID #OPVJLR

0 / 1200 KARAKTER

İnsan doğrulaması

5 + 5 = ?

Editör onayı sonrası yayına girer

Moderasyon · Spam koruması aktif

Henüz onaylı yorum yok. İlk yorumu sen bırak.