Dürüst olmak gerekirse, Postgres tarafında LISTEN/NOTIFY ile uğraşan herkesin ortak bir yarası var. Kısa, masum görünen bir debug işi bir anda sabır testine dönüşüyor. Ben bunu ilk kez 2023 sonbaharında, Kadıköy’deki bir müşteri projesinde yaşadım; terminal açık, event bekliyorum, her şey yolunda gibi… derken bağlantı gidiyor. Sonra yeniden bağlan, aynı kanalı dinle, tekrar dene — iş uzuyor da uzuyor, hiç bitmeyecek gibi. O akşam geriye dönüp baktığımda “neden bu kadar uğraştım?” diye kendi kendime sordum, cevabı da biliyordum zaten.
İnanın, İşin aslı şu ki bu problem teknik olarak “zor” değil. Sadece can sıkıcı. Hani şu 40 satırlık Node scriptini altıncı kez yazarsın ya… işte tam o nokta. Rohith Gilla’nın anlattığı yaklaşımın güzel tarafı da burada: meseleye sadece “nasıl dinlerim?” diye bakmıyor, “bunu nasıl insan gibi kullanırım?” diye yaklaşıyor.
Neden Klasik Yöntem Çabuk Bayatlıyor?
Eskiden ben de herkes gibi küçük bir listen.js dosyası açıp içine birkaç satır atıyordum. pg.Client, LISTEN channel, sonra notification event’i geldi mi ekrana bas… Bitti sanıyorsun. Ama gerçek hayatta bitmiyor. Çünkü bu işin içinde ağ var, tunnel var, laptop uykuya dalıyor, Wi-Fi hop gidiyor, Postgres restart ediyor — bunlardan herhangi biri oldu mu script orada öylece kalıyor, kimseye bir şey söylemeden.
Evet, doğru duydunuz.
Geçen yıl Berlin’de yaptığım bir uzaktan demo sırasında tam da bu oldu. Kanalı dinleyen script çalışıyordu ama olay tetiklendiğinde sistem arka planda uyku moduna geçmişti. O an yüzümdeki ifade muhtemelen çok netti: beklediğim kadar değildi. Çünkü teoride çalışan şey pratikte biraz nazlı çıkabiliyor — özellikle müşteri karşısında.
Bence en sinir bozucu kısım da şu: olay kaçarsa geri dönüp bakmak zorlaşıyor (şaşırtıcı ama gerçek). Terminali kapatıp açarsın… ve o hayati bildirim çoktan uçmuştur. Bir nevi kapının önünde nöbet tutarken kahve almaya gidersin, geri döndüğünde de misafir gitmiştir. Ne yapacaksın?
Çok konuştum, örnekle göstereyim.
Daha İyi Bir İzleme Paneli Ne Sunmalı?
Lafı gevelemeden söyleyeyim: iyi bir LISTEN/NOTIFY deneyimi sadece “mesaj geldi” dememeli. Timestamp göstermeli, kanal adını açıkça yazmalı, payload’ı okunur vermeli ve mümkünse geçmişi saklamalı. Çünkü debug çoğu zaman canlı akışı izlemekten ibaret değil; bazen beş dakika önce ne olduğunu da görmek istiyorsun, hani “az önce bir şey geçti, ne geçti acaba?” dediğin o anlar var ya.
Size bir şey söyleyeyim, Bunu kendi projelerimde birkaç kez test ettim. Bilhassa Şubat 2024’te Ankara’da kurduğumuz küçük bir içerik kuyruğu sisteminde mesajların kaybolmadığını doğrulamak için tarih damgası baya işe yaradı. Basit görünür ama ayrıntı burada gizli: log yoksa tahmin yaparsın, log varsa karar verirsin. İkisi arasındaki fark bazen saatlik debug süresine denk geliyor. Claude Code ile Hata Düzeltmeyi Otomatikleştirmek: PR’a Giden Yol yazımızda bu konuya da değinmiştik.
E tabi tek konu görsellik değil; güvenilirlik daha önemli. Panel güzel olabilir ama bağlantı düşünce dağılıyorsa pek anlamı kalmıyor. Küçük startup için bu durum “idare eder”, ama enterprise seviyede resmen kırmızı alarmdır.
Küçük araç büyük fark yaratıyor
Pek çok ekip hâlâ geçici scriptlerle ilerliyor çünkü ilk başta mantıklı geliyorlar — hızlılar, ucuzlar ve hemen hazır oluyorlar. Ama gün sonunda debug işi üretime yakınlaşınca o geçici çözüm kalıcıya dönüşüyor. E peki, sonuç ne oldu? İşte tam orada sürtünme başlıyor. Daha fazla bilgi için Razer’ın İki Kulaklığı: Benzer Görünüp Ayrılan İnce Çizgi yazımıza bakabilirsiniz.
Bir debug aracı yalnızca mesaj göstermek için değil; bağlantı kopunca seni ortada bırakmamak için vardır.
Sessiz Kahramanlar: Yeniden Bağlanma ve Kalıcılık
Kendi deneyimimden konuşuyorum, Konu burada ciddileşiyor. Uzun yaşayan listener’larda üç klasik dert var: client düşer, tunnel kopar veya backoff ayarı saçmalar ve sunucuyu gereksiz yere dürtersin. Bunlardan biri bile olursa sen “neden çalışmıyor?” diye paniklerken sorun aslında altyapının doğal davranışıdır.
Beni en çok etkileyen parça reconnect mantığı oldu. Başlangıç gecikmesi küçük tutuluyor, hata oldukça süre katlanıyor ve üst sınırla frenleniyor. Bu şekilde sistem hem çevik kalıyor hem de kırılgan davranmıyor. Hmm, basit bir fikir aslında ama tam yerinde. Agentic Yapay Zekâda İz Sürmek: Monitor Et, Ölç, Kurtul yazımızda bu konuya da değinmiştik.
| Durum | Klasik Script | Daha Olgun Yaklaşım |
|---|---|---|
| Bağlantı kopması | Script durur, sessizce ölür | Backoff ile otomatik yeniden bağlanır |
Masaüstünde bunun önemini küçümseyebilirsin ama ben iki ayrı dizüstü bilgisayarda aynı scripti tekrar yazdığımı hatırlıyorum; biri MacBook Pro idi, diğeri eski bir ThinkPad T14’tü (Ekim 2024). Neden? Çünkü dosyanın nereye kaydedildiğini unutmuşum! Böyle anlarda insan kendine kızıyor tabii…
Neden destroyed bayrağı önemli?
Burası ince detay gibi duruyor ama baya kritik olabilir. Eğer nesne gerçekten kapanmışsa yeniden bağlanmayı denemenin hiçbir faydası yok. O bayrak, arka — kendi adıma konuşayım — planda sessizce çalışan timer’ların boş yere döngüye girmesini engelliyor. Açık konuşayım: bu tarz küçük korumalar olmasa UI tarafında tuhaf hayalet davranışlar görürdünüz — şunu biliyorum çünkü gördüm, bir keresinde (buna dikkat edin) Deploy Sonrası Yavaşlayan Metodu Bulan Küçük Bir Araç yazımızda da bu konuya değinmiştik. VC’siz Büyüme Mümkün mü? RunPod’un İlginç Dersi yazımızda da bu konuya değinmiştik.
Main Process Mantığı Neyi Değiştiriyor?
Hani, Dikkat edersen mimari seçim de gayet sade: bağlantılar Electron main process’te tutuluyor, renderer ise sadece subscribe/unsubscribe mesajları yolluyor. Bu bana hep otel resepsiyonu örneğini hatırlatır; oda kartını alan kişi başka, anahtarları yöneten kişi başka. Böyle olunca ekran tarafındaki karmaşa azalıyor.
Bunu geçenlerde İstanbul Maslak’ta yaptığımız iç araç değerlendirmesinde tekrar düşündüm. Arka plandaki uzun yaşayan bağlantıları UI’da tutmaya kalkınca uygulama şişiyor, hata ayıklamak da zorlaşıyor. Main process modelinde ise sorumluluk daha net; yani kafası karışık kod yerine daha sakin kod alıyorsun.
- Tepkiler IPC üzerinden geliyor, yani ekran tarafı hafif kalıyor.
- Aynı connection üzerinde çoklu kanal izlemek mümkün oluyor. — bunu es geçmeyin
- Kapanma/yeniden başlama senaryolarını merkezi yönetmek kolaylaşıyor. (bu kritik)
- Kullanıcı penceresi kapanınca listener’ları temizlemek daha düzenli hale geliyor.
Küçük startup ile kurumsal ekip neden farklı bakar?
Küçük ekipte mesele hızdır; kurumsalda mesele kontrol, gözlemlenebilirlik ve bakım maliyetidir. Startup için “bir şekilde çalışsın” yaklaşımı bazen yeterli, hatta kabul edilebilir. Ama veri akışı büyüyünce aynı yöntem çocuk oyuncağı olmaktan çıkar, resmen operasyon yüküne dönüşür.
Eğer günlük onlarca notification geliyorsa, history saklamak lüks değil ihtiyaçtır. Hele compliance veya audit beklentisi olan yapılarda geçmişi kaybetmek hiç hoş olmaz. Bir not defterine aceleyle isim yazıp sonra silmek gibi düşünün; evet yazdınız ama kim okudu, ne zaman okudu — belli değil.
Peki Gerçek Hayatta Ne Kazandırıyor?
Bence en büyük kazanım huzur hissi gibi görünüyor ama aslında doğrudan verimlilik sağlıyor. Debug süresi kısalınca — kendi adıma konuşayım — ekip tartışmaları azalıyor, yanlış varsayımlar çabuk eleniyor ve özellikle production’a yakın ortamlarda risk düşüyor. Bir özellik iyi mi kötü mü hemen anlayabiliyorsun, dolayısıyla gereksiz PR trafiği de azalıyor.
Bir arkadaşım İstanbul Ataşehir’deki fintech ekibinde buna benzer bir panel kullandı; üç ay içinde debug süresinin yaklaşık %40 azaldığını söyledi. Ben ilk duyduğumda abartılı bulmuştum, sonra hak verdim:. Her seferinde script yazmak yerine hazır bir görünürlük katmanı kullanmak gerçekten fark yaratıyor (ciddiyim). Tabii her proje aynı kazancı vermez; bazı yerlerde etkisi orta seviyede kalabilir.
Sıkça Sorulan Sorular
”
“}
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.
