Ne yalan söyleyeyim, Yorum sistemi derken aklınıza ilk ne geliyor? Büyük ihtimalle: “Bunu sayfaya nasıl bağlayacağım?” İşin içine girince cevabın sandığınız kadar düz olmadığını görüyorsunuz — özellikle Next.js söz konusuysa (yanlış duymadınız). App Router kullananlar için tablo başka, Pages Router tarafındakiler için başka. Geçen Şubat 2026’nın hemen başında, bir müşteri projesinde tam da bu noktada duvara tosladım; ekibin yarısı yeni mimarideydi, eski blog bölümü ise hâlâ Pages Router üstünde duruyordu. Aynı yorum bileşenini iki tarafta da çalışır hale getirmek gerekiyordu (bizzat test ettim). Kağıt üstünde kolay? Evet. Pratikte? Biraz çetrefilli.
Neyse uzatmayalım. Burada anlatacağım yaklaşım tek bir küçük istemci bileşeniyle işi çözüyor — her sayfaya ayrı ayrı karmaşık kurulumlar serpiştirmek yerine, yorum widget’ını bir “adacık” gibi izole ediyorsunuz (şaşırtıcı ama gerçek). Bu hem bakım açısından rahatlatıyor hem de sayfanın geri kalanını server component olarak bırakabildiğiniz için performans tarafında elinizi güçlendiriyor (en azından benim deneyimim böyle). Ciddi fark var.
İşin Mantığı: Neden Tek Çözüm Yetiyor?
Aslında, Next.js bazen insana fazla seçenek veriyor gibi geliyor. Güzel tabii… ama aynı zamanda kafa karıştırıcı. App Router’da server component, client component, route segment derken konu dallanıp budaklanıyor; Pages Router’da ise yılların alışkanlığıyla daha düz bir yapı var. Bir yorum sistemi eklemek istiyorsanız esas mesele şu: widget tarayıcıda çalışacak mı, çalışırken sayfanın açılışını yavaşlatacak mı, soft navigation sonrası kendini yenileyecek mi?
Bi saniye — Bunu geçen yaz İstanbul Levent’te bir editoryal paneli incelerken canlı canlı gördüm (yanlış duymadınız). Sayfa ilk açılışta tertemizdi ama yorum kutusu üçüncü parti bir script yüzünden LCP’ye hafif yük bindiriyordu. Tam burada lazy load mantığı devreye girince nefes aldık. Şöyle düşünün: misafir salona girdiğinde önce kanepeyi görsün, sonra kahve gelsin. Önce ana içerik — yorumlar sıraya beklesin.
Kısa bir not düşeyim buraya.
Bak şimdi, Bu yaklaşımın en iyi tarafı ne peki? Server component zincirini bozmuyorsunuz. Yazı içeriği sunucuda kalıyor, sadece yorum alanı client tarafında ayağa kalkıyor. Küçük startup için güzel haber — minimum kodla iş çözüyorsunuz. Kurumsal projede ise avantaj farklı: güvenlik politikaları ve bakım süreçleri daha net yönetiliyor. İki farklı dünya, ama yaklaşım ikisine de oturuyor (yanlış duymadınız)
Kurulum Adımları: Az Kodla Temiz Entegrasyon
Bakın, İlk iş API anahtarı almak (kendi tecrübem). Widget sağlayıcısına kayıt olup alan adınızı tanımlıyorsunuz ve size verilen anahtarı alıyorsunuz. Açık konuşayım — ben bu kısmı test ederken en çok hata buradan çıktı. Geliştirici ekipler bazen domain’i yanlış giriyor ya da staging ile production anahtarlarını birbirine karıştırıyor; 2025 Aralık’ta İzmir’deki bir SaaS takımında tam bunu yaşadık — üç kişi aynı anda bakınca sorun bulunuyor sanıyorsunuz. Meğer.env dosyası yanlış repoya gitmiş. Klasik.
Sonra.env.local içine istemci tarafında okunabilecek şekilde değişkeni yerleştiriyorsunuz. Burada NEXT_PUBLIC öneki çok önemli; yoksa tarayıcı o değeri göremez ve “neden boş dönüyor?” diye bir saat kaybedersiniz. Hep öyle.
NEXT_PUBLIC_ECHOTHREAD_API_KEY=YOUR_API_KEYBileşenin kendisi de aslında baya sade kalıyor. Bir client component açıp widget’ın bağlanacağı div’i oluşturuyorsunuz; ardından script’i lazyOnload ile çağırıyorsunuz ki sayfa ilk boyandığında öncelik içerikte kalsın. Mantıklı, değil mi?
| Parça | Ne yapıyor? | Neden önemli? |
|---|---|---|
| .env.local | API anahtarını saklıyor | Kod içinde sert yazmıyorsunuz |
| use client | Bileşeni tarayıcıda çalıştırıyor | Script ve DOM erişimi için şart |
| lazyOnload | Widget’ı geç yüklüyor | LCP ve ilk render korunuyor |
| key ile remount | Sahne değişince yeniden kuruyor | Soft navigation sorununu kesiyor |
İnanın, Küçük ama önemli bir not: API anahtarını client’a açmak zorunda kalıyorsunuz ama bunu olabildiğince dar kapsamda tutmak gerekiyor. Her şeye yayarsanız gereksiz güvenlik riski doğar — sadece yorum alanının bilmesi gereken kadar bilgi verin, yeter.
App Router’da Kullanım
Size bir şey söyleyeyim, App Router tarafında mantık oldukça temiz ilerliyor. Yazı sayfasının server component kısmında post’u çekiyorsunuz, içerikleri basıyorsunuz (ben de ilk duyduğumda şaşırmıştım). Altına yorum bileşenini yerleştiriyorsunuz. Ben bunu ilk kez kendi blog altyapımda denediğimde — 2024 Eylül, Kadıköy — şaşırtıcı biçimde az eforla sonuç aldım. Beklediğim kadar uğraştırmadı, yani iyi anlamda yanıltıcı bir deneyim.
Küçük takımlar için bu çok rahat; ayrı bir layout mimarisi kurmadan ilerleyebiliyorsunuz. Büyük ekiplerde ise dikkat edilmesi gereken bir şey var: comment widget’ı gerçekten yalnızca gerektiği yerde render edin. Yoksa herkes her sayfada aynı script’i çağırmaya başlayınca performans borcu sessizce büyür. Fark ettiğinizde iş işten geçmiş olabilir.
Pages Router’da Ne Değişiyor?
Açıkçası burada devrim yok. Aynı komponenti pages/blog/[slug].tsx içine koyuyorsunuz; fark daha çok dosya yapısında hissediliyor, davranışta değil. Biraz eski usul ama iş görüyor.
Bazı ekipler Pages Router’dan çıkmak istemiyor — mevcut CMS entegrasyonları veya legacy modüller yüzünden bu gayet normal, anlıyorum. Ama dürüst olayım: uzun vadede yeni geliştirme yapılacaksa App Router çok daha ferah hissettiriyor. Bu benim görüşüm tabii, zorla kimseyi göçürmüyorum. Bu konuyla ilgili FOSRES Nedir? Açık Kaynak Güvenlik Eğitimi İçin Yeni Bir Yol yazımıza da göz atmanızı tavsiye ederim.
Sorun Çıkarsa Nereden Patlıyor?
Sahada gördüğüm hataların büyük çoğunluğu üç başlıkta toplanıyor: eksik API key, yanlış domain tanımı ve route değişince widget’ın yeniden yüklenmemesi. En çok da de soft navigation kısmı can sıkabiliyor; kullanıcı başka yazıya geçiyor (bizzat test ettim). Aynı comment thread ekranda kalmaya devam ediyor. Tuhaf bir his. Bu yüzden pathname’e bağlı key kullanmak mantıklı — widget sayfa URL’sine göre thread’i otomatik ayırıyor (buna dikkat edin)
Peki dezavantajı yok mu? Var tabii. URL yapınız çok düzensizse ya da canonical yapı tam oturmamışsa yorumların nerede toplandığını sonradan anlamak zorlaşıyor. Bir enterprise projede buna benzer bir durumda analytics ekibi “yorum niye iki farklı başlık altında görünüyor?” diye kapıya dayandı; sebebi query parametrelerinin thread ayrımı yaratmasıydı. Maalesef.
- Dikkat edin: staging domain ile canlı domain anahtarlarını karıştırmayın.
- Dikkat edin: widget script’ini iki kez yüklemeyin. (bu kritik)
- Dikkat edin: soft navigation sonrası remount kontrolünü test edin.
- Dikkat edin: CSP politikanız varsa CDN alan adını whitelist’e alın.
Yorum sisteminde en pahalı hata genelde görünmeyen hatadır: kullanıcıya “çalışmıyor” demezsiniz… sadece boş alan görürsünüz ve herkes birbirine bakar.
Küçük Proje mi Kurumsal Site mi?
Küçük bir startup’taysanız amaç basit olmalı. Hızlı yayınla, ölç, düzelt. Üçüncü parti bir çözüm baya işe yarar çünkü kendi yorum altyapınızı yazıp moderasyon paneliyle boğuşmazsınız —. Beta döneminde ücretsiz olması zaten cabası. Ama bir not düşeyim: ücretsiz dönem bittiğinde fiyatlandırmaya baştan bakmanız lazım, o kısmı ötelemek sonra sürpriz yaratıyor. Bu konuyla ilgili Agentforce Script: Salesforce’un AI Ajanlarına Getirdiği Fren Pedalı yazımıza da göz atmanızı tavsiye ederim.
Ve işler burada ilginçleşiyor.
Kurumsal tarafta tablo biraz farklı. Güvenlik ekipleri cookie davranışını sorar, hukuk departmanı veri saklama süresini sorar, ürün yöneticisi kullanıcı etkileşimini sorar — hepsi aynı anda, hepsi haklı. Teknik entegrasyon kolay olsa da operasyonel uyum kısmı biraz pişmesi gereken hamur gibi; acele etmek istiyorsunuz. Olmuyor. Ben açıkçası burada tek cümlede “tamamdır” demeyi sevmiyorum; önce kullanım senaryosunu netleştirin, sonra konuşalım diyorum. Apple ile Samsung Arasındaki Veri Savaşı: Antitröst Dosyasında Yeni Perde yazımızda bu konuya da değinmiştik.
Teknik Artılar ve Eksiler
Peki neden böyle bir widget iyi? Sıfırdan moderasyon paneli yazmıyorsunuz. Spam filtresi kurmuyorsunuz — çoğu zaman. Kimlik doğrulama akışıyla boğuşmuyorsunuz — Bunların hepsi ciddi vakit kazandırır; bunu küçümsemeyin. Ama karşılığında dış servise bağımlılık alıyorsunuz… işte can sıkıcı kısım tam burası.
Çok konuştum, örnekle göstereyim.
Bence en dengeli kullanım şekli şu: ana içerik sizde kalsın, yorum katmanı dış serviste olsun, ama mutlaka bir fallback planınız bulunsun. Mesela servis yavaşlarsa kullanıcıya küçük bir not gösterilebilir ya da alternatif bir iletişim formu bırakılabilir. Kağıt üzerinde küçük görünür bunlar — ama sahada hayat kurtarır. Gerçekten.
Sıkça Sorulan Sorular
Evet… Bu yöntem hem App Router hem Pages Router’da çalışır mı?
Evet çalışır. Mantık aynı kaldığı sürece sadece dosya yapısını uyarlamanız gerekir. Asıl fark comment bileşeninin nerede render edildiğinde ortaya çıkar.
NEXT_PUBLIC öneki neden gerekli?
Çünkü tarayıcı tarafındaki kodun o değişkene erişmesi gerekir\. Önek olmazsa çevre değişkeni yalnızca sunucu tarafında kalır ve widget boş döner.\*
Aynı yorumu farklı yazılarda nasıl ayırıyor?
Bakın, Pek çok widget sisteminde thread eşlemesi sayfa URL’si üzerinden yapılır\. Bu yüzden URL’nizin temiz ve sabit olması önemli.\*
LCP etkilenir mi?
Küçük bir detay: Eğer script’i erken yüklerseniz evet etkilenebilir\. lazyOnload ya da benzeri geciktirilmiş yükleme stratejileri bu riski azaltır.\*
Kaynaklar ve İleri Okuma
Next.js App Router Dokümantasyonu
Next.js Pages Router Dokümantasyonu
Ayrıca konuyla bağlantılı olarak sitemizde şu yazılara da göz atabilirsiniz:
JavaScript’te Async Mantığı: Event Loop’u Gerçekten Anlamak,
Veritabanı Gözlemlenebilirliği: SQL’den Buluta Tam Görünürlük,
Cybersecurity Bitmiyor, Şekil Değiştiriyor: Asıl Hikâye.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
