Teknik temel

Cloudflare üzerinde tanıtım sitesi yayınlamak

Statik dosyalar ile dinamik uygulama istekleri farklı limit ve ücret kurallarına tabidir. Tanıtım sayfaları statik kalırken başvurular ayrı işlenebilir. Makale HTML dosyası olarak sunulurken iletişim formu, doğrulama ve kayıt yapan Worker uç noktasına gönderilebilir. Ücretsiz plana uygunluk koşulludur; sınırsız dinamik işlem veya ücretsiz alan adı yenilemesi vaadi değildir.

Cloudflare üzerinde tanıtım sitesi yayınlamak

Statik yayın ile çalışan uygulama bölümlerini ayırın

Cloudflare üzerinde site yayımlamak tek bir kurulum biçimi demek değildir. Bir tanıtım sitesinin HTML, CSS, görsel ve JavaScript dosyaları statik olarak sunulabilir; başvuru formu gibi sunucu işlemi gerektiren bölüm ise Worker üzerinden çalışabilir. Bu ayrım, her sayfa görüntülemesinin aynı çalışma maliyetine sahip olmadığını anlamayı sağlar. Mimariyi sağlayıcının adından değil, kullanılan bileşenlerden okuyun.

Orvunweb yaklaşımında kamuya açık içerik önceden oluşturulur. Form gönderimi, korumalı başvuru yönetimi ve kök dil seçimi ayrı dinamik işlevlerdir. Blog gövdesi veya her ziyaretçi görüntülemesi için D1 sorgusu çalıştırmak gerekli değildir. D1 yalnız başvuru operasyonu için kullanılır. Bu, küçük bir tanıtım sitesinin veri işleme ihtiyacıyla içerik sunumunu birbirinden ayıran tasarım kararıdır.

Statik dosyaların doğrudan sunulması, bütün istekleri önce Worker'a yönlendirmekten farklıdır. Her görsel ve metin isteğini dinamik koddan geçirmek gereksiz kota kullanabilir. Buna karşılık özel yönetim ve API yolları kimlik doğrulamayı atlamamalıdır. Statik öncelik, güvenlik gerektiren yolların korumasını kaldırmak anlamına gelmez. Static Assets yapılandırması.

Ücretsiz planı koşullarıyla değerlendirin

Ücretsiz barındırma uygun projelerde yararlı bir seçenek olabilir; fakat sınırsız kapasite veya koşulsuz kesintisizlik vaadi değildir. Dinamik istek, CPU süresi, dosya sayısı ve tek dosya boyutu gibi sınırlar bulunabilir. Bu sınırlar zamanla değişebileceğinden yayın gününde resmi plan belgeleri kontrol edilmelidir. Alan adı kayıt ve yenilemesi de barındırmanın ücretsiz olmasından ayrı giderdir.

Workers Free için resmi belgelerde dinamik istek ve CPU sınırları ayrı tanımlanır. İstek sayısı ziyaretçi sayısı değildir; bir kişi birden fazla istek oluşturabilir, botlar da trafik üretir. Ağda yanıt bekleme süresi ile kodun CPU çalışma süresini de aynı ölçü sanmayın. Sitenin plan ihtiyacını gerçek kullanılan bileşenlerle değerlendirin. Workers limitleri.

D1 tarafında okunan ve yazılan satırlar, saklama boyutu ve veritabanı sınırları önemlidir. Filtrelenmeden bütün tabloyu okumak, ekranda az kayıt gösterilse bile gereksiz okuma maliyeti yaratabilir. Küçük başvuru yönetiminde indeks, sınırlı sayfalama ve süreli sayaç temizliği bu yüzden anlamlıdır. Hesaptaki diğer projelerin aynı kota grubunu paylaşabileceğini de hesaba katın. D1 fiyatlandırma.

Yayın sorumluluğunu hesap ve veri akışıyla tamamlayın

Yayına hazır kod ile gerçekten yayımlanmış site ayrı durumlardır. Hesap yetkisi, alan adı doğrulaması, DNS ve gerekli secret'lar tamamlanmadan canlı sonucu varmış gibi sunmayın. Önizleme ortamı varsa gerçek müşteri verisiyle karışmaması ve arama motorlarında istemeden görünmemesi için ayrı yapılandırın. Canlı formun başarısı yalnız ana sayfanın açılmasıyla doğrulanmaz.

Form kullanılan projede tarayıcıdan gelen verinin sunucuda doğrulanması, spam kontrolü ve gerçek kalıcı kayıt gereklidir. Güvenlik servisi veya veritabanı erişilemiyorsa kullanıcıya sahte başarı gösterilmemelidir. Kayıt alındıktan sonra yetkili kişinin onu nasıl göreceği de kurulmalıdır. Başvuruyu görünmeyen bir tabloya bırakmak operasyonu tamamlamaz.

