Building a directory site sounds trivial until you find yourself wiring up databases, caching layers, and reactive front

Bir dizin sitesi kurmak, aslında küratörlüğünü yaptığınız bir içindekiler tablosunu görüntülemek için veritabanlarını, önbellekleme katmanlarını ve reaktif ön uç çerçevelerini birbirine bağlamak zorunda kalana kadar önemsiz görünür. Yakın zamanda sosyal medya yazılımlarını karşılaştıran bir site olan Social Tools List'i kurdum. Amacım, siteyi hızlıca yayına almak, hızlı tutmak ve yalnızca bir aracı eklediğimde veya güncellediğimde değişen içerikler için altyapı bakımından kaçınmaktı. Statik öncelikli bir yığın (stack) üzerinde karar kıldım: Site oluşturma için Astro, yapılandırılmış veriler için TypeScript ve dağıtım için Cloudflare Workers. Sonuç; anında yüklenen, barındırma maliyeti neredeyse sıfır olan ve veritabanı yönetimi gerektirmeyen bir site oldu.

Bir Dizin Sitesi İçin Neden Statik Öncelikli Yaklaşım Mantıklıdır

Birçok web uygulaması, güvenli ve modern seçenekler gibi göründükleri için varsayılan olarak sunucu tarafı oluşturma (server rendering) veya tek sayfa (single-page) mimarilerini kullanır. Ancak her site, her istekte dinamik kullanıcı girdisi almaz. Social Tools List, okuma ağırlıklı bir kaynaktır. Karşılaştırma verileri, bir ziyaretçi sayfayı yenilediğinde değil, ben bir güncelleme gönderdiğimde değişir. HTML'i önceden oluşturmak; uç noktalarda (edge) veritabanı sorgularına, anlık şablon derlemeye veya tarayıcıdaki hydration yüküne olan ihtiyacı ortadan kaldırır. Siteyi derleme (build) aşamasında oluşturuyor, statik dosyaları dağıtıyor ve sarmalayıcıyı (wrapper) hafif bir worker'ın yönetmesine izin veriyorum. Bu, yanıt sürelerini düşük tutar ve bir dizi çalışma zamanı (runtime) hatasını tamamen ortadan kaldırır.

Verileri Veritabanında Değil, TypeScript'te Saklayın

Veritabanı kullanmıyorum. Dizindeki her araç; bir slug, isim, alan adı ve desteklenen iş akışlarından oluşan bir dizi içeren bir TypeScript nesnesi olarak tanımlanıyor. Tipik bir giriş şuna benzer:

{
  slug: 'buffer',
  name: 'Buffer',
  domain: 'buffer.com',
  workflows: ['scheduling', 'analytics']
}

Verileri siteyi oluşturan aynı dilde saklamanın iki doğrudan faydası vardır. Birincisi, pull request'ler içerik incelemelerine dönüşür. Bir araç eklediğimde, fark (diff) tam alanları ve değerleri gösterir; böylece bir ekip arkadaşım bir CMS arayüzü öğrenmek zorunda kalmadan yazım hatasını veya yanlış bir alan adını fark edebilir. İkincisi, TypeScript derleyicisi her kaydın yapısını zorunlu kılar. Eğer bir slug eklemeyi unutursam veya bir iş akışı anahtarını yanlış yazarsam, hatalı veri bir sayfaya ulaşmadan derleme başarısız olur.

Bir veritabanı; migrasyonlar, bağlantı dizeleri, önbellekleme stratejileri ve yedekleme rutinleri getirecektir. Manuel olarak yönettiğim birkaç yüz girişli bir dizin için bu ek yük tamamen gereksiz bir ağırlıktır. TypeScript modüllerindeki statik veriler, bu model için en ucuz ve doğru seçimdir. "Doğru" kısmı önemlidir. Bu sadece para tasarrufuyla ilgili değil; sahip olmadığım sorunları çözen soyutlama katmanlarını ortadan kaldırmakla ilgilidir.

Yönlendirme ve Oluşturma İşini Astro'ya Bırakın

Astro, tek bir dinamik rotadan her araç için bir HTML sayfası oluşturur. Bir düzen (layout) bileşeni tanımlıyorum ve Astro, her giriş için meta verileri, başlıkları ve yapılandırılmış verileri otomatik olarak basıyor. Aynı veri seti ana dizini, iş akışı kategorisi merkezlerini ve bireysel detay sayfalarını beslediği için, ana sayfadaki bir kartın detay sayfasındakinden farklı bir açıklama gösterme ihtimali yoktur. Geleneksel CMS kurulumlarında genellikle bir sapma (drift) görürsünüz: API bir sürümü, önbellek başka bir sürümü, istemci tarafı oluşturma (client-side render) ise üçüncü bir sürümü döndürür. Tek bir doğruluk kaynağından (single source of truth) yapılan statik oluşturma bunu engeller.

Astro'nun ada (island) mimarisi, tüm sayfayı JavaScript ile kirletmeden küçük etkileşimli parçalar eklemeyi de kolaylaştırır. Site statik HTML olarak sunulur ve yalnızca filtreleme betiği DOM'un belirli bir köşesini hydrate eder. Tüm belgeyi sarmalayan bir framework çalışma zamanı (runtime) yoktur. Astro ayrıca sayfa meta verilerini birinci sınıf bir öncelik olarak ele alır. Her araç sayfası, doğrudan TypeScript kaydından türetilen kendi başlık etiketine ve meta açıklamasına sahip olur, bu nedenle ayrı bir eklentiye veya bir head yönetim kütüphanesine ihtiyacım olmaz.

Bir Framework Olmadan Filtreleme

Arama ve filtreleme işlemleri genellikle geliştiricileri React, Vue veya ağır bir durum yönetimi (state management) kütüphanesi kurmaya iter. Ben buna direnç gösterdim. Astro, tüm listeyi sunucuda düz HTML olarak oluşturur. Bir kilobayttan daha küçük, küçük bir vanilla JavaScript betiği tarayıcıda çalışır ve bir iş akışı etiketine veya metin eşleşmesine göre liste öğelerinin görüntüleme (display) özelliğini değiştirir.

Serving the complete markup sounds inefficient if you come from an API-driven background. But consider the overhead of a typical dynamic approach. The browser downloads a JavaScript bundle, hydrates a component tree, calls an endpoint, waits for JSON, and then renders rows. For a directory that lists fewer than one hundred tools, that ritual is slower and less reliable than hiding divs that are already in the document. My script attaches event listeners to filter buttons, reads a data-workflow attribute on each row, and sets non-matches to hidden. The operation takes milliseconds.

Because the list is present in the initial HTML, the site is usable without JavaScript. Search engine crawlers see every link and every description. Users on slow networks or with script blockers still get the full directory. The filtering is an enhancement, not a gate.

Sitemaps and Robots as Code

Sitemaps and robots.txt are not afterthoughts written by hand. They are Astro routes that consume the same dataset and URL helpers as