Cloudflare Workers ve BunnyCDN Edge Rules ile Origin Yükünü Edge’e Taşımak

Neden Edge’de Kod Çalıştırmaya İhtiyaç Duyuyoruz?

Son birkaç yılda birçok projede şunu net şekilde gördük: Basit ama her istekte tekrar tekrar çalışan mantıkları web sunucusunda (Nginx/Apache/PHP) koşturmak, hem performans hem de karmaşıklık açısından gereksiz yük oluşturuyor. Özellikle CDN kullandığınız, trafik coğrafi olarak dağıldığı ve TTFB’yi (Time to First Byte) olabildiğince aşağı çekmek istediğiniz senaryolarda, bazı işleri origin’den alıp ağın kenarına, yani edge’e taşımak büyük fark yaratıyor.

Cloudflare Workers ve BunnyCDN Edge Rules tam da bu noktada devreye giriyor. URL rewrite, güvenlik başlıkları, basit yetkilendirme, ülke bazlı yönlendirme, bakım sayfası gösterme gibi işleri edge seviyesinde çözdüğünüzde:

• Origin üzerindeki CPU ve I/O yükü azalıyor, daha fazla trafiği aynı sunucuyla karşılayabiliyorsunuz.
• TTFB ve genel yanıt süreleri kısalıyor.
• Sunucu konfigürasyonunuz sadeleşiyor, Nginx/Apache üzerinde karmaşık kural yığınlarından kurtuluyorsunuz.
• Yapılandırmalarınız daha taşınabilir hale geliyor; hosting veya sunucu değiştirirken daha az kırılganlık yaşıyorsunuz.

Bu yazıda DCHost ekibi olarak, Cloudflare Workers ve BunnyCDN Edge Rules kullanarak URL rewrite, güvenlik başlıkları ve basit iş mantığını origin’den edge’e nasıl taşıyabileceğinizi adım adım ele alacağız. Ayrıca edge kurallarını CDN önbellekleme, SEO ve güvenlik politikaları ile nasıl uyumlu çalıştırmanız gerektiğini de pratik örneklerle anlatacağız.

Cloudflare Workers ve BunnyCDN Edge Rules Temel Farkları

Önce iki yapının ne olduğunu netleştirelim; çünkü mimariyi doğru kurmak için hangi iş yükünü nereye koymanız gerektiğini iyi bilmeniz gerekiyor.

Cloudflare Workers: Edge’de Gerçek Kod Çalıştırma

Cloudflare Workers, Cloudflare POP noktalarında çalışan, V8 tabanlı izolasyonlar içinde JavaScript (veya TypeScript/derlenmiş JS) koşturabildiğiniz bir edge compute ortamı. Basitçe özetlersek:

• Tam programlama gücü: Koşullu mantık, döngüler, harici API çağrıları, regex tabanlı routing, A/B test, hatta küçük API uçları bile yazabilirsiniz.
• Request/response üzerinde tam kontrol: Gelen isteği yakalar, URL’yi değiştirir, headere dokunur, gerekirse hiç origin’e gitmeden yanıt üretebilirsiniz.
• Dağıtık çalışır: Kodunuz, ziyaretçiye en yakın edge noktasında koşturulur; bu da özellikle global trafiği olan sitelerde hissedilir hız kazancı sağlar.

DCHost tarafında özellikle SPF kayıtlarını yönetmek, dinamik yönlendirme ve güvenlik başlıklarını merkezi bir yerde tutmak için Cloudflare Workers’ı sıkça kullanıyoruz. Örneğin SPF flattening için Cloudflare Workers kullandığımız yazıda benzer bir yaklaşımı ayrıntılı olarak anlattık.

BunnyCDN Edge Rules: Koşul + Aksiyon Motoru

BunnyCDN Edge Rules ise JavaScript çalıştırmıyor; onun yerine “şu koşul sağlanıyorsa bu aksiyonu uygula” mantığında bir kural motoru sunuyor. Örnek aksiyonlar:

• URL rewrite veya redirect
• Response header ekleme/değiştirme
• Cache davranışını değiştirme (no cache, farklı TTL, cache-key değiştirme vb.)
• Belirli ülkelerden gelen isteklere farklı davranmak
• Belirli user-agent’ları engellemek veya farklı yanıt döndürmek

