JavaScript kütüphaneleri için yeni bir loglama yaklaşımı: LogTape

Kütüphane vs uygulama: temelde farklı loglama gereksinimleri

• Uygulama loglaması: geliştiricinin doğrudan kontrol ettiği bir ortamda açık yapılandırma ve yönetim
• Kütüphane loglaması: başkalarının projelerine dahil olur; kullanıcı ortamına ve tercih hakkına saygı duyması gerekir
• Mevcut yaklaşımın sınırları: uygulama odaklı logger'ları (winston, Pino) kütüphanelere uygularken dayatma sorunu ortaya çıkar
• Kütüphane geliştiricisinin ikilemi: hata ayıklama bilgisi sağlamak ile kullanıcıya yük bindirmemek arasında denge kurmak

Güncel kütüphane loglamasının sorunları

• Parçalanmış loglama ekosistemi: Express DEBUG=express:*, Mongoose ise mongoose.set('debug', true) gibi birbirinden farklı yöntemler kullanıyor
• Bağımlılık ikilemi: winston ve Pino gibi uygulama odaklı kütüphaneler kullanıldığında, kullanıcıya istenmeyen bağımlılıklar ve yapılandırmalar dayatılabiliyor
• Sessizlik vs dayatma: ya loglamadan tamamen vazgeçmek ya da kullanıcıya belirli bir loglama yöntemini zorunlu kılmak gibi iki uç seçenek
• Bağımlılık enjeksiyonunun karmaşıklığı: daha rafine bir yaklaşım olsa da API karmaşıklığını ve kullanıcı yükünü artırıyor

LogTape'in "önce kütüphane" felsefesi

• Koşullu etkinleştirme: loglama yapılandırılmadığında tamamen devre dışı kalır, yapılandırıldığında ise birleşik şekilde yönetilir
• Kullanıcı tercih hakkını koruma: kütüphane loglama yöntemini dayatmaz; yalnızca kullanıcı istediğinde etkinleşir
• Sıfır bağımlılık: 5.3KB boyutuyla tedarik zinciri güvenliği risklerini ortadan kaldırır ve sürüm çakışmalarını önler
• Tam ESM/CJS desteği: uyumluluk zinciri sorunlarını çözer ve tree shaking ile bundle optimizasyonu sağlar

Pratik avantajlar

• Performans optimizasyonu: devre dışıyken neredeyse sıfır ek yük, etkinleştirildiğinde ise güçlü konsol çıktı performansı
• Namespace ayrımı: ["my-lib", "feature"] biçimindeki hiyerarşik kategorilerle çakışmaları önler
• TypeScript öncelikli tasarım: ek type paketi olmadan tam type safety sağlar
• Mevcut sistemlerle köprü kurma: winston ve Pino adaptörleriyle kademeli geçişi destekler

Gerçekçi değerlendirmeler

• Adaptörlerin anlamı: bunun henüz ekosistem standardı olmadığı gerçeğini kabul eden pratik bir uzlaşma
• Python ekosisteminden ilham: standart logging kütüphanesi etrafında birleşen Python'un başarılı örneğine referans veriyor
• Geleceğe dönük yaklaşım: kütüphane ekosistemini kademeli olarak iyileştirmek için sunulan bir seçenek

[sunrabbit]

Ayar yapılmadığında neden tamamen çalışmaz olduğunu anlamakta zorlanıyorum.
getLogger çağrıldığında zaten logger oluşturuluyor ve debug yazdırılırsa çalışıyor sonuçta.

Ben kodu gördüğümde, sadece çalışmıyormuş gibi gösteriyor gibi görünüyor
ve string işlemlerini de ertelemiyor, bu yüzden
sadece log seviyesi ayarlandığında yazdırmayan diğer kütüphanelerden bu "çalışmama" durumunun nasıl farklı olduğunu pek anlayamıyorum.

[hongminhee]

Hmm, configure()/configureSync() çağrılmamış olmasına rağmen günlükler yazdırılıyor mu? Nereye yazdırılıyor? Konsol ekranına mı yazdırılıyor?

[sunrabbit]

Ah, burada bahsettiğim "çalışıyor" olmasının anlamı, logların console ya da dosyaya kaydedilmesi değil; fonksiyonun çalıştırılıp çalıştırılmadığı ve bunun gerçekten bir ek yük oluşturup oluşturmadığıydı.

Yanlış anlaşılmaya açıkmış.

[sunrabbit]

Elbette logger’ın başlıca ek yükünün system call olduğu düşünüldüğünde hiç ek yük yok denemez.
Ama bunu diğer logger’lardan ayrıştıran bir fark olarak görmek zor; çünkü diğer logger’lar da aynı şekilde çalışıyor.

[hongminhee]

Aha, demek istediğiniz buydu. Öncelikle, null output ölçütüne göre benchmark çalıştırdığımda neredeyse hiç ek yük olmadığını söyleyebilirim. Ancak performans ek yükünden daha önemli olduğunu düşündüğüm şey, varsayılan davranışın no-op olup olmamasıydı. Kütüphane yazarı açısından bakıldığında, kütüphane içinde log alınsa bile, o kütüphaneyi kullanan uygulama çalıştığında konsola ya da dosyaya kendiliğinden log basılması sorun yaratabilir.

[sunrabbit]

Aha, meğer bu SHOW GN’miş.
Son zamanlarda ekosistem daha çok logger’ın dışarıdan enjekte edildiği yapıları seçtiği için, sanırım bana çok hitap etmemesinin sebeplerinden biri de buydu.
Yapılandırılmazsa doğal olarak çalışmıyor çünkü.
Yine de şimdiye kadar o ekosistemde olmayan bir logger arayüzü olması ve esnekliğinin yüksek olması nedeniyle daha iyi görünüyor.

Paylaştığınız benchmark ölçütünde system call hariç tutulup null output üretildiği için
bu kısmın dahili logger yapısına göre gerçekten farklılık gösterebileceğini düşünüyorum.

Bu noktada Pino’yla arada üç kata kadar fark açılıyor. Vay be.

---

FYI: Ek olarak, bahsettiğim dışarıdan enjekte edilen logger yapısını sadece Openai Node sdk’ya baksanız bile kolayca görebilirsiniz; orada da logger dışarıdan enjekte edilip çıktılar bu şekilde üretiliyor.

[sunrabbit]

https://github.com/dahlia/logtape/…