Teslim belgesinde hesap sahibi, yayın komutları, domain bağlantısı, secret isimleri ve temel hata kontrolü yer almalıdır. Secret değerlerini public dosyalara yazmayın. Kota sorunu olduğunda otomatik ücretli ürün açmak yerine durumu görünür hale getirin ve sahibin karar vermesini sağlayın. Doğru Cloudflare kurulumu, sağlayıcı logosundan çok bu sorumlulukların açıkça uygulanmasıyla anlaşılır.

Yayın kontrolünü iki ayrı test olarak yürütün: Önce statik sayfaların gerçek domain üzerinde açıldığını, görsellerin doğru dosya türüyle geldiğini ve bilinmeyen adresin uygun bulunamadı yanıtı verdiğini kontrol edin. Sonra formu ayrı sınayın: güvenlik doğrulaması, sunucu yanıtı, kalıcı kayıt ve yetkili yönetim erişimi birlikte doğrulanmalıdır. Statik sayfaların başarılı olması ikinci grubun çalıştığını kanıtlamaz.

Preview ortamında test yapıyorsanız production başvurularını oraya kopyalamayın. Ayrı veritabanı ve ayrı hostname kullanmak veri karışmasını azaltır. Preview'nun arama motorlarına açık hale gelmemesi için uygun erişim veya noindex düzeni gerekir; yalnız canonical etiketi bunu tek başına çözmez. Production'a geçerken preview kısıtlarının yanlışlıkla taşınmadığı da kontrol edilmelidir.

Operatör notunda başarısızlık davranışını açıkça anlatın. D1 kotası dolduğunda veya güvenlik servisi yanıt vermediğinde kullanıcıya yeniden deneme mesajı gösterilebilir; sahte başarı verilmez. Başvurunun daha önce kaydolduğu tekrar denemelerde ise ikinci kayıt oluşturmayan bir düzen gerekir. Bu küçük görünen ayrıntılar, ücretsiz plan hedefinden bağımsız olarak güvenilir başvuru altyapısının parçasıdır. Cloudflare kurulumu tamamlanmış sayılmadan önce sahibin gerçek hesap ve veri akışına erişebildiği de doğrulanmalıdır. Yetki eksikse kodun hazır olduğunu ve hangi canlı kontrolün yapılamadığını ayrı kaydedin.

Aynı hesapta başka projeler varsa yönetim yetkisini ve kaynak adlarını ayırın. Yalnız ilgili sitenin veritabanı, domaini ve kuralları değiştirilmelidir. Kurulum otomasyonu kolaylık sağlar; bunun başka uygulamaların production verisine veya DNS kayıtlarına müdahale yetkisi verdiğini varsaymayın.

Cloudflare üzerinden yayın yapılması, bütün ürünlerinin projede kullanıldığı anlamına gelmez. Statik dosyalar, dinamik Worker istekleri, D1 veritabanı ve Turnstile farklı işlevlerdir. Kullanım ve sınırlar da bu parçalara göre değişebilir. Proje tesliminde hangi ürünün hangi işi yaptığı açıklanırsa hesap panelindeki rakamlar daha anlamlı hale gelir.

Ücretsiz sınırlar değerlendirilirken sayfa görüntülemeyi bütün tüketimle eşitlemeyin. Statik içerik sunumu ile form kaydının çalıştırdığı dinamik işlem aynı kategoride değildir. Veritabanı okuma ve yazmaları da kullanıcı sayısından farklı biçimde oluşabilir. Bir yönetim ekranının gereksiz sorgularla çalışması, ziyaretçi sayısı düşükken bile tüketimi artırabilir. Bu nedenle gerçek sorgu ve istek tasarımı önemlidir.

Hesap kurulumunda işletme sahipliği korunmalıdır. Alan adı, yayın ve veritabanı kaynakları doğru hesapta olmalı; erişimler ihtiyaç kadar verilmelidir. Yerel ortamda çalışan bir proje, uzaktaki hesapta bütün kaynakların kurulmuş olduğunu göstermez. Canlı yayının doğrulanması için gerçek adres, gerçek bağlar ve yetki yapılandırması kontrol edilir. Erişim veya sahip bilgileri eksikse bunlar teslim notunda açıkça belirtilir. Böylece ücretsiz başlangıç avantajı, olmayan bir canlı kurulum veya sınırsız hizmet vaadiyle karıştırılmaz.

Uygulama kontrolü

  • Güncel plan limitlerini inceleyin
  • Önizleme ve üretimi ayırın
  • Form hatalarını izleyin

Somut örnek: Makale HTML dosyası olarak sunulurken iletişim formu, doğrulama ve kayıt yapan Worker uç noktasına gönderilebilir.

Dikkat edilmesi gereken sınır: Ücretsiz plana uygunluk koşulludur; sınırsız dinamik işlem veya ücretsiz alan adı yenilemesi vaadi değildir.

Sonraki adım

Projenizi Orvunweb’e anlatın

İlgili okumalar

Kaynak