"Statik Web Sitesi"nin Teorisi ve Pratiği
(utcc.utoronto.ca)- Statik ve dinamik web siteleri arasındaki farkın bulanıklaştığı görüşünün aksine, uzun işletim zaman ölçeğinde statik dosya tabanlı web siteleri hâlâ farklı özellikler taşır
- Web’in ilk dönemlerinden beri süren dosya yerleştirme yöntemi ve statik dosya sunmanın verimliliği, statik sitelerin uzun süre korunmaya yatkın olmasının nedenidir
- Statik web sitelerinde web sunucusu ile içerik arasında dosya sistemi gibi net bir sorumluluk sınırı bulunur; bu da iki tarafın birbirine dair bilmesi gerekenleri sınırlar
- Dinamik web sitelerinde web sunucusu ile kullanıcı kodu arasındaki sınırın küçük ve basit hâle gelmesi zordur; bu sınırı ve API’yi tek bir yapıda standartlaştırmak da zordur
- Ayrımın ölçütü iş miktarı ya da değişiklik sıklığı değil, sınırın nerede olduğu ve her tarafın neyle ilgilenmek zorunda olduğudur
Statik web sitesi tartışmasının çıkış noktası
- Wesley Aptekar-Cassels’ın There is no such thing as a static website yazısı, statik web siteleri ile dinamik web siteleri arasındaki farkın sanılandan daha küçük olduğunu savunur
- Statik web siteleri göründüğünden daha dinamik ve karmaşıktır
- Dinamik web sitesi geliştirmek ve işletmek eskisine göre daha kolaylaşmıştır
- Tek tek argümanlar ikna edici biçimde kurulsa da, buradan statik ve dinamik web siteleri arasındaki farkın azaldığı sonucuna varılamaz
Dayanıklılık ve sorumluluk sınırlarının yarattığı fark
- Uzun zaman ölçeğinde, statik dosya tabanlı web içeriği yüksek dayanıklılık göstermiştir
- Belirli web sunucuları ve barındırma sağlayıcıları değişse de, statik dosyaları ve dizin ağaçlarına dosya yerleştirme biçimi web’in ilk dönemlerinden beri sürmektedir
- Statik dosya sunma, dinamik web sitelerinde de sıkça gerekli ve verimli olduğundan, yalnızca statik dosyalardan oluşan siteler de aynı avantajlardan yararlanır
- Yalnızca statik içerik sunmak, siteyi işletmesi kolay ve istikrarlı bir hâle getirir; tarihsel olarak bu durum dinamik web siteleri için geçerli olmamıştır
- Statik web sitesinin özü, basit ve güçlü bir yalıtıma sahip sorumluluk sınırıdır
- Bir tarafta HTTPS sertifikası yenileme gibi dinamik güncellemeleri de içeren statik web sunucusunun karmaşıklığı vardır
- Diğer tarafta statik dosyalar bulunur; arada ise dosya sistemi ya da dosya sistemine benzer bir şey yer alır
- İki tarafın birbirinden talep ettiği şeyler son derece sınırlıdır
- Dinamik web sitelerinin web sunucusu ile kullanıcı kodu arasında böyle küçük ve net bir sınıra sahip olması zordur
- Tek bir sınır ve API olarak standartlaştırılma olasılığı da düşüktür
- Web, bir anlamda statik dosyalar sunmak üzere tasarlanmış yönlere sahiptir
- Bu fark, statik dosya web sunucularını işletme ve taşıma açısından dinamik web sunucuları ile çalışma ortamlarına göre avantajlı kılar
- Statik dosya web sunucuları kolay bulunur
- Mevcut işletmeci hizmeti durdursa bile siteyi başka bir yere taşımak kolaydır
- Bu dayanıklılık, en azından tek bir sunucuya sığabilecek küçük ve orta ölçekli statik web siteleri için geçerlidir
- Statik web siteleri ile dinamik web siteleri arasındaki ayrım bulanık değildir
- Bir siteyi oluşturmak ve işletmek için gereken iş miktarı ya da HTTPS sertifikası yenileme gibi düzenli olarak değişen unsurların sayısı ölçüt değildir
- Ölçüt, sınırın nerede olduğu ve her tarafın neyle ilgilenmek zorunda olduğudur
- Statik web siteleri, iki tarafı bağımsız biçimde ele almayı sağlayan keskin bir sınıra sahiptir; dinamik web sitelerinde ise böyle bir sınır doğası gereği yoktur, gerekirse yapay olarak çizilmesi gerekir
1 yorum
Hacker News yorumları
İçerik odaklı bir web sitesinden geçimimi sağlıyorum; bu yıl Craft CMS'ten kendim yaptığım bir statik site oluşturucuya geçtim
Artık sunucu ya da CMS ile uğraşmıyorum, güncelleme gerekmiyor ve ağır veritabanı ile karmaşık önbellekleme yapılandırmalarını da kaldırdım. Şimdi sadece statik dosya sunucusu olduğu için daha kararlı ve neredeyse hiç bakım gerektirmiyor
En iyi yanı ise çevrimdışı çalışabilmek. Sadece bir metin editörü yeterli olduğu için küçük bir Macbook 12" bile çok hızlı hissettiriyor
Sürüm kontrolü de çok faydalı; değişiklikleri inceleyebiliyor ya da geri alabiliyorum ve tüm içerikte regex ile bul/değiştir yapabiliyorum. Metin dosyalarıyla çalışmak kolay
Bu geçişin nasıl hissettirdiğini ve neden iyi çalıştığını burada yazdım: https://nicolasbouliane.com/projects/ursus
Yine de bu teknolojinin, yeniden derleyip dağıtma becerisi olmayan kişiler için de daha erişilebilir olmasını isterim. Hızlı ve ucuz bir web sitesi kurma yöntemi ama Hugo gibi mevcut araçlar kullanıcıdan epey fazla şey varsaydığı için giriş engeli oluşturuyor
Yazıyı da keyifle okudum. Migrasyonda kullanılan html-to-markdown'ın ilk sürümünü ben yapmıştım; hâlâ faydalı şekilde kullanıldığını görmek güzel
Hızlı, gerekli bilgiler iyi derlenmiş ve gereksiz hiçbir şey yok
Kişisel olarak, geçmişteki ve günümüzdeki Berlin'i arka plan alan dizi ve filmler için bir bölüm olmasını isterdim; bir de gerçek Berlin'i ne kadar gerçekçi anlattıklarına dair kısa bir puanlama olsa güzel olurdu
Tüm web sitelerinin %95'inden fazlası için, popüler içeriğin %70'ini RAM'de önbelleğe almak ve kalan %30'u 10.000 IOPS rastgele okuma yapabilen bir SSD'den sunmak büyük olasılıkla fazlasıyla yeterliydi
Site tasarımıyla sürekli oynayıp durmuyorsanız, site ve HTML üretimi yerel cihazda yapılmalı ve tam üretim 1 saniyenin altında sürmeli
Ama GitHub, sürüm kontrolü ve metin editörü merkezli yaklaşım hâlâ teknik insanlara ve programcılara fazla dönük. Barındırmalı WordPress gibi bir şeye ya da eski Dreamweaver/Frontpage dönemine daha yakın bir şeye ihtiyaç var
Özel bir şey yapmak istediğimde en ince ayrıntıya kadar inebilmek hoşuma gidiyor. Örneğin Favorite Git Aliases yazısını düzenlediğimde bunun
.bash_aliasesdosyasına dönüştürülüp GitLab'a push edilmesini ve GitHub'a da mirror edilmesini sağlayabiliyorumMerak edenler için: https://jdsalaro.com. Kullandığım stack'i ya da nedenlerini henüz ayrıntılı yazmadım ama yavaş yavaş dokümante etmeyi planlıyorum
Şimdilik Sphinx için Markdown ve Myst cheat sheet'i (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) ile
environment.pickleyükleme yöntemini (https://jdsalaro.com/howto/sphinx-load-environment-pickle/) yazdımBu aynı zamanda elektrik gibi kaynakların daha az kullanılması, daha küçük donanımın yeterli olması ve en önemlisi güvenliğin iyileşmesi demek. Statik web sitelerine saldırmak daha zordur ve olası kusurlar, web sitesi kodundan ziyade web sunucusuyla sınırlı kalır
Genelde Hugo kullanıyorum; özellikleri çok zengin ve oldukça olgun. Çok dilli web siteleri de yaptım
Statik bir web sitesine Turbo Hotwired entegre etmeyi de düşünebilirsiniz. Gezinme tepkiselliğini artırabilir ve hem sunucu hem istemci tarafındaki yükü azaltabilir
Gerekirse Turbo'yu Mercure ile entegre ederek gerçek zamanlı sayfa akışı da sağlanabilir
Statik site ile dinamik site arasındaki en büyük fark güvenlik saldırı yüzeyi
Statik bir siteyi barındıran web sunucusu, en kötü ihtimalle yanlış dosyayı sunmaya yönlendirilebilir; bu da zaten sunulması güvenli olan dosyaları sunucuya koyarak hafifletilebilir
Dinamik bir site ise kod çalıştırmaya yönlendirilebilir, erişilebilir veritabanından yanlış veri döndürmesi sağlanabilir ve hatta veriyi değiştirmesi bile tetiklenebilir
WordPress ihlalleri sürekli olur ama Nginx ihlalleri öyle değildir
Teknik olarak kod çalıştırmayan bir web sitesi diye bir şey yok. Web sunucusundan dosya sistemi sürücüsüne, işletim sistemine kadar her şey koddur
Statik dosyaların saldırı yüzeyini azalttığı doğru, ama bunun nedenini daha derin düşünmeli ve statik sitenin güvenliğini taşıyan akıllı dinamik sistemler tasarlamalıyız
Sonuçta mesele girdidir ve o girdinin nasıl ele alındığıdır. Ne kadar karmaşık kod çalıştırırsanız çalıştırın, hiç girdi almıyorsa ona saldıramazsınız. Elbette girdi yoksa hangi sayfayı göstereceğini de bilemez, yani statik sitelerde de girdi vardır. Önemli ayrım burada
Statik sitelerin saldırı yüzeyinin daha küçük olduğuna katılıyorum ama asıl büyük nedenin, nginx'in ortalama bir WordPress eklenti kombinasyonuna göre çok daha fazla incelenmesi ve daha yavaş geliştirilmesi olduğunu düşünüyorum
Kendi statik web sunucunuzu yazarsanız, ilk sürümünün varsayılan bir WordPress kurulumundan daha savunmasız olma ihtimali yüksektir
Statik sitelerin ise teorik olarak hiç güncellenmeye ihtiyacı olmayabilir. HTML sürümü gibi hedef değişmedikçe, güncelleme diye bir kavram neredeyse yoktur
aliasyönergesi olanlocationbloğunun sonuna slash koymayı unutursanız bu bir istisnadırGeliştirici açısından bakıldığında, web’in sunduğu soyutlama, yani HTTP/S üzerinde sunulan hipermedya temel alındığında ayrım oldukça temizdir
Bu soyutlamanın anlambilimi, belirli bir yola başlık ve gövde içeren bir isteğin gelmesi ve başlık ile gövde içeren bir yanıtın çıkması yapısıdır. TLS gibi ara ağ ayrıntıları gizlenir
Nitekim modern framework’ler kimlik doğrulama oturumlarını ve istek başlıklarını bile otomatik yöneterek geliştiriciden daha fazlasını gizler. Bu soyutlama içinde “statik, isteğe/duruma bağlı değildir; dinamik ise bağlıdır” şeklindeki standart ayrım nettir, ancak bu ayrım soyutlamanın sunduğu anlambilime dayanır
Bu, TCP’nin özünde paket tabanlı bir alt yapı üzerinde bağlantı odaklı bir protokol olarak çalışmasına benzer. TCP, akış tipi veya paket tipi veri aktarımı gerektiren uygulamalarda kullanılabilir
“Aslında IP’nin üzerinde olduğuna göre bir ayrım yok” diye iddia edilebilir, ancak bu soyutlama katmanına yanlış yerden bakmaktır
Bu, yazının ana fikrinin yanlış olduğu anlamına gelmez. Geliştiriciler, “durumsuz web sitesi”nin altındaki durumsallığı her zaman akılda tutmalı ve gerekli olduğunu düşündüklerinden birkaç katman daha derine inen soyutlamaları anlamaları faydalı olur
Kişisel web sitesi statik ile dinamiğin tuhaf bir karışımı. Büyük kısmı statik, ama blog bölümü dinamik render ediliyor
Blog URL’sine erişildiğinde diskten bir Markdown dosyası alınıp HTML’ye dönüştürülüyor, ardından bu HTML bir şablona yerleştirilerek sayfanın geri kalanı ve CSS vb. oluşturuluyor
Buna rağmen hızlı ve verimli. Geçen hafta blog yazılarımdan biri HN’de 1 numaraya çıktığında bir arkadaşım “Umarım Cloudflare ayarlamışsındır” diye mesaj attı. Ayarlamamıştım ama 2 çekirdekli 1 GB bellekli VPS’in yük ortalaması 0.15’i geçmedi
Mantık şudur: “Çoğu HTML, ama bu dosyada şu satıra gelince kodu çalıştır, başka bir biçimdeki dosyayı ayrıştır ve sonucu çıktının içine ekle”
2001’de her blog yazısına yorum bölümü gibi şeyler eklenmiş statik bir web sitesi yapmak için son derece makuldü. Bu tür PHP yeterince ucuzdu; hatta ISP’ler çoğu zaman bunu
/~userdir/altında barındırmaya ve açık internete sunmaya izin verirdiVeritabanına aşırı derecede bağımlı olmayan makul bir yapıyla küçük bir VPS bile Hacker News trafiğini rahatça kaldırabilir
Threads gibi bir ürün çıkaracaksanız Facebook’un yaptığı türde bir ölçeklendirmeye ihtiyaç duyarsınız, ama sıradan salt okunur bir site için çok para harcamanıza hiç gerek yok
Dinamik içeriği şablona yerleştirmek ya da derleme süresi ile karmaşıklığı azaltmak gibi nedenler aklıma geliyor, ama benim düşünmediğim başka sebepler de olabilir
wasmile biraz uğraşan bir dışarıdan bakan olarak, neden sunucuda kullanıcı kodu çalıştırıp “dinamik” web sayfaları üretmenin basit bir dosya sunucusundan daha iyi olduğunu anlayamıyordum.Dinamik kısımlar tarayıcıda çalışsın, sunucu da sadece dosyaları sunsun diye düşünüyordum. 90’lardaki tarayıcıların bu işlerde berbat olması ise istisna.
Basitlik ve ölçeklenebilirlik açısından CDN önündeki basit bir dosya sunucusunu geçebilecek bir şey yok
Ayrıca varsayılan tarayıcı özelliklerini bozmayan kaç teknoloji olduğu da önemli.
Örneğin GitHub, kaynak kodu gezerken geri düğmesini benim ortamımda hâlâ yaklaşık %40 oranında bozuyor. OSX üzerinde Chrome kullanıyorum; bunu nasıl başardıklarını da bilmiyorum.
Benim deneyimimde, sunucu tarafında HTML üreten siteler, istemci tarafı render’a dayananlardan daha hızlı ve daha güvenilir hissettiriyor. Tarayıcı önbelleği boşken, sayfa başına 50’den fazla görsel olan bir booru açmak; her yeri zaten önbelleğe alınmış ve günlerdir değişmeyen metinden ibaret bir GitHub sayfasını açmaktan her zaman daha hızlı ve daha akıcı geliyor
Örneğin kullanıcı tarafından gönderilen içeriği bir veritabanına kaydetmek isteyebilirsiniz, kimlik doğrulama gerekebilir ya da birkaç GB’lık veri kümesinde tam metin arama sunmanız gerekebilir. Tarayıcının erişemediği şeyler için bir arayüz sağlamak veya kullanıcı girdisini doğrulamak da gerekebilir.
Bunların hepsi sunucuda çalışan kullanıcı kodu gerektirir. Sonra sunucudaki veriyi iyi tanımlanmış bir aktarım protokolüne çevirip istemciye göndermeniz, orada tekrar dönüştürüp HTML’ye çevirmeniz gerekir.
Tersi yönde de durum aynı; kötü niyetli özel istemcileri engellemek istiyorsanız girdiyi hem istemci hem sunucu tarafında doğrulamanız gerekir.
Ya da doğrudan sunucuda HTML üretip işi bitirebilirsiniz. İş yükü çok daha azdır ve çoğu uygulamada pratikte aynı deneyimi sunar
Veritabanı parolası, API anahtarı, şifreleme anahtarı gibi gizli kalması gereken sırlar varsa, bunları sunucudaki kodun işlemesi gerekir. Tüm kod istemcide çalışırsa saldırganın bu sırları bulma ihtimali her zaman vardır.
İstemciye daha küçük ve sınırlı bir API sunmak, saldırı yüzeyini azaltmayı da kolaylaştırır. İstemcinin doğrudan veritabanına bağlanmasına izin verirseniz yetkilerin ve güvenlik ayarlarının kusursuz olması gerekir; ama uygulamanın ele aldığı kitap ya da film listesini sunarsanız savunmayı aşmak çok daha zordur.
İlk yüklemeyi hemen kullanılabilir tek bir veri paketi olarak vermek de çoğu zaman sitenin daha tepkisel hissettirmesini sağlar. Uygulamayı indirip yükleme göstergesi gösterdikten sonra veriyi getirip göstermeyle gerçek süre aynı olsa bile, kullanıcıya ilki daha hızlı gelir.
Sunucu genellikle veritabanının ve gereken diğer sunucuların yanında bulunduğundan, gerekenleri ön tarafta yüklemek daha hızlı olabilir. Bu tür ortamlardaki ağ çağrıları daha kararlıdır. Tüm işlemleri kullanıcı tarafına iterseniz daha yavaş ve daha kararsız çağrılarla uğraşmanız gerekir.
Sunucu, kullanıcının tarayıcısından çok daha tutarlı bir platform olma eğilimindedir. Tarayıcılar iyileşti ama hâlâ pek çok ince fark var. Sunucuda gereken araçları ve runtime sürümlerini tam olarak belirleyebilir ve güncellemeleri daha deterministik biçimde yapabilirsiniz.
Elbette bunlar her zaman tamamen doğru değil ve istisnalar var. Ben çoğunlukla frontend uygulamalarıyla uğraşıyorum ama işin çoğunu ya da tamamını tarayıcıda yapan, iyi tasarlanmış uygulamalarda da büyük değer var. Yalnız bunlar genelde oldukça karmaşık web uygulamaları oluyor ya da zaten tarayıcıda belli ölçüde render gerektiren durumlar oluyor
Üretim yalnızca bir kez yapılıyor ve çok hızlı bitiyor. Ondan sonra kullanıcı açısından statik sayfaların sayısız avantajı aynen geçerli oluyor.
Kaynak kullanımı kat kat daha az ve sayfalar çok daha tepkisel. Kullanıcı deneyimi de çok daha iyi; son 10 yıldır buna pek önem vermedik
rsyncile web sunucusuna yüklediğim bir site işletmiştim. Tüm sayfalar dinamik olarak render ediliyordu.Avantajı, bir kez kurduktan sonra web sitesiyle kelimenin tam anlamıyla bir daha uğraşmamak ve sadece sevdiğim Markdown’ı yazmak olmuştu.
Harikaydı. Web hosting sağlayıcısı PHP’yi kaldırana kadar
Bu yüzden NextJS statik sayfa dışa aktarma özelliğini çok seviyorum.
Derleyip statik
.html,.js,.cssdosyalarını istediğiniz CDN’e ya da statik web sunucusuna dağıtıyorsunuz. Tekil sayfalar ve rotalar derleme sırasında önceden render edildiği için ilk yükleme çok hızlı oluyor ve arama motorları tarafından dizine eklenebiliyor.NextJS’in
.jskodunu parçalara bölüp önceden yükleme biçimi de hızlı yükleme deneyimine katkı sağlıyor. Daha zengin işlevler gerekiyorsa istediğiniz REST API’ye bağlayıp istediğiniz kadar dinamik hale getirebilirsiniz.MDX eklentileriyle aynı proje içinde tamamen statik alanlar veya içerik odaklı siteler de kolayca yapılabiliyor.
Ancak v13 app router geldikten sonra statik dışa aktarma özelliğine yeterince önem verilmediği hissi var. Page router’da olan sığ yönlendirme, statik rewrite/redirect gibi özellikler statik dışa aktarmada yok.
Statik dışa aktarma kullanınca ticari Vercel ürünlerine hiç ihtiyaç kalmadığı için, uzun vadede bu özelliği tamamen kaldırmalarından endişe ediyorum
Çoğunda JavaScript’e bile gerek yok; React, JSX, middleware, sunucu tarafı render gibi şeylere de ihtiyaç yok.
Bu kadar çok hareketli parça ve npm bağımlılığı olan bir şeyi uzun vadede bakımda tutmayı hayal etmek zor. Bunun hiçbir kullanım alanı yok demiyorum ama tek bir landing page yapmak için 1.8 GiB Git checkout ve 828.128 satır kodluk bir projeye dalmadan önce basit düşünmek gerek
Dan Abramov’un örneğine bakabilirsiniz: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343...
Bunun nedeni Vercel’in iş modeli değil; Next.js kullanım oranları içinde bu kullanım senaryosunun daha az yaygın olması.
“Statik rewrite” ile tam olarak ne kastedildiğini bilmiyorum. Bu middleware ile çözülmüyor mu?
90’larda bir noktada “statik site üreticisi” ifadesini duymadan önce sitemi m4 ile üretiyordum
Sonra PHP ve Python’a geçtim, şimdi ise Jekyll kullanarak yeniden statiğe döndüm
Mümkün olduğunda statik yaklaşım çok daha iyi. SSL sertifikaları hariç her şeyi kendi takvimime göre düzeltebiliyorum
PHP yükseltmesi bir şeyi bozarsa bunu hemen düzeltmek zorundasınız; iş bitene kadar da site kapalı kalır
Statik sitede üretici bozulsа bile başarısızlığın sonucu sadece mevcut statik durumun kalmasıdır. Yeni yazı yayımlamanız gerekmiyorsa sorun olmaz
Sunucu çökse bile bir arkadaşınızdan birkaç dosyayı host etmesini istemeniz yeterli olur. “Bunu PHP sürüm X ile ayar Y üzerinde çalıştırıyorsun, değil mi? postgres de var, değil mi?” diye sormanız gerekmez
Bazı arkadaşlar da “Bilgisayarıma PHP kurmak istemiyorum” diyebilir
Karmaşıklık olarak
sed "s/VERSION/1.2.3/g"komutundan bir seviye yukarıda gibi geliyor. Her şeyi harici shell komutlarıyla halledebiliyorsanız Python gibi bir şey kurmanıza da gerek kalmıyorBirkaç yıldır hem statiğin hem de dinamiğin avantajlarını veren bir mimari deseni araştırıyorum
Sunucu tarafında dinamik kod çalıştırabiliyorsunuz, ama ölçekleme maliyeti çok düşük kalıyor ve bir şey bozulsa da kendi kendine toparlanıyor
Buna Baked Data deseni diyorum: https://simonwillison.net/2021/Jul/28/baked-data/
Temel fikir, site verisinin salt okunur tam bir kopyasını uygulamayla birlikte paketlenmiş bir varlık olarak dağıtmak
Tamamen statik sitede olduğu gibi değişiklik olduğunda tüm siteyi yeniden dağıtmanız gerekir; bu yüzden sürekli güncellenen siteler için uygun değildir
Avantajı, bunu Vercel gibi ucuz dinamik scale-to-zero hosting’e dağıtabilmeniz, uygulamanın birden çok kopyasını ayağa kaldırıp her türlü trafiği karşılayabilmeniz ve uygulama ölürse host’un onu otomatik yeniden başlatabilmesidir
Sunucu tarafı arama veya yorum sistemi olan statik siteler gördüm; her yazı ya da yorum ayrı bir düz dosya olarak gönderiliyor, oradan da statik sayfalar otomatik yeniden üretiliyordu
Fark, Markdown dosyaları yerine sqlite içinde saklayıp oradan build etmek mi acaba diye düşünüyorum. Genel backend/sunucu tarafı özellikleri olan statik sitelerle karşılaştırınca göze çarpan anlamlı tek fark bu gibi görünüyor
Derlenmiş ikili çalıştırılabilir dosyalara dosya ya da görsel gibi kodlanmış ikili kaynaklar gömmek eskiden de çok nadir bir şey değildi. Çalıştırılabilir dosyanın boyutunu büyüttüğü için çok fazla eklenmezdi
C veya C++ örneği: https://github.com/graphitemaster/incbin
İlginç olan, programların çalıştırılabilir dosyanın içindeki veriyi değiştirmeyecek şekilde tasarlanmış olmasıydı. Derlenmiş kod makinede çalışıyor ve güvenlik açısından da mantıklı
Ama konteynerleri, mesela docker’ı düşününce, çalışan bir konteyner paketlenmiş bir çalıştırılabilir dosyaya benziyor ama bir dosya sistemi de var
Konteynere veri koyduğunuzda bu, çalıştırılabilir dosyaya gömülü kaynaklara benzer bir fikir; farkı, o verinin değişebilir olması
Yine de konteyner içinde çalışma anında veri değişse bile kalıcı depolama bağlamazsanız bu değişiklikler sürmez
Son zamanlarda neden “çalıştırılabilir dosya ile onun içindeki geçici veri alanı” gibi tek dosyalık bir şey yapılmadığını merak etmeye başladım. Program ile veritabanı benzeri veriler tek bir dosyada birleşebilirdi
Bu, “Baked Data” ile biraz ilişkili bir düşünce. Çalıştırılabilir dosyaya kaynak gömmek sonuçta kodlanmış veriyi onun içine koymak demek
Betik dillerinde base64 ile kodlanmış veriyi doğrudan bir değişkende tutan tek bir betik dosyası oluşturabilirsiniz
Son iki yaklaşım nispeten küçük statik veriler için uygun, ama çalıştırılabilir dosyaların bu kısıtlarını bir şekilde aşan bir teknik geliştirilse ilginç olurdu
Proje sayfamı da böyle host ediyorum: https://usmanity.com/projects
Listeye yeni proje eklerken ya da mevcut öğelerin ayrıntılarını değiştirirken HTML dosyalarını elle düzenlemek istemediğim için Notion kullanıyor, GitHub’a commit etmeden önce veriyi bake ediyorum
Etkinleştirince sitenin tüm sayfalarını bir dizine HTML olarak bake ediyor,
.htaccessdosyasını değiştirip tüm trafiği oraya yönlendiriyordu. İçerik güncellenince hepsini yeniden bake ediyorduhttps://www.drupal.org/project/boost
Statik sitelerde hâlâ büyük ölçüde eksik olan kısmın, düzenleme için kullanılan CMS’in nerede barındırılacağı olduğunu düşünüyorum
Yanlışsam düzeltilmek isterim ama Decap CMS (eski adıyla Netlify CMS) tarayıcıda çalışabiliyor ve GitHub üzerinden okuma/düzenleme yapıp yeniden build ile dağıtımı tetikleyebiliyor. Ancak CORS nedeniyle tarayıcının GitHub API ile doğrudan iletişim kuramadığını, bu yüzden de hâlâ küçük bir sunucuya ya da bir proxy’ye ihtiyaç olduğunu düşünüyorum
Netlify, istekleri proxy’leyen bir GitHub backend’i barındırıyor ama bu durumda Netlify’a ve fiyatlandırma politikasındaki değişimlere bağlı kalıyorsunuz
GitLab ve BitBucket’ta da aynı sorun var gibi görünüyor: https://github.com/isomorphic-git/isomorphic-git#cors-suppor...
Bunu en az kurulumla çözmenin basit bir yolu var mı? Tarayıcı eklentileriyle CORS’u seçici olarak gevşetmek mümkün olabilir ama bu ideal değil
Git tabanlı statik site oluşturucularına Markdown düzenleme ve canlı önizleme sunan, tarayıcıda çalışan, barındırma/sunucu kısıtları az olan bir CMS eklenebilse pek çok küçük web sitesi ve blog için çok uygun olurdu
Statik oluşturucu bu veriyi JSON feed gibi bir şey üzerinden okuyup sayfaları oluşturabilir. Örneğin her ürün kaydında HTML biçiminde bir gövde açıklaması yer alabilir
Böylece başka biri ürün bilgilerini güncellese bile web sitesi yine statik kalır. Airtable’ın buna uygun olacağını sanmıştım ama şaşırtıcı şekilde HTML alanlarını pek iyi desteklemiyordu
Web sitesini istediğiniz şekilde oluşturup FTP ile Surreal’e bağladıktan sonra kullanıcıların ya da müşterilerin yalnızca izin verilen bölümleri düzenlemesini sağlayabiliyorsunuz
Aylık 12 dolar, bu dertten kurtulmak için gayet ucuz ve teknik olmayan kullanıcılara tam bir WYSIWYG düzenleyici sunabiliyorsunuz
[1] https://www.surrealcms.com
Şu anda bu eklenti dizüstü bilgisayarıma yerel olarak kurulmuş VS Code’da çalışıyor ama GitHub Codespaces’te çalışmıyor
Bunu GitHub Codespaces’in ücretsiz kotası içinde, makul kullanım süresi sınırlarıyla çalıştırmak mümkün olursa kazanan bu olur gibi geliyor. Geliştirme ortamını kendi bilgisayarıma kurmak zorunda kalmadan tamamen çevrimiçi ve sürüm kontrollü bir kurulum elde edilir; statik site de S3 gibi bir yerden sunulur ve yine de tam bir CMS deneyimi yaşanır
Statik sitelerin çok önemli bir avantajı, onları çok daha kolay şekilde yayınlayıp unutabilmeniz
S3 bucket site gibi bir yere yüklerseniz neredeyse hiç endişelenmeniz gerekmez
PHP ile ya da daha kötüsü kendi kendine barındırılan WordPress ile “yayınla ve unut” tarzı bir site kurarsanız, birkaç ay kontrol etmezseniz site Rus porno reklamlarıyla dolabilir
Birkaç statik site işletiyorum ve onların sürekli ayakta olduğunu, düzeltme gerektirmediğini bilmek gerçekten çok güzel. Buna karşılık dinamik siteler için, sitenin çöküp çökmediğini kontrol eden uyarılara ihtiyaç var