Yani BunnyCDN Edge Rules, Nginx’teki “if + rewrite + add_header” kombinasyonuna benziyor; ama bunu global edge katmanında, görsel bir arayüzle yönetmenizi sağlıyor. Karmaşık iş mantığı değil, basit ve tekrarlayan operasyonel kurallar için ideal.

Origin’den Edge’e Taşınabilecek İşler

Her şeyi edge’e taşımak doğru değil; ama bazı kalıplar neredeyse her projede tekrar ediyor ve bunlar edge için biçilmiş kaftan:

1. URL Rewrite ve Routing

• Eski URL şemasından yeni yapıya geçerken 301/302 yönlendirmeler
• Single Page Application (SPA) için tüm yolları /index.html veya /app.html’e düşürmek
• Backend framework’ünüzün (Laravel, Symfony, Ruby vb.) URL yapısını sade göstermek için /urun/slug → /index.php?route=product&slug=slug gibi dönüşümler
• Coğrafi veya dil bazlı yönlendirme (tr.example.com, en.example.com vb.)

Bu kurallar klasik olarak Nginx/Apache config içinde tutulur. Ancak CDN ile çalışırken, bu rewrite’ları edge’de yapmak çoğu zaman daha mantıklıdır.

2. Güvenlik Başlıkları

Önemli HTTP güvenlik başlıklarının büyük kısmı, uygulama kodunuzdan bağımsızdır ve tamamen “policy” niteliğindedir:

• Strict-Transport-Security (HSTS)
• Content-Security-Policy (CSP)
• X-Frame-Options
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

Bunları her sunucuda ayrı ayrı konfigüre etmek yerine, edge seviyesinde standartlaştırmak çoğu zaman daha sağlıklıdır. Detayları bizim HTTP güvenlik başlıkları rehberimizde uzun uzun anlattık; burada özellikle Workers ve Edge Rules üzerinden pratik örneklere odaklanacağız.

3. Basit Koşullu Mantık

Aşağıdaki gibi işler için tam teşekküllü backend koduna ihtiyacınız yok:

• Belirli ülkelerden gelen trafiği farklı bir alan adına yönlendirmek
• Bakım modundaysanız tüm isteklere statik bir bakım sayfası döndürmek
• Basit bir IP kara listesi uygulamak
• A/B testinde trafiğin %10’unu yeni sayfa tasarımına göndermek

Bu tarz mantıklar, ya tamamen Workers ile kod seviyesinde çözülebilir ya da yeterince basitse BunnyCDN Edge Rules ile koşul/aksiyon olarak tanımlanabilir.

Cloudflare Workers ile URL Rewrite ve Güvenlik Başlıkları

Cloudflare Workers tarafında temel yapı şu şekilde ilerler:

1. Bir Worker oluşturursunuz.
2. İlgili domain ve path için bir Route tanımlarsınız (örneğin example.com/*).
3. Worker kodu, bu route’a gelen her isteği dinler, gerekirse isteği değiştirir, origin’e veya başka bir hedefe iletir, yanıtı alır ve son kullanıcıya döner.

Workers ile Basit URL Rewrite Örneği

Basit bir senaryo üzerinden gidelim: /blog/* isteklerini origin’de /index.php?route=blog&slug=… şeklinde çalışan bir PHP uygulamasına yönlendirmek istiyorsunuz; ama URL’lerinizin temiz ve SEO dostu görünmesini istiyorsunuz.

addEventListener('fetch', event => {  event.respondWith(handleRequest(event.request));});async function handleRequest(request) {  const url = new URL(request.url);  // /blog/slug yapısını /index.php?route=blog&slug=slug şekline çevir  if (url.pathname.startsWith('/blog/')) {    const slug = url.pathname.replace('/blog/', '').replace(//$/, '');    url.pathname = '/index.php';    url.searchParams.set('route', 'blog');    url.searchParams.set('slug', slug);  }  const newRequest = new Request(url.toString(), request);  const response = await fetch(newRequest);  return response;}

Bu sayede:

• Kullanıcı tarafında temiz URL’ler (/blog/yeni-urunler) kalır.
• Origin üzerinde ekstra rewrite kuralı yazmanız gerekmez.
• Gelecekte origin platformunuzu değiştirdiğinizde, sadece Worker’daki mapping’i güncellemeniz yeterli olur.

Workers ile Güvenlik Başlıkları Ekleme

Aynı Worker içinde, origin’den gelen response üzerine güvenlik başlıklarını da ekleyebilirsiniz. Örneğin:

async function handleRequest(request) {  const url = new URL(request.url);  // ... URL rewrite mantığınız burada olabilir ...  const response = await fetch(url.toString(), request);  const newHeaders = new Headers(response.headers);  newHeaders.set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');  newHeaders.set('X-Frame-Options', 'DENY');  newHeaders.set('X-Content-Type-Options', 'nosniff');  newHeaders.set('Referrer-Policy', 'strict-origin-when-cross-origin');  // Örnek, sade bir CSP  newHeaders.set('Content-Security-Policy', "default-src 'self'; img-src 'self' https: data:; script-src 'self'; style-src 'self' 'unsafe-inline';");  return new Response(response.body, {    status: response.status,    statusText: response.statusText,    headers: newHeaders  });}

Bu yaklaşımın en güzel tarafı, HTTP güvenlik politikalarınızı uygulama kodundan tamamen bağımsız hale getirmeniz. Framework değiştirseniz bile, Workers tarafında birkaç satırlık güncelleme ile tüm site politikanızı değiştirebiliyorsunuz.

Workers ile Basit Koşullu Mantık (Ülke Bazlı Yönlendirme)

Cloudflare, isteğin geldiği ülkeyi CF-IPCountry header’ı ile Worker’a iletir. Bunu kullanarak örneğin Türkiye’den gelen kullanıcıları tr.example.com’a yönlendirebilirsiniz:

async function handleRequest(request) {  const country = request.headers.get('CF-IPCountry');  const url = new URL(request.url);  if (country === 'TR' && url.hostname === 'www.example.com') {    const target = 'https://tr.example.com' + url.pathname + url.search;    return Response.redirect(target, 302);  }  return fetch(request);}

Bu örnekler, Workers ile neler yapabileceğinizin sadece küçük bir kısmı. Ama pratikte gördüğümüz şu: URL rewrite + güvenlik başlıkları + birkaç koşullu mantık bile, origin konfigürasyonunuzu ciddi şekilde sadeleştiriyor.

BunnyCDN Edge Rules ile URL Rewrite ve Güvenlik Başlıkları

Cloudflare Workers kadar esnek bir programlama ortamı sunmasa da, BunnyCDN Edge Rules birçok senaryo için fazlasıyla yeterli. Özellikle “koşul + aksiyon” şeklinde ifade edilebilen işleri, hiç kod yazmadan edge’e taşıyabiliyorsunuz.

BunnyCDN Edge Rules ile URL Rewrite Örneği

Diyelim ki WordPress siteniz var ve /eski-blog/* URL’lerini /blog/* altına kalıcı yönlendirmek istiyorsunuz. Bunu Nginx üzerinde 301 redirect ile çözmek yerine, BunnyCDN Edge Rules ile şöyle yapabilirsiniz:

1. BunnyCDN panelinde ilgili Pull Zone’a girin.
2. Edge Rules bölümünden yeni bir kural oluşturun.
3. Koşul (Condition) olarak: URL Path starts with /eski-blog/ seçin.
4. Aksiyon (Action) olarak: Redirect (301) + hedef URL olarak /blog/%path% kurgulayın.

Daha gelişmiş bir senaryoda, rewrite aksiyonu kullanarak istek origin’e gitmeden URL’yi /index.php?route=… formuna dönüştürebilirsiniz. Böylece Nginx/Apache konfigürasyonunuz neredeyse sadece statik dosya ve PHP FPM proxy ayarlarından ibaret kalır.

BunnyCDN ile Güvenlik Başlığı Ekleme

Edge Rules’un en pratik kullanım alanlarından biri, response header eklemek/değiştirmek. Örneğin tüm HTML yanıtlarına aşağıdaki güvenlik başlıklarını eklemek isteyin:

• Strict-Transport-Security
• X-Frame-Options
• Referrer-Policy

Bunun için:

1. Tek bir Edge Rule oluşturun.
2. Condition: Response Content-Type contains text/html.
3. Action: Set Response Header ile aşağıdaki başlıkları tanımlayın:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadX-Frame-Options: DENYReferrer-Policy: strict-origin-when-cross-origin

CSP gibi daha kompleks başlıklar için de aynı yaklaşım geçerli; ancak policy’yi dikkatli tasarlamanız gerekiyor. Bunun için öncesinde HTTP güvenlik başlıkları rehberindeki CSP bölümünü okumanızı öneririz.

Edge Rules ile Cache Davranışını Ayarlamak

Edge kurallarını doğru cache politikası ile birlikte kullanmak en az URL rewrite kadar kritik. Örneğin:

• /api/* isteklerini asla cache’lememek
• /assets/* altında agresif cache (1 ay) kullanmak
• /blog/* için daha kısa TTL (örneğin 10 dakika) verip stale-while-revalidate benzeri davranış elde etmek

BunnyCDN’de Edge Rules ile path bazlı cache TTL belirleyebilir, hatta bazı header’ları (örneğin Authorization) görmezden gelerek cache oranını artırabilirsiniz. Biz bu tip optimizasyonların mantığını CDN önbellekleme ve edge kuralları rehberimizde etraflıca anlattık; burada sadece Workers/Edge Rules ile nasıl birleştiğini vurguluyoruz.

Edge Kurallarını SEO ve CDN Önbellekleme ile Uyumlu Kullanmak

URL rewrite ve güvenlik başlıklarını edge’e taşıdığınızda, SEO ve cache davranışı açısından dikkat etmeniz gereken birkaç kritik nokta var.

301/302 Yönlendirme Kuralları

Eski URL’den yeni URL’ye kalıcı geçiş yapıyorsanız:

• Mümkünse 301 (permanent redirect) kullanın.
• Yönlendirme zinciri oluşturmamaya çalışın (eski → ara → yeni yerine direkt eski → yeni).
• Hem Cloudflare Workers hem BunnyCDN Edge Rules tarafında aynı yönlendirmeyi tekrarlamayın; aksi halde redirect loop oluşabilir.

Örneğin dil yönlendirmesi yapıyorsanız, tarayıcı diline göre otomatik redirect yerine, genellikle ilk ziyarette banner veya kullanıcıya seçenek sunmak daha sağlıklı. Aksi halde arama motoru botları yanlış varyanta kilitlenebilir.

Canonical ve İç Linkler

Edge’de yaptığınız rewrite, uygulama tarafındaki URL mantığıyla çelişmemeli. Örneğin:

• Kullanıcı /blog/yazi-1 görüyor, ama uygulama canonical’ı /index.php?route=blog&id=1 olarak set ediyorsa SEO tarafında karışıklık çıkar.
• Edge’de /eski-urun → /urun/yeni-urun redirect yaparken, sayfa içinde hala /eski-urun linklerini kullanıyorsanız, botlar her taramada ekstra yönlendirme yaşar.

Bu nedenle, edge kurallarını uygularken uygulama tarafındaki canonical, sitemap ve iç link yapısını da güncellemek şart.

stale-while-revalidate ile Birlikte Kullanım

Cloudflare ve bazı CDN’ler, Cache-Control direktifleri içinde stale-while-revalidate ve stale-if-error gibi özellikleri destekliyor. Biz bu konuyu stale-while-revalidate direktiflerini anlattığımız yazıda detaylandırmıştık.

Önemli nokta şu: URL rewrite’ı edge’de yaptığınızda, cache key ve varyant mantığınızı da buna göre kurgulamanız gerekiyor. Örneğin Workers ile /blog/slug → /index.php?route=blog&slug=slug dönüşümünü yapıyorsanız, CDN tarafında cache key’i kullanıcının gördüğü URL’ye göre ayarlamak genellikle daha mantıklı. Aksi halde cache’iniz teknik query string’e göre dağılır, hit oranınız düşer.

DCHost Origin Altyapısı ile Örnek Mimari

Edge’de ne kadar çok işi çözerseniz çözün, güçlü ve sağlıklı bir origin altyapısına ihtiyacınız var. DCHost tarafında tipik olarak şu mimariyi öneriyoruz:

• Origin olarak DCHost VPS veya dedicated sunucu: Uygulama (PHP/Laravel, WordPress, Node.js vb.) burada çalışıyor.
• Ön tarafta Cloudflare veya BunnyCDN: Tüm statik içerik ve büyük ölçüde HTML yanıtları cache’leniyor.
• Edge’de Workers / Edge Rules: URL rewrite, güvenlik başlıkları, basit mantık, ülke bazlı yönlendirme gibi işler burada çözülüyor.

Global trafiği olan projelerde ise bunu bir adım ileri taşıyıp çok bölgeli mimariler kurmak mümkün. Örneğin trafiğinizi Avrupa ve Amerika’daki iki farklı DCHost origin kümesine dağıtıp, DNS veya CDN üzerinden coğrafi yönlendirme yapabilirsiniz. Bu yaklaşımı GeoDNS ve çok bölgeli hosting mimarisi yazımızda detaylandırdık.

Edge’de kuralları doğru tasarladığınızda, yeni bir DCHost VPS’e geçiş, ölçek büyütme veya veritabanını ayrı sunucuya taşıma gibi operasyonlar çok daha az riskle yapılabiliyor. Çünkü yönlendirme ve güvenlik politikalarınızın büyük kısmı artık origin konfigürasyonuna değil, edge katmanına bağlı.

Gerçek Dünya Senaryoları: Hangi İşi Nereye Koymalı?

Sahada en sık karşılaştığımız senaryolar üzerinden hangi işi Workers’a, hangisini Edge Rules’a, hangisini origin’e bırakmanız gerektiğini özetleyelim.

1. WordPress + WooCommerce Sitesi

• Origin (DCHost VPS): WordPress, WooCommerce, PHP-FPM, MySQL/MariaDB.
• Cloudflare/BunnyCDN: Statik dosyalar, mümkünse çoğu HTML için cache.
• Edge kuralları:

• WooCommerce sepet/ödemeyi cache dışı bırakacak path bazlı kurallar
• /wp-admin, /wp-login.php gibi yollara IP/ülke bazlı erişim kısıtlaması
• Güvenlik başlıkları (HSTS, X-Frame-Options, Referrer-Policy vb.)
• /eski-blog/* → /blog/* yönlendirmeleri

Böyle bir yapıda, hem performans hem de güvenlik kazanıyorsunuz. WordPress tarafındaki server-side ayarların detaylarını WordPress için sunucu tarafı optimizasyon rehberimizde ayrıca anlattık; edge kuralları bu optimizasyonları tamamlayan katman gibi düşünebilirsiniz.

2. Laravel / Özel PHP Uygulaması

• Origin: Tüm routing Laravel üzerinde.
• Workers:

• Bakım modunda tüm trafiği statik bakım sayfasına çevirmek
• Webhook’lar için IP beyaz liste/karaliste uygulamak
• Basit bir rate limiting (daha gelişmiş senaryolar için Nginx/Redis tabanlı çözümler daha uygun olabilir)

API ve mikroservisler için daha ince ayarlı trafik kontrolü gerektiğinde, edge katmanını Nginx/Redis temelli oran sınırlama ile birleştirmek mantıklı. Bunu da API ve mikroservisler için rate limiting stratejileri yazımızda detaylandırdık.

3. Statik veya Jamstack Site

Statik HTML/Jamstack projelerde aslında origin neredeyse “build artifact deposu” haline geliyor.

• Origin: Sadece dosya sunumu.
• Edge kuralları:

• Coğrafi yönlendirme (tr.example.com, en.example.com gibi)
• Güvenlik başlıklarının tamamı
• Özel hata sayfaları (404, 500) için rewrite

Bu tür yapılarda edge mantığını iyi kurguladığınızda, origin kapasite gereksinimi çok düşük kalıyor; küçük bir DCHost VPS bile oldukça yüksek trafiği kaldırabiliyor.

Pratik İpuçları ve Sık Yapılan Hatalar

1. Aynı Kuralı Birden Fazla Katmanda Tekrarlamayın

En sık gördüğümüz hata: Aynı redirect veya header, hem origin konfigürasyonunda hem Cloudflare Page Rules/Workers’da hem de BunnyCDN Edge Rules’ta tanımlanmış oluyor. Sonuç:

• Redirect loop’lar
• İki farklı CSP’nin üst üste binmesi ve beklenmedik JS hataları
• HSTS’nin iki farklı yerde farklı değerlerle set edilmesi

Önerimiz: URL rewrite ve güvenlik başlıkları için tek bir katmanı “kaynak gerçek” olarak seçin. Eğer Workers veya Edge Rules kullanıyorsanız, mümkün olduğunca Nginx/Apache içindeki benzer kuralları sadeleştirin.

2. Loglama ve Debug Mekanizması Kurun

Edge’de olanı görmek her zaman kolay değil. Cloudflare Workers tarafında console.log çıktısını Workers dashboard’dan görebilirsiniz; ama üretim ortamında daha sistematik yaklaşmak iyi olur. Örneğin:

• Önemli olayları (örneğin bloklanan IP, belirli bir redirect kuralına giren istekler) küçük bir log endpoint’ine POST etmek
• Hata oranlarını izlemek için basit metrikler üretmek

DCHost üzerinde kuracağınız merkezi log altyapısı (örneğin Loki/Promtail) ile edge kaynaklı logları da bir araya getirip, uçtan uca görünürlük elde edebilirsiniz.

3. Küçükten Başlayın, Kapsamı Yavaş Genişletin

Onlarca kuralı bir gecede edge’e taşımaya çalışmak, üretim ortamında sürprizlere yol açıyor. Bizim pratikte izlediğimiz yol genelde şu:

1. Önce sadece güvenlik başlıklarını edge’e taşıyın.
2. Sonra nispeten risksiz redirect’lerle devam edin (/eski-url → /yeni-url gibi).
3. En son uygulama davranışını etkileyen rewrite ve bakım modu gibi kuralları taşıyın.

Her adımda, HTTP status kodlarını ve response header’larını dikkatlice izleyerek ilerlemek, canlı sitede sorun çıkma riskini ciddi şekilde azaltıyor.

4. Versiyonlama ve Ortam Ayrımı Yapın

Özellikle Cloudflare Workers tarafında, staging ve prod için ayrı Workers ve ayrı Route’lar kullanmak çok faydalı. Staging ortamınız için ayrı bir subdomain (örneğin staging.example.com) ve buna özel edge kuralları tanımlayarak, değişiklikleri gerçek trafik almadan önce test edebilirsiniz. Bu yaklaşımı genel olarak yayın süreçleri için geliştirme–staging–canlı yolculuğu rehberimizde detaylandırmıştık; edge kuralları da bu akışın bir parçası olmalı.

Sonuç: Edge’i Doğru Kullanan Origin Rahat Uyur

Cloudflare Workers ve BunnyCDN Edge Rules, doğru kullanıldığında sadece birkaç milisaniyelik hız kazancı değil, aynı zamanda mimari sadelik ve operasyonel esneklik getiriyor. URL rewrite, güvenlik başlıkları ve basit mantığı origin’den edge’e taşıdığınızda:

• Sunucu tarafı konfigürasyonunuz sadeleşiyor.
• Hosting veya altyapı değişikliklerinde kırılgan noktalar azalıyor.
• TTFB ve genel yanıt süresi iyileşiyor; özellikle global ziyaretçiler bunu hissediyor.
• Güvenlik politikalarınızı merkezi ve tutarlı şekilde yönetebiliyorsunuz.

DCHost olarak bizim önerimiz, edge’i “sihirli kutu” gibi görmek yerine, bilinçli bir katman olarak ele almanız. Hangi kural neden edge’de, neden origin’de, neden uygulama kodunda sorusuna net cevaplarınız olduğunda; ölçek büyütmek, yeni özellikler eklemek ve güvenlik politikalarını güncellemek çok daha kolay hale geliyor.

Eğer altyapınızda Cloudflare veya BunnyCDN kullanıyor ve “şu karmaşık Nginx kurallarını nasıl sadeleştiririm, şu güvenlik başlıklarını tek yerden nasıl yönetirim, bu basit yönlendirmeleri nasıl origin’den kurtarırım” diye düşünüyorsanız, DCHost ekibiyle iletişime geçebilirsiniz. Projenizin gereksinimlerine göre uygun DCHost VPS veya dedicated sunucu altyapısını, edge tarafında doğru kurgulanmış Workers/Edge Rules katmanıyla birlikte tasarlayıp, üretim ortamına adım adım ve güvenli şekilde taşımanıza yardımcı olabiliriz.