<![CDATA[sph.sh Blog]]> https://sph.sh/tr RSS for Node Sun, 27 Sep 2026 22:23:05 GMT Sun, 27 Sep 2026 22:23:05 GMT 60 <![CDATA[Yazılımda Chesterton Çiti: Önce Neden Diye Sor, Sonra Sil]]> https://sph.sh/tr/posts/chestertons-fence-in-software/ https://sph.sh/tr/posts/chestertons-fence-in-software/ Sun, 27 Sep 2026 00:00:00 GMT Chesterton Çiti, açıklanamayan kodu yerinde bırakmanın gerekçesi olarak anılır; oysa Chesterton'ın kendi metni, amaç anlaşıldığında çitin kaldırılmasına izin verir. Bu yüzden her çiti iki yarısı olan, zaman sınırlı bir hata ayıklama sorusu olarak ele alın: neden kuruldu ve bugün kim ona bağımlı. Bütçe bitince, değişiklik geri alınabilir ve bağımlılar gözlemlenebilir olduğu sürece, varsayılan olarak kademeli kaldırmaya geçin. Çit kalsın ya da gitsin, cevabı yorum, commit gövdesi, ADR ya da flag metadata'sı olarak geride bırakın.

Continue reading...

]]> <![CDATA[İletişim, Bir Sonraki Mühendislik Seviyenizin Kapısıdır]]> https://sph.sh/tr/posts/communication-skill-gate-next-engineering-level/ https://sph.sh/tr/posts/communication-skill-gate-next-engineering-level/ Sat, 05 Sep 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[Passkey Artık Default: Asıl İş Login Değil, Recovery]]> https://sph.sh/tr/posts/passkeys-by-default-recovery/ https://sph.sh/tr/posts/passkeys-by-default-recovery/ Mon, 31 Aug 2026 00:00:00 GMT Passkey, gelişmiş seçenek olmaktan çıkıp varsayılan giriş yöntemi haline geldi. Amazon Cognito managed login içinde passkey ile girişi Kasım 2024'ten beri sunuyor. Microsoft Entra ID Eylül 2026'da passkey'i varsayılan olarak açmaya başlıyor; arkalarındaki WebAuthn spesifikasyonu da Ağustos 2026'da Level 3 ile W3C Recommendation statüsüne ulaştı. E-posta, şifre ve SMS OTP ile çalışan bir login akışının sahibiyseniz geçişin küçük yarısı giriş tarafı: bir feature plan kararı, tek bir yapılandırma bloğu ve birkaç API çağrısı. Büyük yarı, passkey ortada olmadığında ne olacağı; çünkü giriş sertleştikçe saldırı trafiği hesap kurtarmaya, yani recovery tarafına kayıyor. Önce Cognito kurulumu, sonra asıl ağırlığı hak eden kısım: SMS'in yerini alan recovery merdiveni.

Continue reading...

]]> <![CDATA[Ajan Planınız Tasarım Dokümanınızdan Uzun Olmalı]]> https://sph.sh/tr/posts/writing-plans-for-coding-agents/ https://sph.sh/tr/posts/writing-plans-for-coding-agents/ Mon, 31 Aug 2026 00:00:00 GMT Geliştirdiğim bir filo ve lojistik platformunun kod deposunda ajana dönük dokümanlar iki dizine ayrılıyor: docs/superpowers/specs/ tasarım dokümanlarını, docs/superpowers/plans/ uygulama planlarını tutuyor. İkisi de yönettiğim Claude Code oturumlarından çıkıyor: önce spec'i onaylıyorum, plan ardından o spec'e göre yazılıyor. İki dizini wc -l ile saydım: 36 spec toplam 6.765 satır, ortalama yaklaşık 188; 45 plan toplam 38.639 satır, ortalama yaklaşık 859. Yürütülebilir plan, uyguladığı tasarımdan dört ila beş kat uzun.

| Doküman türü | Adet | Toplam satır | Ortalama | |---|---|---|---| | Tasarım spec'i (docs/superpowers/specs/) | 36 | 6.765 | ~188 | | Uygulama planı (docs/superpowers/plans/) | 45 | 38.639 | ~859 |

Continue reading...

]]> <![CDATA[Yapay Zeka Kodu Ucuzlattı, İncelemeyi Pahalılaştırdı]]> https://sph.sh/tr/posts/ai-assisted-coding-burnout-review-load/ https://sph.sh/tr/posts/ai-assisted-coding-burnout-review-load/ Wed, 26 Aug 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[Kimlik Okumaları DynamoDB'de, Arama OpenSearch'te: Zero-ETL Okuma Modeli]]> https://sph.sh/tr/posts/dynamodb-kv-mindset-opensearch-read-model/ https://sph.sh/tr/posts/dynamodb-kv-mindset-opensearch-read-model/ Sun, 23 Aug 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[DynamoDB Sayfalama: İmzalı Cursor, Sıralama ve Toplam Sayı Problemi]]> https://sph.sh/tr/posts/dynamodb-pagination-sorting-cursor/ https://sph.sh/tr/posts/dynamodb-pagination-sorting-cursor/ Sun, 23 Aug 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[Kod Ajanlarında Kalite: Model Kademesi mi, Harness mi?]]> https://sph.sh/tr/posts/agentic-coding-model-tier-vs-harness/ https://sph.sh/tr/posts/agentic-coding-model-tier-vs-harness/ Sun, 16 Aug 2026 00:00:00 GMT Kod ajanı kötü bir diff ürettiğinde standart çözüm tek satırlık bir konfigürasyon: daha güçlü modele geçmek. Model ile harness'i ayrı sütunlar olarak yayımlayan benchmark tabloları bu refleksi zora sokuyor. Yetenekleri birbirine yakın modeller arasında harness'i değiştirmek skoru en az modeli değiştirmek kadar oynatıyor; modelin üstünlüğü ancak görevler uzadıkça yeniden öne çıkıyor. Bu yüzden benim varsayılanım yaygın refleksin tersi: kapalı bir doğrulama döngüsüne ve sıkı bir bağlam bütçesine sahip bir harness içinde orta kademe bir model; kademe yükseltmenin tetiği ise görevin ufku, görevin önemi değil.

Continue reading...

]]> <![CDATA[Dogwood: AI Ajanları için Zamansal Yetkilendirme]]> https://sph.sh/tr/posts/dogwood-temporal-policy-language/ https://sph.sh/tr/posts/dogwood-temporal-policy-language/ Fri, 07 Aug 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[Claude Code Nerede Çalışmalı? Devcontainer, Codespaces ve MicroVM]]> https://sph.sh/tr/posts/claude-code-lambda-microvm-dev-sandboxes/ https://sph.sh/tr/posts/claude-code-lambda-microvm-dev-sandboxes/ Tue, 04 Aug 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[Prisma vs Drizzle vs Kysely: TypeScript Veri Katmanı Seçimi]]> https://sph.sh/tr/posts/prisma-vs-drizzle-vs-kysely/ https://sph.sh/tr/posts/prisma-vs-drizzle-vs-kysely/ Mon, 03 Aug 2026 00:00:00 GMT Postgres üzerinde kurulan her yeni TypeScript servisi, geri dönüşü pahalı olan tek bir kararı dayatır: SQL'in ne kadarını bir kütüphaneye devrediyorsunuz? Prisma, Drizzle ve Kysely bu soruya farklı cevap verir ve fark bir özellik listesi değildir. Fark, tiplerin nereden geldiği ve sorguyu kimin yazdığıdır. Lambda üzerinde çalışan, Postgres tabanlı yeni bir servis için varsayılan Drizzle. Şemanın ve migration'ların sahipliğini üstlenir, ama sorgunun şeklini yine de kod içinde görünür bırakır. Bu varsayılanı geçersiz kılan iki koşul var. Prisma'ya yöneltilen ve karşılaştırmaların çoğunda hâlâ tekrarlanan serverless itirazı da geçerliliğini yitirdi; yerine geçen daha dar itirazı fark etmek ise çok daha zor.

Continue reading...

]]> <![CDATA[Hızlanmak İçin Yavaşla]]> https://sph.sh/tr/posts/slow-down-to-speed-up-sustainable-engineering-pace/ https://sph.sh/tr/posts/slow-down-to-speed-up-sustainable-engineering-pace/ Thu, 23 Jul 2026 00:00:00 GMT Bir tarihi tutturmak için temizliği atlamak o an hızlı hissettirir ve tek bir sprint boyunca çoğu zaman gerçekten öyledir. Sorun şu: testi, küçük refactor'ü ya da kararsız pipeline düzeltmesini atlamak o işi silmez. İşi faizle erteler ve faiz size hatalar, yeniden iş ve yangın söndürmeye giden zaman olarak geri döner. Sezgisel okuma şudur: bakım, gönderime harcanmayan zamandır, o halde sizi yavaşlatmalıdır. Teslimat performansı üzerine yapılan araştırma tam tersini gösteriyor: kodunu ve pipeline'ını temiz tutan ekipler daha sık gönderim yapar. Buradaki öneri şu: varsayılan olarak istikrarlı, bakımı içine alan bir tempoyu seçin ve teknik borcu bir kaza olarak değil, bilinçli ve takvime bağlı bir karar olarak ele alın.

Continue reading...

]]> <![CDATA[Bu Kodun Sahibi Kim: Hesap Verebilirlik ve Suçlama]]> https://sph.sh/tr/posts/code-ownership-accountability-vs-blame/ https://sph.sh/tr/posts/code-ownership-accountability-vs-blame/ Tue, 21 Jul 2026 00:00:00 GMT "Bunu her kim yazdıysa aptalın tekiymiş" cümlesi yazılımda en sık kurulan, ama en işe yaramaz cümlelerden biridir. Analiz gibi görünür; oysa önemi olmayan bir soruyu yanıtlar. Bir dosyayı açıp tek bir satırı değiştirdiğiniz an, orijinal kodu kimin yazdığından bağımsız olarak, o kodun canlıdaki davranışının sahibi olursunuz. Yazarlık geçmiştir. Sahiplik ise şimdiki zamandır. Çoğu geliştirme ekibi için kalıcı yanıt şudur: makine tarafından okunabilir bir kayıt (bir CODEOWNERS dosyası ve bir servis kataloğu) ile desteklenen, gerçek bir on-call rotasyonuna sahip ekip düzeyinde servis sahipliği. Bunu işler kılan ise ekiplerin yanlışlıkla eş anlamlı sandığı üç kelimedir: sorumluluk (responsibility), hesap verebilirlik (accountability) ve suçlama (blame).

Continue reading...

]]> <![CDATA[Event Odaklı Düşünmek: Yeni Başlayanlar için Komut ve Event]]> https://sph.sh/tr/posts/thinking-in-events-beginner-guide/ https://sph.sh/tr/posts/thinking-in-events-beginner-guide/ Fri, 17 Jul 2026 00:00:00 GMT Birçok ekip bir mesaj broker'ı ekler, RPC çağrılarının adını "event" olarak değiştirir ve komutlarla düşünmeye devam eder. Değişen isimdir, zihniyet değil. Bir komut hâlâ "şunu şimdi yap" der ve tek bir bilinen worker'a yöneliktir; yani hiçbir şey gerçekten ayrışmaz. Mesajlaşmanın operasyonel maliyetini ödersiniz, ama faydasını görmezsiniz.

request/response HTTP ve CRUD ile rahatsanız ama daha önce hiç event odaklı sistem kurmadıysanız, küçük bir değişim her şeyi yerine oturtur. Talimat vermek (komut) yerine zaten olmuş olguları duyurun (event). Bu bir düşünme biçimi olduğu için, herhangi bir broker'a dokunmadan önce doğru yapabilirsiniz.

Komut mu, Event mi, Mesaj mı?

Üç kelime sanki aynı anlama geliyormuş gibi kullanılıyor. Gelmiyor.

Continue reading...

]]> <![CDATA[Serverless İç Servis Katmanı Seçmek]]> https://sph.sh/tr/posts/serverless-internal-service-layer-101-choosing-the-layer/ https://sph.sh/tr/posts/serverless-internal-service-layer-101-choosing-the-layer/ Tue, 14 Jul 2026 00:00:00 GMT Bir serverless yapı tek takımı aştığında servisler birbirini çağırmaya başlar. Alışılmış cevap, başka bir takımın fonksiyon ARN'i üzerinde lambda:InvokeFunction yetkisi vermektir. Bu yetki, fonksiyon adını herkese açık bir sözleşmeye çevirir. Çağrılan takım artık fonksiyonu yeniden adlandıramaz, ikiye bölemez veya değiştiremez; çünkü göremediği bir repo'daki tüketiciyi bozar. Akla ilk gelen çözüm çağrılan servisi bir SDK istemci kütüphanesiyle sarmalamaktır ama işe yaramaz: bağımlılık IAM politikasının içindedir ve hiçbir istemci kütüphanesi oraya uzanamaz.

Continue reading...

]]> <![CDATA[gRPC, Protobuf ve Gateway’inizin İzin Verdiği Wire Format]]> https://sph.sh/tr/posts/serverless-internal-service-layer-102-protocols-payloads/ https://sph.sh/tr/posts/serverless-internal-service-layer-102-protocols-payloads/ Tue, 14 Jul 2026 00:00:00 GMT Alternatifleri eleyip bu katmanı seçtiniz. Sıradaki soru onun neyi taşıyabildiği ve 101. bölümdeki katmanı gören, service mesh dünyasından gelen herkes bunu bir dakika içinde soruyor: neden gRPC değil? Orada doğu-batı trafiğinin varsayılan taşıyıcısı gRPC ve soru da yerinde.

Cevap yapısal. Private REST API istekleri HTTP/1.1'e düşürüyor, gRPC ise HTTP/2 framing üzerinde taşınıyor. Dahası, gRPC konuşan her AWS yüzeyi Lambda fonksiyonlarını hedef olmaktan çıkarıyor; yani gateway değiştirmek sizi kurtarmıyor. Ama takımların gRPC'den asıl istediği şey bütün bunlardan sağ çıkıyor, çünkü istenen şey hiçbir zaman taşıma katmanı değildi. Şemaydı.

gRPC neden masada değil

Continue reading...

]]> <![CDATA[Katmanı Private API Gateway ile Kurmak]]> https://sph.sh/tr/posts/serverless-internal-service-layer-103-building-the-layer/ https://sph.sh/tr/posts/serverless-internal-service-layer-103-building-the-layer/ Tue, 14 Jul 2026 00:00:00 GMT Katmanı seçtiniz (101. bölüm) ve neyi taşıyacağını karara bağladınız (102. bölüm). Bu bölüm kurulum: private REST API, onu erişilebilir yapan resource policy, route bazına daraltılmış AWS_IAM yetkileri, sahiplik sınırına göre bölünen iki CDK stack'i, Node 22 Lambda'dan atılan SigV4 çağrısı ve bütün bunların çalışıp çalışmayacağına karar veren, VPC'ye bağlı çağıranlarla ilgili operasyonel gerçekler. Desenin merkezindeki değişiklik küçük kalıyor: çağıranın execution role'ü, fonksiyon ARN'i üzerinde lambda:InvokeFunction yerine bir route ARN'i üzerinde execute-api:Invoke taşır ve çağrılan fonksiyonun ARN'i kendi stack'inden hiç dışarı çıkmaz. Önce private endpoint kısıtı geliyor, çünkü API tipini her şeyden önce o belirliyor.

Private endpoint yalnızca REST'te var

Continue reading...

]]> <![CDATA[Serverless Servisler Arasında Kimlik ve Şifreleme]]> https://sph.sh/tr/posts/serverless-internal-service-layer-104-identity-encryption/ https://sph.sh/tr/posts/serverless-internal-service-layer-104-identity-encryption/ Tue, 14 Jul 2026 00:00:00 GMT 103. bölüm katmanı kurdu: paylaşılan bir execute-api interface endpoint üzerinden erişilen, her çağrısı SigV4 ile imzalanan ve route bazlı yetkilendirilen private bir REST API. O katman bir soruyu iyi cevaplıyor, ikincisini ise tamamen açık bırakıyor.

SigV4 hangi servisin çağırdığını kanıtlar. Kimin adına çağırdığı hakkında hiçbir şey söylemez. Bunlar farklı sorulardır ve yalnızca ilkini cevaplayan bir katman, her servisin her kullanıcı adına iş yapabildiği bir katmandır. Bu bölüm o boşluğu kapatıyor, ardından taşıma katmanının neyi şifreleyip neyi şifrelemediğini tam olarak söylüyor.

Doğrulanmış özneyi taşımak

Continue reading...

]]> <![CDATA[Çok Hesaplı Kurulum: Hesaplar Arası Çağrılar ve Veri Sınırı]]> https://sph.sh/tr/posts/serverless-internal-service-layer-105-multi-account/ https://sph.sh/tr/posts/serverless-internal-service-layer-105-multi-account/ Tue, 14 Jul 2026 00:00:00 GMT 101 ile 104 arasındaki bölümler bu iç servis katmanını tek bir AWS hesabının içinde seçti, protokollerini belirledi, kurdu ve güvenli kıldı. Çok takımlı yapılar orada kalmaz. Takım sınırı genelde bir hesap sınırının üzerine oturur ve bu tek hamle, katmanın altındaki yetkilendirme kurallarını baştan yazar. Aynı hesapta, API'nin resource policy'si ile çağıranın identity policy'si bir OR'dur: ikisinden biri çağrıya izin verebilir. Hesaplar arasında bunlar bir AND'e döner: ikisinin de açıkça izin vermesi gerekir ve sessizlik reddetmek demektir. Bu bölümdeki her şey o dönüşten çıkıyor: seçebileceğiniz iki ağ topolojisi, veri sınırını taşıyan politikalar ve organizasyon seviyesinde hiç yazamayacağınız o tek guardrail. Aşağıdaki her kural AWS dokümantasyonuna sabitlendi.

Continue reading...

]]> <![CDATA[Katman Nasıl Bozulur: Throttle, Retry ve Döngüler]]> https://sph.sh/tr/posts/serverless-internal-service-layer-106-failure-modes/ https://sph.sh/tr/posts/serverless-internal-service-layer-106-failure-modes/ Tue, 14 Jul 2026 00:00:00 GMT Katman kuruldu, kimliği iki yönde de yerine oturdu ve hesaplara yayıldı. Şimdi dürüst kısım: nasıl bozulduğu. Her iç çağrının arasına bir gateway koymanın bedeli, çağrı başına eklenen fiyattan ibaret değil. Bozulmanın şeklini de değiştiriyor ve direct invoke'un size bedavaya verdiği iki şeyi sessizce geri alıyor: Lambda'nın özyinelemeli döngü kesicisi ve retry'ın kendisi. 103. bölümdeki katman yine de kurulmaya değer. Bu bölümün konusu şu: katmanın geri aldığı işleri artık siz üstleniyorsunuz ve eksilen parçalar, çoğu yazının uyardığı parçalar değil.

Continue reading...

]]> <![CDATA[Gözlemlenebilirlik ve Service Mesh'ler Nereye Gidiyor]]> https://sph.sh/tr/posts/serverless-internal-service-layer-107-observability/ https://sph.sh/tr/posts/serverless-internal-service-layer-107-observability/ Tue, 14 Jul 2026 00:00:00 GMT Bir service mesh size üç şey vaat eder: kimlik, dayanıklılık ve gözlemlenebilirlik. Bu seri ilk ikisini hesapta zaten duran primitive'lerden kurdu: kimliği 104. bölümde, dayanıklılığı 106. bölümde. Üçüncüsü gözlemlenebilirlik ve insanların bedava geleceğini varsaydığı parça tam olarak bu. Yarısı gerçekten bedava geliyor. Tek satır uygulama kodu yazmadan, her çağrı tek bir JSON satırı yazıyor: çağıran servis, route, status ve latency. Ortada hiçbir sidecar yok.

Continue reading...

]]> <![CDATA[CDK TypeScript Lambda: Bundler ve cdk synth Runner Seçimi]]> https://sph.sh/tr/posts/cdk-lambda-bundler-runner-benchmark/ https://sph.sh/tr/posts/cdk-lambda-bundler-runner-benchmark/ Sat, 11 Jul 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[Nub vs Vite+: JS Yığınının Zıt Uçları İçin İki Rust Araç Zinciri]]> https://sph.sh/tr/posts/nub-vs-vite-plus-javascript-toolchain/ https://sph.sh/tr/posts/nub-vs-vite-plus-javascript-toolchain/ Sat, 11 Jul 2026 00:00:00 GMT JavaScript araç zinciri hâlâ ayrı parçalardan oluşan bir yığın: paket yöneticisi, runtime, TypeScript çalıştırıcısı, bundler, test çalıştırıcısı, linter ve formatlayıcı; her birinin kendi config dosyası ve kendi sürüm kayması var. 2026'nın iki projesi bu yığını tek ve hızlı bir Rust ikilisine indirmeyi vaat ediyor: Nub ve Vite+. İkisi de oxc tabanlı, tek ikilili ve haftalar arayla çıktı; bu yüzden geliştiriciler onları sürekli rakip diye sınıflandırıyor. Değiller. Vite+, tarayıcıya bakan uygulama hattının sahibi; Nub ise stok Node sürecinin sahibi. Kural bu kadar basit: derleme çıktın tarayıcıda yükleniyorsa Vite+ üzerinde standartlaş; bir Node süreci olarak çalışıyorsa Nub'a uzan. Aşağıdaki sayıların tümü sağlayıcının belirli senaryolardaki mikro benchmark'larından geliyor.

Continue reading...

]]> <![CDATA[Stateful Kaynaklar Ayrı Bir CDK Stack'inde mi Durmalı?]]> https://sph.sh/tr/posts/cdk-stateful-stack-named-contracts/ https://sph.sh/tr/posts/cdk-stateful-stack-named-contracts/ Fri, 03 Jul 2026 00:00:00 GMT Bir CDK uygulaması aynı yerleşim sorusunu defalarca yanıtlar: bu kaynak, onu kullanan Lambda fonksiyonlarıyla aynı stack'te mi dursun, yoksa kendi stack'ini mi alsın? Yaygın tavsiye, "veritabanını ayrı tut," doğru cevaba yanlış testle ulaşır. Ölçüt state değildir. Paylaşılan bir EventBridge bus'ı hiç veri tutmaz; ama onu silmek tüm domain'leri aynı anda bozar, dolayısıyla "state tutuyor mu" sorusu onu yanlış sınıflandırır. Yerleşimi belirleyen ölçüt yaşam döngüsüdür: bir kaynağın ömrü tek bir dağıtımdan uzun olduğunda kendi uzun ömürlü stack'ini hak eder ve diğer stack'ler ona bilinen bir adla erişir. Bu ad bir sözleşmedir ve sözleşme, ayarlayabileceğiniz bir bağlılık spektrumunun üzerinde durur.

Yaşam döngüsü testi

Continue reading...

]]> <![CDATA[AWS Limitlerine Takılmadan Ölçekte IAM Politika ve Rol Yönetimi]]> https://sph.sh/tr/posts/iam-policies-roles-at-scale-aws-limits/ https://sph.sh/tr/posts/iam-policies-roles-at-scale-aws-limits/ Wed, 01 Jul 2026 00:00:00 GMT IAM'in sessiz ve katı tavanları var. Bir yönetilen politika ancak belli sayıda karakter tutabilir. Bir role ancak belli sayıda politika ekleyebilirsiniz. Satır içi politikalar, uyarı vermeden dolan bir varlık başına boyut bütçesini paylaşır. Hesapların varsayılan bir rol kotası vardır. Tek bir paylaşılan mega-role yaslanıp izinleri konsoldan yapıştıran ekipler bu tavanlara doğru sürüklenir ve bir dağıtımın ortasında anlaşılması güç bir hatayla engellenir. Çıkış yolu yapısal: varsayılan olarak en az ayrıcalık, sorumluluk başına tek politika, paylaşılan mega-role yerine dar kapsamlı roller ve koruma katmanı olarak izin sınırları ile SCP'ler.

Continue reading...

]]> <![CDATA[Backstage Kur mu Satın Al mı: Kendi IDP'nin Gerçek Maliyeti]]> https://sph.sh/tr/posts/backstage-build-vs-buy/ https://sph.sh/tr/posts/backstage-build-vs-buy/ Tue, 30 Jun 2026 00:00:00 GMT Liderlerin Backstage'e yönelmesinin nedeni servis dağınıklığıdır: onlarca ya da yüzlerce servis var ve hangisinin nerede çalıştığını, kimin sahibi olduğunu kimse söyleyemiyor. Tuzak şudur: araç demoda hızlı bir kurulum gibi görünür, bu yüzden bütçe kuruluma yazılır ve onu ayakta tutan şeyi ıskalar. Backstage satın aldığınız bir ürün değil, ekip ayırdığınız bir çatıdır ve asıl tekrar eden gider kalıcı bir platform ekibidir. Bundan sonraki karar, Backstage'i kendiniz mi işleteceğiniz yoksa yönetilen bir geliştirici platformu mu kullanacağınızdır; ortada fonlanmış bir platform ekibi yoksa varsayılan yanıt yönetilen platformdur.

Continue reading...

]]> <![CDATA[Bruno API Koleksiyonlarını Git'te Tutmak: Bedava Postman Değil, Bir İş Akışı Değişikliği]]> https://sph.sh/tr/posts/bruno-api-collections-in-git/ https://sph.sh/tr/posts/bruno-api-collections-in-git/ Mon, 29 Jun 2026 00:00:00 GMT API koleksiyonunuz bir bulut sağlayıcıda ya da tek bir mühendisin laptopunda yaşarken, o uç noktalara hizmet veren kod git'te yaşıyor. Bir uç nokta zorunlu bir header eklediği veya bir alanı yeniden adlandırdığı anda ikisi birbirinden uzaklaşır: kod değişikliği bir pull request ile gider, ama kaydedilmiş istek geride kalır ve koleksiyonu sonradan açan kişi, artık gerçeğe uymayan bir isteği debug eder. Çözüm, istek koleksiyonunuzu kodun yanında düz metin dosyaları olarak commit etmektir; böylece API sözleşmesi, kullandığı handler ile aynı pull request, aynı inceleme ve aynı geçmişten geçer. Buradaki araç Bruno, ama asıl mesele onu hangi istemcinin gösterdiğinden çok sözleşmenin nerede yaşadığı; secret'lar etrafında net bir sınır ve bulut iş birliğinin hâlâ kazandığı birkaç durum var.

...

Continue reading...

]]> <![CDATA[AWS Kinesis: Data Streams vs Firehose vs Managed Flink]]> https://sph.sh/tr/posts/aws-kinesis-family-deep-dive/ https://sph.sh/tr/posts/aws-kinesis-family-deep-dive/ Sun, 28 Jun 2026 00:00:00 GMT "Kinesis", AWS'deki en fazla anlam yüklenmiş isimlerden biridir. İsim, farklı problemleri çözen dört ayrı servisi kapsar; bu yüzden konsoldaki bir açılır listeden "Kinesis" seçen bir ekip, çoğu zaman seçtiği servisin varsaydığı işi yapamadığını sonradan fark eder. Bir mühendis "bunu Kinesis'e koyarız" dediğinde neredeyse her zaman Data Streams'i kasteder: shard tabanlı, sıralı ve yeniden okunabilen ham log'u. Diğer üçü bir teslim borusu, bir akış işleme motoru ve bir video servisidir. Aşağıdaki bölümler önce dördünü ayrıştırır, sonra karar vermeden önce bilmen gereken Data Streams mekaniğine, maliyet şekline ve karar sınırlarına derinlemesine iner.

Dört servisin ayrımı

Continue reading...

]]> <![CDATA[Suçsuz Postmortem: Bir Model ve Kopyala-Yapıştır Şablon]]> https://sph.sh/tr/posts/blameless-culture-postmortem-thinking/ https://sph.sh/tr/posts/blameless-culture-postmortem-thinking/ Sun, 21 Jun 2026 00:00:00 GMT Aynı kesinti tekrar tekrar geri geliyor; çünkü olay incelemeniz bir neden değil, bir suçlu buldu. Düzeltilmesi gereken hata modeli budur. Yanlış komutu yazan kişiyi adıyla işaret etmek, aynı komutun sistemi bir daha düşürmesini nadiren engeller; düzeltme, komutun geçtiği kontrolde yapılmalıdır. Sayfaya bir isim yazılıp kapanan bir inceleme, tekrarı önleyecek sistem değişikliğinin gerisinde kalır. Aşağıdaki model kişileri değil kontrolleri hedefler; yanında kopyalanabilir bir şablon ve bireysel sorumluluğun nerede hâlâ geçerli olduğuna dair net bir sınır gelir.

İşleyiş modeli farklı ekiplerde tutarlı biçimde işliyor; ancak "suçsuzluk" bir kültür değişimidir. Bunun oturduğunu kanıtlayan metriklerin kımıldaması birkaç çeyrek alır.

İki Soru Kümesi, İki Sonuç

Continue reading...

]]> <![CDATA[Mühendislik Ekibi Dokümantasyonu: Çalışma Anlaşmaları, Definition of Done ve Nöbet Belgeleri]]> https://sph.sh/tr/posts/team-documentation-ways-of-working/ https://sph.sh/tr/posts/team-documentation-ways-of-working/ Sat, 20 Jun 2026 00:00:00 GMT Bir ekibin çalışma biçimi genellikle insanların kafasında yaşar. Sonuç tahmin edilebilir: her yeni katılan kişi "biz işleri nasıl yaparız" konusunun farklı ve eksik bir versiyonunu öğrenir, beklentiler hiç yazılmadığı için nöbet stresli geçer ve kilit bir kişi ayrıldığında aylarca biriken bağlamı yanında götürür. Çözüm "daha fazla belge yazmak" değildir; çözüm, çalışma biçimini her biri tek bir sahibe ait, işin yanında saklanan, küçük ve adı konmuş bir canlı belge kümesi olarak ele almak ve onboarding'i bir refakatçi ritüeli yerine takip edilen, kontrol listeli bir program olarak yürütmektir. Devamı, sağlıklı bir ekibin sahiplendiği belirli belgelerin bir taksonomisidir.

Continue reading...

]]> <![CDATA[AppSync Subscription'larını AppSync Dışından Tetiklemek]]> https://sph.sh/tr/posts/appsync-graphql-bff-subscriptions/ https://sph.sh/tr/posts/appsync-graphql-bff-subscriptions/ Fri, 19 Jun 2026 00:00:00 GMT AWS AppSync size yönetilen WebSocket subscription'ları verir, ama bunlar yalnızca bir AppSync GraphQL mutation'ına yanıt olarak tetiklenir. Çok servisli bir Backend-for-Frontend (BFF) içinde asıl durum downstream'de, yani sipariş, stok ve ödeme servislerinde tutulur ve bu durum değişiklikleri hiçbir zaman bir AppSync mutation'ından geçmez. Yani bir BFF'te "subscription yönetmek" aslında tek bir problemdir: downstream olaylarını NONE veri kaynaklı dahili bir mutation'a köprülemek ve sonra payload'ı AppSync'in fan-out yapmasına bırakmak. Aşağıdaki kurulum AWS CDK ile yapılan bir incelemedir; henüz hiçbir parçası deploy edilmedi ya da ölçülmedi.

Continue reading...

]]> <![CDATA[GitHub Actions Tetikleyicileri: push vs pull_request vs Merge Queue vs Release]]> https://sph.sh/tr/posts/ci-steps-by-trigger/ https://sph.sh/tr/posts/ci-steps-by-trigger/ Fri, 19 Jun 2026 00:00:00 GMT Özellik commit'i push'layın, pull request açın ya da release çıkarın; birçok pipeline üçüne de aynı yanıtı verir: tam test matrisi, entegrasyon paketi ve deploy mantığının hepsi tetiklenir. Asıl sorun bu tekdüzeliktir. Her git olayı yaşam döngüsünün farklı bir noktasında gelir ve farklı bir güvenlik bağlamı taşır; bir tetikleyiciye ait olan kontrol, başka bir tetikleyicide ya israftır ya da tehlikelidir. Bunun yerine on: bloğunu bir yönlendirme tablosu gibi ele alın: kontrolü tetikleyiciye eşleyin ki PR geri bildirimi hızlı kalsın, main deploy edilebilir kalsın ve release'ler tekrar üretilebilir kalsın.

Continue reading...

]]> <![CDATA[Native Mobil Uygulamalar için Sunucu Güdümlü Arayüz]]> https://sph.sh/tr/posts/server-driven-ui-mobile/ https://sph.sh/tr/posts/server-driven-ui-mobile/ Fri, 19 Jun 2026 00:00:00 GMT Bir native uygulama yayınlarsınız, sonra her hafta bir vitrin ekranını, bir promosyon afişini veya bir ödeme adımını değiştirmeniz gerekir. Her değişiklik app-store incelemesini ve kullanıcıların güncellemesini bekler; zaten yüklü olan sürümler aylarca kullanıcıların cebinde kalır, yani bir sunucuyu yeniden dağıttığınız gibi istemciyi geri alamazsınız. Sunucu güdümlü arayüz (SDUI) buna, yeni native kod yerine bir arayüz tarifi göndererek yanıt verir: buradaki öneri, onu içerik biçimli yüzeyler için bir neşter gibi kullanmak ve sözleşmeyi eski istemciler zarifçe geri çekilecek biçimde tasarlamaktır.

Web Karşılığı ve Mobildeki Ek Kısıt

Continue reading...

]]> <![CDATA[Commit'ten Üretime Lead Time Nasıl Azaltılır?]]> https://sph.sh/tr/posts/compressing-time-to-production/ https://sph.sh/tr/posts/compressing-time-to-production/ Thu, 18 Jun 2026 00:00:00 GMT Birçok organizasyonda bir özellik canlıya çıkmadan günlerce kod-tamam halinde bekleyebilir; bir inceleme kuyruğunun, bir release train'in ya da kaçırdığı bir deploy slotunun arkasında takılı kalır. Bunu yakalayan metrik, değişiklikler için lead time'dır: bir değişikliğin commit edilmesinden üretimde çalışmasına kadar geçen süre; ve bu sürenin büyük kısmı programlama değil, süreçtir. Bir teknik liderin yapabileceği en faydalı hamle, lead time'ı birincil teslimat metriği olarak ele almak ve en büyük bekleme aşamasının üzerine yapısal olarak gitmektir. Sıra bellidir: parti boyutunu küçült, deploy ile release'i ayır, sonra güvenlik kapısını ve ekipler arası kapıyı kendi kendine işleyen guardrail'lere dönüştür.

Lead Time Saati

Continue reading...

]]> <![CDATA[Shift-Left Security: İnceleme Kuyruğu Darboğazını Kaldırmak]]> https://sph.sh/tr/posts/security-without-the-review-queue/ https://sph.sh/tr/posts/security-without-the-review-queue/ Thu, 18 Jun 2026 00:00:00 GMT Birçok organizasyonda tamamlanmış bir değişiklik, üretime çıkmadan önce günlerce inceleme kuyruğunda bekler. Bu kuyruğun nedeni, güvenlik incelemesinin tek tip manuel bir kapı gibi ele alınmasıdır: her değişiklik, riski ne olursa olsun, üretime ulaşmadan önce bir insanın arkasında sıraya girer. Çözüm, incelemeyi her değişiklik için bir kapı olarak görmeyi bırakmaktır: onu otomatik, risk-tabanlı korkuluklara dönüştürün ki sıradan durum hiçbir zaman bir insanı beklemesin. Kuyruk böylece güvenliği zayıflatmadan ortadan kalkar ve kapı yalnızca riskin gerektirdiği yerde kalır.

Continue reading...

]]> <![CDATA[BFF ile Mobil API Sürümleme: İstemciyi Geri Alamadığınızda Ship Etmek]]> https://sph.sh/tr/posts/the-client-you-cannot-roll-back/ https://sph.sh/tr/posts/the-client-you-cannot-roll-back/ Thu, 18 Jun 2026 00:00:00 GMT Sunucuda kötü bir deploy saniyeler içinde geri alınabilir; mobilde ise ship edilen binary kalıcıdır, app store incelemesi sizin kontrolünüz dışındadır ve eski istemci sürümleri aylarca kullanımda kalır. Bu asimetri, release stratejinizi belirlemesi gereken tasarım kısıtıdır: istemci, sistemin geri alamayacağınız tek parçasıdır; bu yüzden hem güvenlik hem hız, değiştirebildiğiniz tarafa kaymak zorundadır. Bu kısıttan doğan kaldıraçlar şunlar: bir backend-for-frontend katmanı, bağımsız deploy için tüketici güdümlü sözleşmeler, geriye dönük uyumlu API evrimi ve server-driven UI'ın değerini nerede kanıtladığına dair net bir sınır.

Asimetrik Saat

Continue reading...

]]> <![CDATA[Lambda Durable Functions vs Step Functions: Orkestratör Ne Zaman Kodunuza Ait?]]> https://sph.sh/tr/posts/lambda-durable-functions-vs-step-functions/ https://sph.sh/tr/posts/lambda-durable-functions-vs-step-functions/ Wed, 17 Jun 2026 00:00:00 GMT Problem

Continue reading...

]]> <![CDATA[Frontend Platformu için Golden Path: İskelet, Paylaşılan Paketler ve Görev CLI'si]]> https://sph.sh/tr/posts/paved-road-frontend-platform/ https://sph.sh/tr/posts/paved-road-frontend-platform/ Tue, 16 Jun 2026 00:00:00 GMT Bir organizasyon çok sayıda küçük frontend uygulaması işlettiğinde, her ekip farklı bir iskeletten başlar ve build yapılandırması, lint kuralları ile dağıtım şekli birkaç sprint içinde birbirinden kayar. Bu kayma tembellikten değildir: bir uygulamayı başlatmanın standart yolunun aynı zamanda en hızlı yolu olduğu tek bir yer yoktur, bu yüzden her ekip temelleri yeniden kurar ve gözlemlenebilirliği, i18n'i ve dağıtımı biraz farklı şekilde yeniden uygular. Çözüm, üç temel taştan kurulan ince bir asfalt yoldur (bir golden-path iskeleti, sürümlü paylaşılan paketler ve bir görev CLI'si); işe yaradığını kanıtlayan tek ölçüt ise zorunlu tutulması değil, gönüllü benimsenmesidir.

Ekipler Arası Kayma Neden Birikir

Continue reading...

]]> <![CDATA[Sunum Servisi için Hexagonal Mimari: BFF Karşılaştırması]]> https://sph.sh/tr/posts/hexagonal-presentation-service/ https://sph.sh/tr/posts/hexagonal-presentation-service/ Fri, 12 Jun 2026 00:00:00 GMT Sunum servisi, tek bir UI parçasının arkasında duran ince arka uçtur: parayı ve tarihleri biçimler, metni ve i18n'i çözer, oturum durumunu şekillendirir ve UI adına tek bir alt domain servisini proxy'ler. Ekipler bunu yapışkan kod için bir çöplük olarak görür ve bu kod zamanla çamur topuna dönüşür. Para biçimleme HTTP işleyicilerinin içine karışır, alt servis istemcisinin tuhaflıkları iş kurallarına sızar. Bu servisi sürdürülebilir tutan disiplin port-ve-adaptör (hexagonal mimari) yaklaşımıdır ve tek bir kurala iner: domain çekirdeğini somut hiçbir şeye bağımlı olmamaya zorla.

Yapışkan Koddan Çamur Topuna

"İnce proxy" olarak başlayan bir servis, hiçbir sınır ayakta kalmayana kadar sessizce sorumluluk biriktirir:

Continue reading...

]]> <![CDATA[Sunucu Tarafı Micro-Frontend Kompozisyonu: Tek Sayfa, Birçok Ekip]]> https://sph.sh/tr/posts/server-side-micro-frontend-composition/ https://sph.sh/tr/posts/server-side-micro-frontend-composition/ Tue, 09 Jun 2026 00:00:00 GMT Checkout ya da vitrin gibi tek bir yüksek trafikli sayfa, çoğu zaman bağımsız teslimat yapması gereken birçok ekibin katkısına ihtiyaç duyar. Frontend monolit, bu ekipleri tek bir sürüm trenine bindirir; böylece bir ekibin yavaş derlemesi veya bozuk testi diğer tüm ekiplerin deploy'unu engeller. Sayfayı birleştiren mekanizma kolay kısımdır; asıl zor problem, sahiplik sınırı ile birçok ekibi koordineli bir sürüm olmadan görsel ve davranışsal olarak hizalı tutan sürümlenmiş tutarlılık sözleşmesidir. Çok ekipli, SEO'ya duyarlı ve ilk boyamanın önemli olduğu bir sayfada varsayılan seçenek sunucu tarafı kompozisyondur; istemci tarafı kompozisyon ile iframe'ler daha dar senaryolarda öne geçer.

Continue reading...

]]> <![CDATA[Init Amortismanına Göre Kod Mimarisi: Lambda'da Yalın, Ağırlık Ancak Hak Edilince]]> https://sph.sh/tr/posts/code-architecture-init-amortization/ https://sph.sh/tr/posts/code-architecture-init-amortization/ Wed, 03 Jun 2026 00:00:00 GMT Problem

1. Bölüm Lambda sorusunun topoloji yarısını yanıtladı: single responsibility bir kod ilkesidir, kaç fonksiyon deploy edileceği ise ayrı bir topoloji kararıdır. Diğer yarı, belirli bir runtime'ın içine ne kadar kod mimarisi girmesi gerektiğidir: ne kadar OOP, dependency injection ve framework ağırlığı. Yanıt 1. Bölüm'ün "istisnayı hak et" biçimini yansıtır: varsayılan olarak yalın fonksiyonel handler kullan, sonra her runtime'ın init-amortismanı izin verdikçe daha ağır yapıyı hak et. Kararı belirleyen değişken, tek bir initialization'ın kaç invocation'a hizmet ettiğidir.

Continue reading...

]]> <![CDATA[AWS Lambda'da Effect: SST ve DynamoDB ile URL Kısaltıcı Oluşturma]]> https://sph.sh/tr/posts/effect-lambda-link-shortener/ https://sph.sh/tr/posts/effect-lambda-link-shortener/ Wed, 03 Jun 2026 00:00:00 GMT Tipik bir TypeScript Lambda handler'ı kesişen işleri kodun içine yığar: JSON.parse(event.body), gelişigüzel if (!body.url) kontrolleri, bir try/catch içinde URL doğrulaması, ardından her catch bloğunun bir HTTP statüsünü yeniden türetip bir hata gövdesini yeniden serileştirdiği iş mantığı. Asıl maliyet ilk bakışta görünmez; sorun boilerplate değil, statülerin ve hata şekillerinin çağrı noktasında seçilmesi ve bu yüzden zamanla kayması. Dahası, mantığı test etmenin tek yolu ya gerçek AWS'ye bağlanmak ya da SDK istemcisini elle mock'lamak. Effect bu yığını tipli bir programın üzerindeki ince bir adaptöre indirger. Kurulabilir tek bir parça, Lambda ve DynamoDB üzerinde SST v4 ile kurulmuş bir URL kısaltıcı, her Effect yapı taşının size tam olarak ne kazandırdığını gösterir.

Continue reading...

]]> <![CDATA[AWS Lambda: Tek Amaçlı Fonksiyonlar mı, Lambdalith mi?]]> https://sph.sh/tr/posts/lambda-function-granularity-responsibility-scope-domain/ https://sph.sh/tr/posts/lambda-function-granularity-responsibility-scope-domain/ Wed, 03 Jun 2026 00:00:00 GMT Problem

Continue reading...

]]> <![CDATA[Scrum, Kanban ve Scrumban: Yapay Zeka Destekli Ekipler]]> https://sph.sh/tr/posts/scrum-kanban-scrumban-ai-driven-teams/ https://sph.sh/tr/posts/scrum-kanban-scrumban-ai-driven-teams/ Tue, 02 Jun 2026 00:00:00 GMT Yapay zeka asistanları artık kodun giderek büyüyen bir kısmını yazıyor. Mühendislik liderleri ise hâlâ Scrum mı, Kanban mı, başka bir çevik çerçeve mi seçecekleri konusunda haftalarca tartışıyor; sonra başka bir şirketin törenlerini kopyalayıp neden hiçbir şeyin daha hızlı akmadığına şaşırıyor. Tuzak, çerçevenin ismini kararın kendisi sanmaktır. Görüşüm şudur: yapay zeka destekli bir ekibin neredeyse hiç markalı bir metodolojiye ihtiyacı yoktur. İhtiyacı olan, bağlamına göre ayarlanmış dört geri besleme döngüsüdür: işin nasıl aktığı, ne sıklıkla yeniden yön belirlediğiniz, paralelde ne kadar iş yürüdüğü ve çıktının nasıl incelendiği. Bu karar merceği, bir sonraki çerçeve modasından sonra da geçerli kalır ve yapay zekanın darboğazı kod yazmaktan uzaklaştırdığını hesaba katar.

Continue reading...

]]> <![CDATA[Zod Branded Types ile PII Koruması: Compile-Time Log Güvenliği]]> https://sph.sh/tr/posts/zod-brands-prevent-pii-logging/ https://sph.sh/tr/posts/zod-brands-prevent-pii-logging/ Thu, 28 May 2026 00:00:00 GMT Structured loglar PII'yi birbirine çok benzeyen üç çağrı yerinden sızdırır: logger.info({ user }), metrics.increment("login", { email }) ve tracer.startActiveSpan("auth", { attributes: { ip } }). Çoğu ekip bunu yakalamak için Pino redact.paths ya da cloud tarafında bir scrubber ekler. O savunmalar son hattır ve liste tabanlıdır; şemalar değiştikçe sessizce kayarlar. Effect-TS aynı problemi runtime'da, Redacted ve değer yerine basan bir Logger ile ele alıyor. Pino, problemin bir dilimini compile-time'da LogFnFields ile kapatıyor; belirli anahtarları never üzerinden yasaklıyor. Rust'ın secrecy crate'i üçüncü bir yol izliyor: wrapper Display'i hiç implement etmiyor.

Continue reading...

]]> <![CDATA[Staff Engineer Solver Arketipi: Bir Operasyon Modeli]]> https://sph.sh/tr/posts/solver-track-staff-engineer-operating-model/ https://sph.sh/tr/posts/solver-track-staff-engineer-operating-model/ Tue, 26 May 2026 00:00:00 GMT Mühendislik organizasyonlarında kendiliğinden oluşan gayri resmi hızlı şerit

Belirli bir ölçeği aşan mühendislik organizasyonlarının çoğunda, standart SDLC'nin yanına sessizce ikinci bir şerit kurulur: beklemeye fazla stratejik, planlamaya fazla belirsiz, tam ekip ayırmaya fazla dar işler için. Bu örüntü sektörden bağımsız tekrarlar: yönetici sponsorluğu, bir veya iki kıdemli mühendis, aylarla ölçülen bir süre ve tanınabilir küçük bir sonuç kümesi. Bu şeritlerin çoğu uygulama nedeniyle değil, ilk proje şeride girmeden önce operasyon modelini kimse yazmadığı için başarısız olur.

Continue reading...

]]> <![CDATA[Aurora Serverless v2 Nasıl Çalışır: Mimariye Derin Bakış]]> https://sph.sh/tr/posts/aurora-serverless-v2-architecture/ https://sph.sh/tr/posts/aurora-serverless-v2-architecture/ Mon, 25 May 2026 00:00:00 GMT Aurora Serverless v2, çoğu zaman provisioned Aurora'dan bağımsız, ayrı bir veritabanı ürünüymüş gibi tanıtılır. Bu çerçeve mühendisleri yanlış varsayımlara götürür: replika sayısının otomatik arttığı, ölçekleme anında bağlantıların düştüğü, her ölçeklemede cache'in soğuduğu sanılır. Üçü de doğru değil; ama Kasım 2024'ten beri bir dördüncü kısmen doğru: sıfıra ölçekleme bir soğuk başlangıç yolu ima ediyor. Altta yatan gerçek şu: Serverless v2, provisioned cluster'ların da üzerinde çalıştığı aynı Aurora işlem ve depolama altyapısına eklenmiş bir scaling daemon ve faturalama sarmalayıcısıdır.

Adlandırma üzerine kısa bir not

Continue reading...

]]> <![CDATA[Phronesis ve AI Kodlama Ajanları: Modelin Size Veremeyeceği Beceri]]> https://sph.sh/tr/posts/phronesis-and-ai-coding-agents/ https://sph.sh/tr/posts/phronesis-and-ai-coding-agents/ Mon, 25 May 2026 00:00:00 GMT AI kodlama ajanları kod yazma maliyetini neredeyse sıfıra indirdi. Ne kadar kod yazılması gerektiğini ve ne zaman yazılması gerektiğini bilmenin maliyeti ise kıpırdamadı. Bugünkü "AI verimliliği" tartışmasının büyük kısmı, insanların bu iki beceriyi birbirine karıştırarak birbirlerini yanlış anlamasından ibaret. Aristoteles'ten ödünç alınan bir çerçeve bu iki beceriyi temiz biçimde ayırıyor; Mario Zechner, Addy Osmani, Kent Beck, Simon Willison, METR ve Steve Yegge bu çerçeve üzerinden okunduğunda görünürdeki çelişkiler tek bir anlaşmazlığa iniyor. O anlaşmazlıkta Zechner doğruya Yegge'den daha yakın duruyor; ama Yegge'nin karşıt pozisyonu argümanı körleştirmek yerine keskinleştiriyor.

Tartışmanın Sürekli Karıştırdığı İki Beceri

Continue reading...

]]> <![CDATA[GitHub Environments: Deployment İçin Manuel Onay Kapıları]]> https://sph.sh/tr/posts/github-environments-approval-gates/ https://sph.sh/tr/posts/github-environments-approval-gates/ Tue, 19 May 2026 00:00:00 GMT Üretim deploy'larında insan onayı gerekir, ama çoğu ekip yanlış parçayı seçer. En sık görülen üç şekil şudur: bir label'a bakan workflow if: koşulu, issues: write izniyle yorum bekleyen marketplace onay action'ı, ya da herhangi bir katkıcının tetikleyebildiği workflow_dispatch butonu. Artifact'ı main üzerinden bir kez üretin, staging'e otomatik düşsün, aynı artifact production'a ancak bir PM ya da QA bir GitHub Environment kapısında onay verdikten sonra promote edilsin. Aynı artifact, iki environment, tek onay. Bu kapı hem deploy credential'ını hem de insan onayını birlikte kapsar ve run'a bağlı bir audit kaydı bırakır.

Environment nesnesi

Continue reading...

]]> <![CDATA[AWS Bedrock ve CDK ile RAG Agent Kurmak]]> https://sph.sh/tr/posts/aws-bedrock-rag-cdk-port/ https://sph.sh/tr/posts/aws-bedrock-rag-cdk-port/ Tue, 12 May 2026 00:00:00 GMT AWS, Bedrock Agent ile Knowledge Bases ve OpenSearch Serverless üçlüsünü yönetilen RAG yolu olarak konumlandırıyor: retrieval kodunu kendin yazmadan, belgeye dayalı sohbet uygulaması çıkarıyorsun. DigitalOcean rag-assistant şablonunun şeklini AWS-native servislere TypeScript ile CDK üzerinde taşıdım, uçtan uca dağıttım ve ilk koşunun düştüğünü gördüm. AWS Bedrock yönetilen RAG yığını CDK ile çalışıyor, ancak belge boşluğundan doğan iki tuzak ilk dağıtımını düşürecek: bölgeler arası inference profile için IAM açığı ve dağıtım anında otomatik ingestion job'un olmaması.

Mimari eşleme

Continue reading...

]]> <![CDATA[Amazon Bedrock Knowledge Bases Rehberi: Veri Kaynakları ve Vektör Depoları]]> https://sph.sh/tr/posts/bedrock-knowledge-bases-anatomy/ https://sph.sh/tr/posts/bedrock-knowledge-bases-anatomy/ Tue, 12 May 2026 00:00:00 GMT Konsol sihirbazının arkasındaki varsayılan

Amazon Bedrock Knowledge Bases; bir konnektörü, bir chunker'ı, bir embedding modelini, bir vektör deposunu ve bir retrieval API'sini tek bir yönetilen yüzeyde paketler. Confluence konnektörü aslında kılık değiştirmiş bir vektör deposu kararıdır. AWS dokümantasyonu, Confluence Cloud'un "şu anda" yalnızca OpenSearch Serverless vektör deposu ile kullanılabildiğini açıkça belirtir; aynı kilitlenme SharePoint ve Salesforce için de geçerlidir. Bu tek kısıt mimariyi iki yola ayırır; konnektörü bağlamadan önce seçim yapmak sizi yeniden yazımdan kurtarır.

Continue reading...

]]> <![CDATA[HMAC: Nedir, Nasıl Çalışır ve Ne Zaman Yanlış Araçtır]]> https://sph.sh/tr/posts/hmac-explainer-when-to-use/ https://sph.sh/tr/posts/hmac-explainer-when-to-use/ Tue, 12 May 2026 00:00:00 GMT Webhook alıcıları, imzalı indirme bağlantıları ve servisler arası iç çağrıların hepsi aynı soruya cevap arar: bu istek gerçekten paylaşımlı sırra sahip taraftan mı geldi ve bozulmadan mı ulaştı? Sabit zamanlı karşılaştırma, ham gövde üzerinden hash alma ve zaman kayması toleransının aynı anda doğru olması gerekir; aksi halde koruma süs olarak kalır. Her iki tarafın da aynı sırrı tutabildiği simetrik güven durumunda bütünlük ve özgünlük için doğru varsayılan, standart kütüphanenin sabit zamanlı karşılaştırma fonksiyonuyla birlikte HMAC-SHA-256'dır.

HMAC'in tam tanımı

Continue reading...

]]> <![CDATA[Kafka vs SNS/SQS/EventBridge: Ne Zaman ve Nasıl Geçmeli]]> https://sph.sh/tr/posts/kafka-or-event-bus-migration-signals/ https://sph.sh/tr/posts/kafka-or-event-bus-migration-signals/ Mon, 11 May 2026 00:00:00 GMT SNS+SQS, EventBridge, Pub/Sub veya Service Bus üzerinde çalışan ekipler eninde sonunda bir duvara çarpar ve "Kafka'ya geçmeli miyiz?" sorusunu sorar. Sorun şu: "duruma bağlı" cevapları hangi koşulların gerçekten önemli olduğunu sıralamadığı için karar, en son okunan dokümana doğru kayar. Kafka; dayanıklılık, replay, sıralama ve sürdürülebilir throughput sorunlarının cevabıdır. Yönetilen event bus'ta iki veya daha fazla somut sinyal ateşlenene kadar kalın, sonra rip-and-replace yerine transactional outbox ile aşamalı geçiş yapın.

Yedi sinyal geçişi haklı çıkarır, beş karşı sinyal geçişe karşı durur ve aşağıdaki geçiş planı event tiplerini tek tek taşır; böylece geri dönüş her adımda mümkün kalır.

Kafka'ya İten Sinyaller

Continue reading...

]]> <![CDATA[AWS Bedrock AgentCore'u CDK ile deploy etmek: hızlı başlangıç]]> https://sph.sh/tr/posts/agentcore-cdk-quickstart/ https://sph.sh/tr/posts/agentcore-cdk-quickstart/ Tue, 05 May 2026 00:00:00 GMT Çıkış noktası

Önceki post AgentCore Runtime'ı mimari düzeyde anlatıyor: container, identity, memory, gateway. Deployment sorusu tam orada başlıyor: AgentCore artık @aws-cdk/aws-bedrock-agentcore-alpha üzerinden CDK'dan erişilebilir, peki uçtan uca çalışan bir trial neye benziyor? Kısa cevap: alpha L2'yi kullan ve sürümünü pin'le. Stack kodu kısa kalıyor çünkü ağırlığı construct taşıyor; ilk invoke sonuç dönmeden önce birkaç IAM ve Marketplace ön koşulunun yerine oturması gerekiyor.

Ne kuruyoruz

eu-central-1'de AgentCore Runtime üzerinde minimal bir Strands agent'ı deploy eden tek bir CDK stack'i; build script'i ve boto3 invoke yardımcısı dahil. Tam dosya yapısı:

[code block]

Continue reading...

]]> <![CDATA[Claude'u GitHub Action ile PR Reviewer Olarak Kurmak]]> https://sph.sh/tr/posts/claude-code-action-pr-reviewer-setup/ https://sph.sh/tr/posts/claude-code-action-pr-reviewer-setup/ Mon, 04 May 2026 00:00:00 GMT Bir GitHub repo'suna AI destekli code review eklemek tek bir seçimle başlıyor: geçici bir LLM entegrasyonu mu, bakımı yapılan bir action mı. Bakımlı yol erişim kontrolünü ve prompt injection temizliğini zaten üstleniyor; geçici yolda ikisi de size kalıyor. anthropics/claude-code-action v1 başlanmaya değer varsayılan: pull_request trigger'ı, salt okunur bir tool allowlist'i, sabitlenmiş bir model ve insanda kalan bir merge geçidi.

Workflow dosyasının kendisi kısa. Karar gerektiren kısım etrafındakiler: onu hangi trigger tetikliyor, hangi izinleri alıyor, modelin hangi tool'ları çağırmasına izin var ve büyük bir PR'ın review maliyeti ne oluyor.

Önerilen kurulum

Continue reading...

]]> <![CDATA[TypeScript'te AWS Lambda Soğuk Başlatma Optimizasyonu: 5 Anti-Pattern]]> https://sph.sh/tr/posts/aws-lambda-typescript-anti-patterns/ https://sph.sh/tr/posts/aws-lambda-typescript-anti-patterns/ Tue, 28 Apr 2026 00:00:00 GMT Ekipler NestJS, Spring veya .NET monolitlerinden AWS Lambda'ya geçerken uzun ömürlü servislerde işe yarayan kalıpları yanlarında getiriyor. Bundle'lar şişiyor, cold start uzuyor ve platformun ekonomisi bu kalıpları cezalandırıyor. Lambda bir mikroservis değil, fonksiyondur; monolit OO/DI kalıpları bundle'ı şişirir, cold start'ı uzatır.

Hasarın çoğunu beş alışkanlık üretiyor: DI container'lar, modüler olmayan AWS SDK import'ları, god-handler servis sınıfları, modül üstünde senkron secret çağrısı ve ağır ORM'ler.

Continue reading...

]]> <![CDATA[Cloudflare Workers'a WASM Görsel Yeniden-Boyutlama Modülü Yüklemek]]> https://sph.sh/tr/posts/cloudflare-workers-wasm-image-resize/ https://sph.sh/tr/posts/cloudflare-workers-wasm-image-resize/ Wed, 22 Apr 2026 00:00:00 GMT Body'den JPEG alıp yeniden boyutlandırılmış JPEG döndüren bir POST /resize?w=800&q=85 handler'ı, Cloudflare Workers + WASM'ın bir görsel hattı sunucusu olarak en sade, oyuncak olmayan stres testidir. Tasarım üç edge-platform limitine aynı anda yüklenir: derlenmiş binary boyutu, isolate başına bellek ve istek başına CPU süresi. Sırayla okunduğunda yayınlanmış limitler sorunun büyük kısmını zaten çözer. Free tier tek başına CPU süresinden elenir; Paid tier'da ise tasarım, ikinci bir codec'e pek yer bırakmayan bir bundle bütçesi içinde, istek başına tek görsel için iş görür.

Continue reading...

]]> <![CDATA[WebAssembly Kullanım Alanları: Tarayıcı, WASI Sunucu ve Edge Compute]]> https://sph.sh/tr/posts/webassembly-101/ https://sph.sh/tr/posts/webassembly-101/ Tue, 21 Apr 2026 00:00:00 GMT WebAssembly konuşmaları sürekli birbirini ıskalıyor; çünkü tek bir kelime üç çok farklı mimari bahsi örtüyor. Frontend geliştirici "web'i hızlandırır" diye düşünüyor, backend geliştirici "container'ların yerine geçer" diye okuyor, platform geliştirici "edge'i çalıştırır" diye varsayıyor ve üçü de kısmen haklı. Tek bir runtime'ı değerlendirmeden önce problemini bu üçünden birine oturt; hiçbiri mevcut mimarini tarif etmiyorsa Wasm'i şimdilik ertele.

30 Saniyede WASM

Tek bytecode, üç ayrı bahis: tarayıcıda performans, sunucuda WASI runtime, edge'de compute.

Continue reading...

]]> <![CDATA[EventBridge Hesaplar Arası Fan-Out: Tek Producer, İzole Consumer'lar]]> https://sph.sh/tr/posts/event-fanout-isolated-consumer-accounts/ https://sph.sh/tr/posts/event-fanout-isolated-consumer-accounts/ Mon, 20 Apr 2026 00:00:00 GMT Bir producer servisi yeni consumer'ları midye gibi üstüne toplar. Event isteyen her yeni takım başka bir if enabled(x) publish(x) dalı ekler ve her yeni consumer için producer'ın deploy edilmesi gerekir. Dallar, uygulama koduymuş gibi görünen bir anahtar kutusudur; herhangi bir hatanın etki alanı ise ödeme işlemleriyle aynı hesabın içindedir.

Bu dalları ortadan kaldıran varsayılan şudur: tek event, birçok consumer, her biri kendi AWS hesabında kendi SQS ve DLQ'suyla. Fan-out'u event bus katmanındaki kurallar taşır; producer'ın kodu bu işin dışında kalır. Audit, Customer Center, Marketing ve onlardan sonra gelen her consumer aynı topolojiyi kullanır. Farklı bir omurga ancak sıralama, replay veya ham throughput zorladığında yerini hak eder.

Continue reading...

]]> <![CDATA[wasmCloud ve NATS: Event Bus'ı Taşınabilir Kılmak]]> https://sph.sh/tr/posts/wasmcloud-nats-event-bus-portability/ https://sph.sh/tr/posts/wasmcloud-nats-event-bus-portability/ Mon, 20 Apr 2026 00:00:00 GMT Event-driven bir sistemde vendor lock-in runtime'da değil, bus topolojisinde yaşar. Runtime haftalar içinde değiştirilebilir; topoloji çeyrekler alır. Serverless kilitlenmesi tartışmaları bu ayrımı çoğunlukla atlar; Lambda'yı Cloud Functions'a, Workers'ı Containers'a karşı konumlandırır, event bus'ı da tesisat hanesine yazar.

Continue reading...

]]> <![CDATA[Web ve Mobil Uygulamalarda Uzun Süren API İsteklerini Yönetmek]]> https://sph.sh/tr/posts/async-api-patterns-web-mobile/ https://sph.sh/tr/posts/async-api-patterns-web-mobile/ Sat, 18 Apr 2026 00:00:00 GMT Senkron İstek/Yanıt Nerede Tıkanır

Çoğu ürün API'si düz senkron istek/yanıt ile başlar. Login için, bir kullanıcı kaydını okumak için, basit bir arama için çalışır. Sonra bir uç nokta gerçek iş yapmak zorunda kalır.

Altı ila on saniye süren bir ödeme yetkilendirmesini düşünün. Bu kadar uzun bir spinner checkout dönüşümünü düşürür; kullanıcılar butona tekrar basar ve altta bir idempotency katmanı olmadığında backend ikinci bir ücretlendirmeyi kabul eder.

Continue reading...

]]> <![CDATA[Claude Code, Cursor, Copilot, Codex için Tek Yapılandırma]]> https://sph.sh/tr/posts/model-agnostic-ai-coding-setup/ https://sph.sh/tr/posts/model-agnostic-ai-coding-setup/ Sat, 18 Apr 2026 00:00:00 GMT Ekipler nadiren tek bir AI kodlama aracında uzlaşır; yalnızca Claude Code, Codex, Copilot, Cursor ya da OpenCode'dan biriyle çalışan bir repo, farklı bir araç seçen her katkı sağlayıcıyı dışarıda bırakır. Aşağıdaki düzen tek bir dosyayı yetkili kılar: kaynak olarak AGENTS.md, diğer araçların beklediği her dosya adı için symlink ya da @-import, araçlar arası tool katmanı için MCP. Düzen üç yerde kırılır: skill'ler, slash komutları ve Windows symlink tuzakları.

Problem

Continue reading...

]]> <![CDATA[Optimistic UI vs Decoupled Akış: Async Backend'ler için UX Desenleri]]> https://sph.sh/tr/posts/ux-event-based-backends-optimistic-to-decoupled/ https://sph.sh/tr/posts/ux-event-based-backends-optimistic-to-decoupled/ Sat, 18 Apr 2026 00:00:00 GMT Event-based bir backend, işi istek/yanıt döngüsünün dışına taşır: istemci gönderir, sunucu kabul edip kuyruğa alır ve durum değişikliği bir süre sonra gerçekleşir. Spinner, sistemin bu oturum için aktif olarak sonucu ürettiği sinyalini verir; ancak event-based bir akışta client tarafında beklenen bir iş yoktur. UI iki farklı durumu birleştirir (backend işi sıraya aldı vs. backend şu anda sonucu hesaplıyor); oysa bu iki durum kullanıcıya farklı sözler verir.

Backend bir değişikliği kaydettiği an ile frontend'in bunu yansıttığı an arasındaki boşluk mimari olarak kaçınılmazdır. Bu boşluğu spinner ile kapatmak yanlış hamledir: spinner ya durum gelmeden biter (ve kullanıcı "oluşturuldu" yazısının ardından boş bir liste görür) ya da oturumun ötesine sarkar.

Continue reading...

]]> <![CDATA[Idempotency: API'lerde Güvenli Retry için Başlangıç Rehberi]]> https://sph.sh/tr/posts/idempotency-beginners-guide/ https://sph.sh/tr/posts/idempotency-beginners-guide/ Thu, 09 Apr 2026 00:00:00 GMT Idempotency, aynı işlemin defalarca çalıştırılmasının bir kez çalıştırılmasıyla aynı sonucu üretmesi özelliğidir. Para, yan etki ya da dağıtık iş tutan her API için kritiktir. Altta yatan taşıma katmanları (HTTP, mobil şebekeler, mesaj aracıları) başarısızlık durumunda niyetten bağımsız olarak retry yapar ve idempotent olmayan bir endpoint, her retry'ı bir duplicate yazmaya çevirir: çift ücretlendirme, tekrarlanan siparişler, iki kez işlenen işler.

Continue reading...

]]> <![CDATA[Abonelik Uygulamalarında Mobil Reklam Atıfı: SKAN 4 ve AdAttributionKit]]> https://sph.sh/tr/posts/mobile-ad-attribution-subscription-conversion/ https://sph.sh/tr/posts/mobile-ad-attribution-subscription-conversion/ Thu, 09 Apr 2026 00:00:00 GMT Abonelik uygulamalarında attribution, Meta, Google veya TikTok'taki bir reklam tıklamasını veri ambarındaki doğrulanmış bir ücretli abonelik olayına bağlamak zorundadır. Install, o olaya giden yolda yalnızca ara bir sinyaldir; SKAN 4 ile ATT ise click-to-install bağlantısını install-to-subscription bağlantısından çok daha zor gözlemlenir hâle getirir. Tek bir hattın, birbirinden bağımsız saatlerle gelen üç kaynağı (SKAN postback'leri, mobil uygulama olayları, ödeme sağlayıcı makbuzları) uzlaştırması gerekir ki pazarlama, finans ve ürün aynı sayılar üzerinde çalışabilsin.

Continue reading...

]]> <![CDATA[2026'da RevenueCat Alternatifleri: Mobil Uygulamalar için Abonelik Platformu Seçimi]]> https://sph.sh/tr/posts/revenuecat-alternatives-comparison-2026/ https://sph.sh/tr/posts/revenuecat-alternatives-comparison-2026/ Thu, 09 Apr 2026 00:00:00 GMT Mobil abonelik altyapısı katmanlı bir seçimdir: cihaz üstündeki SDK ve entitlement motoru, onun arkasındaki faturalama/katalog/vergi katmanı ve en üstteki paywall, deneyleme ve analitik araçları. İlk katmanda RevenueCat varsayılandır ve diğer iki katmanı da çoğu ekip için yeterince iyi karşılar. Brüt gelir üzerinden alınan %1 MTR ücreti yaklaşık 100 bin dolar MTR'ın üstünde matematiği değiştiriyor ve 2026 pazarında varsayılanı tek bir eksende geçen alternatifler var: paywall deneylemede Adapty, analitik/fiyat oranında Qonversion, win-back akışlarında Apphud, çapraz platform faturalamada Chargebee ve Stripe Billing.

Continue reading...

]]> <![CDATA[Zapier MCP İzin Kontrolü: AI Agent API Erişimi Sınırlama]]> https://sph.sh/tr/posts/zapier-mcp-api-permission-control/ https://sph.sh/tr/posts/zapier-mcp-api-permission-control/ Sun, 05 Apr 2026 00:00:00 GMT Doğrudan MCP sunucu entegrasyonları, AI agent'lara geniş ve çoğu zaman kontrolsüz API erişimi verir. Önceki yazıda en az yetki prensibini uygulamak için kapsamı sınırlı proxy'lerin nasıl yazıldığını göstermiştik. Zapier MCP yönetilen bir alternatif sunuyor: aksiyon bazlı beyaz liste, merkezi kimlik yönetimi ve insan onay mekanizması; hem de tek satır proxy kodu yazmadan.

Bir agent'ı standart işlemlerle üç ya da daha fazla uygulamaya bağlayan ekipler için varsayılan bu yönetilen katman. Elle yazılan bir proxy, bakım maliyetini ancak tek bir entegrasyon derin özelleştirme ya da 100ms altı bir bütçe istediğinde çıkarır.

MCP'de Kontrolsüz API İzinleri

Continue reading...

]]> <![CDATA[Mobil IAP ve Paywall Stratejileri - App Store, Play Store, RevenueCat]]> https://sph.sh/tr/posts/mobile-iap-paywall-strategies/ https://sph.sh/tr/posts/mobile-iap-paywall-strategies/ Thu, 02 Apr 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[Platformlar Arası Abonelik Yetkilendirmesi: Web, iOS ve Android Senkronizasyonu]]> https://sph.sh/tr/posts/omnichannel-entitlement-sync/ https://sph.sh/tr/posts/omnichannel-entitlement-sync/ Thu, 02 Apr 2026 00:00:00 GMT Bir ürün web, iOS ve Android üzerinde abonelik sattığında, her platform kendi şemasında, kendi yaşam döngüsüyle ve kendi teslim gecikmesiyle abonelik olayları yayar. Yetkilendirme senkronizasyon katmanı, bu heterojen olayları "bu kullanıcı şu anda neye erişebilir?" sorusuna tek ve tutarlı bir cevaba dönüştüren parçadır. Platform başına naif bir handler, saatler içinde senkronizasyondan çıkar; asıl sorun webhook tesisatı değil, dağıtık durumun kendisidir.

Continue reading...

]]> <![CDATA[Ödeme Sağlayıcıları ve Uyumluluk: Stripe, Adyen, Chargebee, Paddle, PayPal Karşılaştırması]]> https://sph.sh/tr/posts/payment-providers-comparison-compliance/ https://sph.sh/tr/posts/payment-providers-comparison-compliance/ Thu, 02 Apr 2026 00:00:00 GMT Küresel ödeme kabulünün aynı şekilde davranmayan üç katmanı vardır: işlem işleme, vergi uyumluluğu ve satışın yasal sorumluluğu. Sağlayıcıyı yalnızca işlem ücretine bakarak seçen bir SaaS ekibi, diğer iki katmanı genellikle bir KDV denetimi, bir PSD2/SCA red oranı ya da bir chargeback politikası gün yüzüne çıkardığında fark eder. Asıl karar, ekibin hangi katmanları kendi yönettiği ve hangilerini dışarıya verdiğidir.

Continue reading...

]]> <![CDATA[Abonelik Yaşam Döngüsü Yönetimi: Yükseltmeler, Dunning ve Dolandırıcılık Tespiti]]> https://sph.sh/tr/posts/subscription-lifecycle-management/ https://sph.sh/tr/posts/subscription-lifecycle-management/ Thu, 02 Apr 2026 00:00:00 GMT Abonelik faturalamasında mutlu yol kısadır; asıl uzun olan, sessizce gelir sızdıran uç durumlar kuyruğudur. Özensiz bir proration adımı plan yükseltmelerinde çift ücret keser; varsayılan bir yeniden deneme politikası dunning sırasında kartı boş yere arka arkaya dener; eksik dolandırıcılık sinyalleri sonunda chargeback olarak geri döner. Abonelikler tek bir işlem değildir; birer durum makinesidir ve her faturalama olayı tetiklenebilen, başarısız olabilen veya tekrarlayabilen bir geçiştir.

Continue reading...

]]> <![CDATA[Claude Code Skill'leri ve Bağlam Penceresi Şişmesi: Token Bütçesi Rehberi]]> https://sph.sh/tr/posts/why-copying-claude-code-skills-doesnt-work/ https://sph.sh/tr/posts/why-copying-claude-code-skills-doesnt-work/ Mon, 23 Mar 2026 00:00:00 GMT Claude Code ekosistemi artık 500'den fazla topluluk skill'i, 1.200'den fazla agent skill'i ve düzinelerce MCP sunucu dizini barındırıyor. Birinin "awesome" kurulumunu klonlamak cazip geliyor; yanlış varsayılan da tam olarak bu. Kopyalanan konfigürasyonlar üç sorunu aynı anda büyütür: context window şişmesi gerçek koda yer bırakmaz, araç kalabalığı modelin doğru aracı seçme yeteneğini düşürür ve kopyalanan iş akışları senin kod tabanınla uyuşmaz.

Continue reading...

]]> <![CDATA[SaaS Yetkilendirme için AWS Cognito + Verified Permissions]]> https://sph.sh/tr/posts/cognito-avp-saas-authorization/ https://sph.sh/tr/posts/cognito-avp-saas-authorization/ Sun, 22 Mar 2026 00:00:00 GMT AWS üzerinde B2B SaaS kurarken kimlik doğrulama işin kolay yarısıdır. Cognito kullanıcıyı doğrular ve bir JWT döndürür; ancak geçerli bir token, A kiracısının B kiracısının belgelerini okuyup okuyamayacağı hakkında hiçbir şey söylemez. Bu ikinci soruyu AWS Verified Permissions (AVP) yanıtlar ve başlangıç için makul varsayılan pool modelidir: tek Cognito User Pool, tek AVP policy store ve her Cedar politikasının içine yerleştirilmiş bir kiracı kontrolü.

Ağırlığı üç karar taşır: Pre Token Generation trigger'ının access token'a hangi claim'leri yazacağı, kiracı izolasyonunun Cedar politikasında mı yoksa kiracı başına ayrı altyapıda mı duracağı ve her çağrı yolunun hangi AVP API'sini kullanacağı. Cedar politikalarının şekli, TypeScript entegrasyonu ve aylık fatura bu üç karardan çıka...

Continue reading...

]]> <![CDATA[OpenFGA vs SpiceDB vs Cerbos vs OPA vs AWS Verified Permissions: Hangisini Seçmeli]]> https://sph.sh/tr/posts/external-authorization-management-systems/ https://sph.sh/tr/posts/external-authorization-management-systems/ Sun, 22 Mar 2026 00:00:00 GMT Özel yetkilendirme sistemleri geliştirmek birçok uygulama için işe yarıyor. Dağıtık sistemler ise politika değerlendirme, ilişki yönetimi ve ince taneli erişim kontrolünü servis olarak sunan özel yetkilendirme altyapılarından giderek daha fazla fayda görüyor. Makul bir başlangıç noktası: yetkilendirmeyi tek bir servisin içinde kaldığı sürece gömülü bir kütüphanede tutun, servis sınırını aştığı anda harici bir motora geçin.

Hangi motoru seçeceğiniz baskın modelinize bağlı. AWS üzerinde öznitelik ağırlıklı kararlar için Cedar ve AWS Verified Permissions uygun. Erişim, kullanıcı ile kaynak arasındaki ilişkilerden türüyorsa SpiceDB veya OpenFGA öne çıkıyor. Geri kalanını maliyet, operasyonel yük ve politika dili kilitlenmesi belirliyor.

Continue reading...

]]> <![CDATA[Cedar vs Rego vs OpenFGA: Politika Dili Karşılaştırması]]> https://sph.sh/tr/posts/policy-language-comparison-cedar-rego-openfga/ https://sph.sh/tr/posts/policy-language-comparison-cedar-rego-openfga/ Sun, 22 Mar 2026 00:00:00 GMT Yetkilendirme için seçtiğin politika dili, güvenlik mimarinin geri kalanını şekillendirir: politikaların nasıl yazılacağını, test edileceğini, dağıtılacağını ve denetleneceğini belirler. Sonradan dil değiştirmek hepsini yeniden yazmak demek, bu yüzden seçimi baştan bilinçli yapmakta fayda var.

Continue reading...

]]> <![CDATA[SpiceDB vs Auth0 FGA: İlişki Tabanlı Yetkilendirme Karşılaştırması]]> https://sph.sh/tr/posts/spicedb-vs-auth0-fga/ https://sph.sh/tr/posts/spicedb-vs-auth0-fga/ Sun, 22 Mar 2026 00:00:00 GMT SpiceDB ve Auth0 FGA, Zanzibar tabanlı iki önde gelen yetkilendirme sistemidir. Ancak temelde farklı tercihler yaparlar. SpiceDB, ZedToken'lar aracılığıyla güçlü tutarlılık garantileri sunan gRPC-öncelikli, kendi sunucunuzda barındırılabilen (veya Authzed üzerinden yönetilen) bir motordur. Auth0 FGA ise farklı bir tutarlılık modeli ile OpenFGA üzerine kurulu, REST-öncelikli, tamamen yönetilen bir hizmettir.

Çoğu takım için varsayılan Auth0 FGA'dır; altyapı bütçeniz yoksa kendi sunucunuzda OpenFGA. Bu varsayılanı SpiceDB'ye çeviren iki gereksinim vardır: bir sonraki okumada hemen geçerli olması gereken izin iptali ve kontrolünüzdeki altyapıdan çıkamayacak yetkilendirme verisi. Şema sözdizimi, API ergonomisi ve yayımlanan ölçek tavanları bu ikisinin yanında daha az belirleyicidir.<...

Continue reading...

]]> <![CDATA[Müşteri Geri Bildirimi Nasıl Önceliklendirilir: RICE ve ICE]]> https://sph.sh/tr/posts/customer-feedback-product-value/ https://sph.sh/tr/posts/customer-feedback-product-value/ Thu, 19 Mar 2026 00:00:00 GMT Müşteri geri bildirimi nadiren tertemiz bir problem tanımı olarak gelir. Slack mesajları, destek yanıtları, satış notları, puanlar ve tek cümlelik özellik istekleri olarak gelir. Zor olan toplamak değil. Zor olan, o akışı en yüksek sesin veya en büyük logonun varsayılan olarak yol haritasını çekmesine izin vermeden kararlara dönüştürmektir.

Gerçek bir ekipte ayakta kalan halka kısadır: intake, triage, iş belirsizse keşif, teslimat ve müşteriye kapanan döngü. Her adımın destek SLA’larına, mühendislik kuyruklarına ve panelin gösterdiği kadar temiz olmayan metriklere rağmen çalışması gerekir.

Geri bildirimin yükü

Farklı ekiplerde tekrar eden birkaç örüntü:

Continue reading...

]]> <![CDATA[Kimlik Doğrulama vs Yetkilendirme: Temelleri ve İzin Sistemleri Neden Bozulur]]> https://sph.sh/tr/posts/scalable-permission-systems-101-authorization-fundamentals/ https://sph.sh/tr/posts/scalable-permission-systems-101-authorization-fundamentals/ Sun, 15 Mar 2026 00:00:00 GMT Broken access control, OWASP Top 10'da (2021, 2025 güncellemesinde de doğrulandı) bir numaralı güvenlik açığı. İzin hatalarının çoğunun kökeninde, kontrolleri unutmayı kolay ve tutarlı tutmayı zor kılan bir mimari var. Kod tabanı büyüdükçe, bir kontrolün sessizce eksik kalabileceği yerlerin sayısı da büyüyor.

İlk günden benimsenmeye değer varsayılan, tüm veri erişiminin üzerinden geçtiği izin farkında tek bir katmandır; kontrol tamamlanamadığında erişimi reddeden bir katman. Oraya giden yol, pek çok kod tabanının bulanıklaştırdığı bir ayrımla başlar.

Kimlik Doğrulama ve Yetkilendirme

Bu iki kavram genellikle tek bir "auth" kelimesi altında birleştiriliyor ve bu da karışıklığa yol açıyor. Temelde farklı konulardır.

Continue reading...

]]> <![CDATA[Service Layer ile Merkezi Yetkilendirme]]> https://sph.sh/tr/posts/scalable-permission-systems-102-service-layer-centralization/ https://sph.sh/tr/posts/scalable-permission-systems-102-service-layer-centralization/ Sun, 15 Mar 2026 00:00:00 GMT Post 101'de dağınık izin kontrollerinin kök sorunlarını teşhis ettik: tutarsız mantık, güvenlik açıkları ve bakım yükü. İlk çözüm service layer pattern: tüm yetkilendirme mantığı, uygulama kodunuz ile veritabanı arasındaki tek bir katmana taşınır.

Route koruması için Next.js middleware ve farklı seviyelerdeki guard'lar bu katmanın üzerine eklenir. İkisi birlikte derinlemesine savunma mimarisini oluşturur: izin kuralı tek bir yerde yazılır, veriye giden her yolda uygulanır.

Dağınık Kontrollerin Kök Nedeni

Continue reading...

]]> <![CDATA[RBAC: TypeScript ile Type-Safe Rol Bazlı Erişim Kontrolü]]> https://sph.sh/tr/posts/scalable-permission-systems-103-role-based-access-control/ https://sph.sh/tr/posts/scalable-permission-systems-103-role-based-access-control/ Sun, 15 Mar 2026 00:00:00 GMT Post 102 yetkilendirmeyi service layer'da merkezileştirdi; izin kontrollerinin nerede yapılacağı sorusunu çözdü. Ancak service layer içindeki izin kuralları hala sabit kodlanmış if/else zincirleri: if (session.role === 'admin') return true. Yeni bir rol eklemek, her servis dosyasındaki her yardımcı fonksiyonu değiştirmek anlamına geliyor.

O zincirlerin yerini RBAC (Rol Bazlı Erişim Kontrolü) alıyor. Modeli Ferraiolo ve Kuhn 1992'de biçimlendirdi, NIST ise INCITS 359-2004 olarak standartlaştırdı. Tek bir type-safe can() fonksiyonu sabit kodlanmış kontrollerin tamamını devralıyor. Hem sunucu hem istemci tarafında çalışıyor ve Post 102'nin açık bıraktığı izin mantığı tekrarını kapatıyor.

RBAC Nedir?

NIST Modeli

Continue reading...

]]> <![CDATA[TypeScript'te Attribute-Based Access Control (ABAC): Policy Engine Oluşturma]]> https://sph.sh/tr/posts/scalable-permission-systems-104-attribute-based-access-control/ https://sph.sh/tr/posts/scalable-permission-systems-104-attribute-based-access-control/ Sun, 15 Mar 2026 00:00:00 GMT Post 103 type-safe RBAC'ı can(role, resource, action) fonksiyonu ve deklaratif bir izin matrisi ile oluşturdu. Yeni bir rol eklemek tek satırlık bir değişiklik olarak kalıyor, sunucu ve istemci de tek bir doğruluk kaynağını paylaşıyor. Ancak bağlamsal kararlar (sahiplik, departman kapsamı, belge durumu) bu matrisin dışında özel yardımcı fonksiyonlar olarak kalıyor. canModifyDocument, canEditInDepartment ve canPublishInReviewStatus can() fonksiyonunun yanında çoğalıyor; her biri tip sisteminin doğrulayamadığı bir if/else zinciri.

Continue reading...

]]> <![CDATA[İleri ABAC: Field-Level İzinler ve Veritabanı Entegrasyonu]]> https://sph.sh/tr/posts/scalable-permission-systems-105-advanced-abac-field-level-db/ https://sph.sh/tr/posts/scalable-permission-systems-105-advanced-abac-field-level-db/ Sun, 15 Mar 2026 00:00:00 GMT Post 104 builder pattern ile type-safe bir ABAC policy engine oluşturdu. can(user, action, resource, data?) fonksiyonu özne, kaynak ve eylem niteliklerini deklaratif koşullar aracılığıyla değerlendiriyor. Sahiplik, departman kapsamı ve kaynak durumu artık policy kuralı; dağınık yardımcı fonksiyonlar ortadan kalktı. Geriye iki boşluk kalıyor ve ikisi de aynı builder genişletilerek kapanıyor; etrafına yeni bir kontrol katmanı eklemek gerekmiyor.

Continue reading...

]]> <![CDATA[TypeScript'te Multi-Tenant Yetkilendirme: CASL vs Özel ABAC]]> https://sph.sh/tr/posts/scalable-permission-systems-106-multi-tenancy-libraries-decisions/ https://sph.sh/tr/posts/scalable-permission-systems-106-multi-tenancy-libraries-decisions/ Sun, 15 Mar 2026 00:00:00 GMT Post 101 bir izin sistemi için yedi hedef belirledi ve dağınık kontrol anti-pattern'ini ortaya koydu. Post 102 yetkilendirmeyi bir service layer içinde merkezileştirdi. Post 103 type-safe RBAC ekledi. Post 104 rol-izin matrisini ABAC policy engine ile değiştirdi. Post 105 ABAC'ı çevre koşulları, alan düzeyinde okuma/yazma izinleri ve veritabanı sorgu filtreleme ile genişletti.

Continue reading...

]]> <![CDATA[MCP vs Doğrudan API Erişimi: MCP Katmanını Ne Zaman Atlamalı]]> https://sph.sh/tr/posts/skip-mcp-layer-scoped-api-access/ https://sph.sh/tr/posts/skip-mcp-layer-scoped-api-access/ Thu, 12 Mar 2026 00:00:00 GMT Atlassian'ın Rovo MCP Server'ı yapay zeka agentlerini birkaç dakikada Jira ve Confluence'a bağlıyor; karşılığında kimlik doğrulayan kullanıcının görebildiği her şeyi agente açıyor. Onlarca proje ve alanın bulunduğu bir organizasyonda bunun anlamı şu: sunucu tarafında proje kapsamı kısıtlaması yok, araç şemaları iş başlamadan context window'u tüketiyor ve Jira, Confluence ile Compass işlemleri ya hep ya hiç açılıyor.

Continue reading...

]]> <![CDATA[AWS Control Tower Çoklu Hesap Stratejisi: Landing Zone'dan Kurumsal Governance'a]]> https://sph.sh/tr/posts/aws-control-tower-multi-account-strategy/ https://sph.sh/tr/posts/aws-control-tower-multi-account-strategy/ Fri, 06 Mar 2026 00:00:00 GMT AWS Control Tower, iyi governance'a sahip bir çoklu hesap AWS ortamının temelini oluşturur. Kolay kısım kurulum sihirbazı; asıl kararlar sonrasında başlar. Landing zone ayağa kalktığında OU ağacının şekli, koruma mekanizmalarının hangi sırayla açılacağı, hesap sağlama ve hesaplar arası erişim hâlâ açık sorulardır.

Çoğu organizasyonda şu dört varsayılan geçerlidir: OU sınırlarını politika sınırlarıyla hizala, preventive kontrollerden önce detective kontrolleri aç, merkezi loglamayı ilk günden kur ve Account Factory for Terraform'a yalnızca takım zaten Terraform kullanıyorsa yönel. Devamı, bu varsayılanların arkasındaki trade-off'lar ve onlardan sapmayı haklı çıkaran koşullarla ilgili.

Çoklu Hesap Stratejisinin Önemi

Continue reading...

]]> <![CDATA[Maaş mı, Etki mi, Tatmin mi? Her Mühendisin Yüzleştiği Meslek Sorusu]]> https://sph.sh/tr/posts/salary-impact-satisfaction-vocation/ https://sph.sh/tr/posts/salary-impact-satisfaction-vocation/ Wed, 04 Mar 2026 00:00:00 GMT Maaş-etki-tatmin tartışması mühendislik kariyer forumlarının değişmez gündem maddesi ve karışıklık tam da bu çerçevelemeden çıkıyor. Maaş, etki ve tatmin, mesleki gelişimin üç ayrı aşamasında öne çıkan ihtiyacı tarif ediyor. Bunları rakip öncelikler gibi ele almak, bir sıralama sorusunu sadakat testine çeviriyor; ardından gelen kararlar da hedefi ıskalıyor.

Örgütsel psikoloji bu aşamaları çoktan haritalamış durumda. Wrzesniewski'nin iş yönelimi araştırması, Öz-Belirleme Teorisi ve Dan Koe'nun Vocation (Meslek) kadranı aynı üç adımlı ilerlemede buluşuyor. Hangi adımda olduğunuzu bilmek, şu an hangi boyutun ilgiyi hak ettiğini ve hangisinin bekleyebileceğini söylüyor.

Birbirini Duymayan Taraflar

Continue reading...

]]> <![CDATA[Organizasyon Düzeyinde Yeniden Kullanılabilir GitHub Actions Workflow'ları: Mimari, Güvenlik ve Benimseme]]> https://sph.sh/tr/posts/github-actions-platform-scale/ https://sph.sh/tr/posts/github-actions-platform-scale/ Sun, 01 Mar 2026 00:00:00 GMT GitHub Actions ile başlamak aldatıcı derecede basittir. Bir YAML dosyası kopyalarsınız, birkaç adım eklersiniz ve pipeline çalışır. Bu basitlik, farklı ekiplerin sahiplendiği düzinelerce repository kendi build, test ve deploy biçimini taşımaya başladığında ölçeklenmez. Sonuç orta ve büyük ölçekli mühendislik organizasyonlarında tanıdıktır: ince farklılıklar içeren yüzlerce workflow dosyası, tutarsız güvenlik uygulamaları, büyük farklılıklar gösteren build süreleri ve platform mühendislerinin platform yeteneği geliştirmek yerine "GitHub Actions'da X'i nasıl yaparım?" sorularını yanıtladığı bir destek kuyruğu.

Continue reading...

]]> <![CDATA[React Native Expo ile Sentry Entegrasyonu: Pratik Hızlı Rehber]]> https://sph.sh/tr/posts/sentry-react-native-expo-setup/ https://sph.sh/tr/posts/sentry-react-native-expo-setup/ Mon, 16 Feb 2026 00:00:00 GMT Sentry'nin kurulum wizard'ı bir React Native Expo projesini tek komutla hazırlar; çoğu uygulama için wizard ve bir development build yeterlidir. Saat kaybettiren kısımlar sonrasında başlar: Expo Go native crash'leri ve session replay'i sessizce devre dışı bırakır, EAS Update source map'leri kendiliğinden yüklemez ve app.json içinde unutulan bir auth token uygulamayı kuran her cihaza gider.

Aşağıdaki yapılandırma Expo SDK 50 ve üzeri ile @sentry/react-native paketini varsayar. Eski sentry-expo paketi SDK 50 ile birlikte kullanımdan kaldırıldı; yeni projelerde tercih edilmemeli.

Ön Koşullar

Başlamadan önce şunlara ihtiyacın var:

Continue reading...

]]> <![CDATA[DevRel Nedir? Developer Relations Rolü, Beceriler ve Kariyer Yolu]]> https://sph.sh/tr/posts/devrel-role-analysis/ https://sph.sh/tr/posts/devrel-role-analysis/ Wed, 04 Feb 2026 00:00:00 GMT Developer Relations (DevRel) sıklıkla "geliştiriciler için marketing" veya "konferanslarda konuşup seyahat ederek para kazanma" olarak yanlış anlaşılıyor. Bu okuma stratejik değeri gözden kaçırıyor. DevRel, geliştiricilerin gerçek deneyimini sistematik olarak toplar ve ürün geliştirmeye geri aktarır. Aynı zamanda geliştirici eğitimini tek bir dokümantasyon ekibinin yetişemeyeceği ölçeğe taşır. Geri kalan her şey bu tanımdan çıkar: kimin bu rolde başarılı olduğu ve şirketin bu işe ne zaman bütçe ayırması gerektiği.

Continue reading...

]]> <![CDATA[DynamoDB Throttling: Hot Partition Çözümleri, Write Sharding ve Retry Stratejileri]]> https://sph.sh/tr/posts/dynamodb-rate-limit-strategies/ https://sph.sh/tr/posts/dynamodb-rate-limit-strategies/ Wed, 28 Jan 2026 00:00:00 GMT DynamoDB'yi ölçekte kullanırken throttling kaçınılmaz bir sorun haline geliyor. ProvisionedThroughputExceededException hatası, tablo seviyesinde yeterli kapasite olmasına rağmen sıkça karşılaşılıyor; çünkü DynamoDB kapasiteyi her partition için ayrı ayrı uyguluyor.

En çok fark yaratan kaldıraç partition key tasarımı. Write sharding, kapasite modları, DAX ve retry mantığı bu seçimin üzerine ek pay kazandırıyor. Single Table Design'da pratik sıra şöyle: önce yüksek kardinaliteli key'ler, yüksek kardinalite kurulamayan erişim pattern'leri için sharding, sonra geriye kalanın etrafına retry ve monitoring.

DynamoDB'nin Throttling Mekanizmasını Anlamak

Continue reading...

]]> <![CDATA[MCP Sunucu RBAC, Araç Bileşimi ve Çoklu Ajan İş Akışı Kalıpları]]> https://sph.sh/tr/posts/mcp-advanced-patterns-workflows-rbac/ https://sph.sh/tr/posts/mcp-advanced-patterns-workflows-rbac/ Thu, 22 Jan 2026 00:00:00 GMT MCP içeriklerinin çoğu ilk çalışan sunucuda duruyor: birkaç araç kaydet, bir istemci bağla, bitti. Asıl sorunlar sonra başlıyor; aynı sunucuya ikinci bir ekip bağlandığında ve kayıtlı araçlardan biri production'ı değiştirebildiğinde.

Bu boşluğu altı kalıp kapatıyor: araç anotasyonları, iş akışı orkestrasyonu, öznitelik koşullu RBAC, kademeli yetkilendirme, hata kurtarma ve gözlemlenebilirlik. Sadece birini seçecekseniz, denetim loglamayla desteklenmiş RBAC'ı seçin. İzinler ve denetim izleri, ajanlar araçları çağırmaya başladıktan sonra eklenmesi en pahalı katman; orkestrasyon ise karşılaştıracak iki iş akışınız olana kadar bekleyebilir.

Ölçeklenirken Çıkan Sorunlar

Continue reading...

]]> <![CDATA[RAG Veri Hazırlama: Yapay Zeka Sisteminin Başarısını Belirleyen Temel]]> https://sph.sh/tr/posts/rag-data-preparation/ https://sph.sh/tr/posts/rag-data-preparation/ Thu, 22 Jan 2026 00:00:00 GMT Çoğu RAG implementasyon başarısızlığı retrieval mimarisine değil, veri hazırlamaya dayanıyor. Ekipler retrieval parametrelerini haftalarca ayarlarken asıl problem kötü parse edilmiş dokümanlar veya uygunsuz chunking oluyor. Doğrulanmış parsing ve 512 token civarı recursive splitting, başlanacak varsayılan; semantik ve parent-child chunking ek maliyetini ancak ölçümler gösterdiğinde hak ediyor.

RAG Pipeline'ının Kalite Tavanı

RAG implementasyonlarında yaygın bir pattern var: sofistike retrieval mimarileri (hybrid search, reranking, CRAG) hala kötü sonuçlar üretiyor. Kök neden neredeyse her zaman veri hazırlama katmanında.

[code block]

Continue reading...

]]> <![CDATA[Forward Deployed Engineer Nedir? FDE, Solutions Architect ve TAM Karşılaştırması]]> https://sph.sh/tr/posts/forward-deployed-engineer-role-analysis/ https://sph.sh/tr/posts/forward-deployed-engineer-role-analysis/ Mon, 19 Jan 2026 00:00:00 GMT Forward Deployed Engineer (FDE), müşterinin altyapısında production kodu yazar ve o kod çalışana kadar sahada kalır. Sınır tam olarak burada: Solutions Architect, Solutions Engineer ve Technical Account Manager implementasyonu müşteriye devreder, FDE devretmez. FDE deployment'ı production'a kadar üstlendiği için rolün ücret bandı da tükenmişlik riski de komşu unvanlardakinden farklı seyrediyor.

Talep kurumsal AI ile birlikte arttı; çünkü bir AI sistemi işe yarar çıktı üretmeden önce müşteri bağlamına (tarihsel veri, iş akışları, iş kuralları) ihtiyaç duyar ve demo ortamı bu bağlamı sağlayamaz. Modelin bedeli açık: FDE ağırlıklı bir organizasyon derin entegrasyonu brüt marjdan feragat ederek satın alır ve bu takas yalnızca ürün kategorisi henüz yeniyken karşılığını verir.

Continue reading...

]]> <![CDATA[TypeScript AI SDK Karşılaştırması: Agent Geliştirme için Vercel AI SDK vs OpenAI Agents SDK]]> https://sph.sh/tr/posts/typescript-ai-sdk-agent-tooling/ https://sph.sh/tr/posts/typescript-ai-sdk-agent-tooling/ Mon, 19 Jan 2026 00:00:00 GMT TypeScript'te AI agent geliştirmeye başlarken ilk karar sıkıcı olanı: tool çağrılarını, streamingi ve provider kimlik bilgilerini hangi SDK taşıyacak. Üç cevap öne çıkıyor ve her biri farklı bir şeyi optimize ediyor. Vercel AI SDK, providera özgü yüzeyi taşınabilirlik karşılığında bırakıyor; OpenAI Agents SDK multi-agent orkestrasyonunu çalışma zamanına gömüyor; direkt provider SDK'leri ise her ayarı açıkta bırakıyor.

Çoğu TypeScript ve Next.js kod tabanında varsayılan Vercel AI SDK. Asıl soru bu varsayılanın nerede yetersiz kaldığı: yoğun multi-agent orkestrasyonu ve hiçbir soyutlamanın henüz açmadığı bir özelliğe ihtiyaç duyan tek providerlı servisler.

TypeScript AI SDK Ekosistemi

Üçü de soyutlamayı farklı bir seviyeye yerleştiriyor:

Continue reading...

]]> <![CDATA[RAG mi, Fine-Tuning mi, Hazır AI mi? Kurumsal Karar Rehberi]]> https://sph.sh/tr/posts/ai-integration-levels-enterprise-guide/ https://sph.sh/tr/posts/ai-integration-levels-enterprise-guide/ Sat, 17 Jan 2026 00:00:00 GMT Kurumsal AI benimseme süreci tahmin edilebilir bir patern izler: ekipler basit alternatifleri doğrulamadan sofistike mimarilere yönelir. L1'deki doğrudan sohbetten L6'daki fine-tuning'e uzanan altı seviyeli bir merdiven, bu seçenekleri arkalarındaki iş ihtiyacıyla karşılaştırmayı kolaylaştırır. Varsayılan, çoğu yol haritasının sandığından daha aşağıdadır. L2, yani yüklü bilgi dosyalarıyla bir sistem prompt'u, hak ettiğinden fazla dahili senaryoyu çözer; yukarı ancak ölçülmüş bir kısıtlama seni zorladığında çıkarsın.

Continue reading...

]]> <![CDATA[AI/LLM Sözlüğü: Her Geliştiricinin Bilmesi Gereken 82 Terim]]> https://sph.sh/tr/posts/ai-llm-glossary-developer-terms/ https://sph.sh/tr/posts/ai-llm-glossary-developer-terms/ Sat, 17 Jan 2026 00:00:00 GMT AI terminolojisi çoğu dokümantasyonun takip edemeyeceği kadar hızlı gelişiyor. Her hafta yeni terimler ortaya çıkıyor - RAG, RLHF, LoRA, MCP, GGUF - ve genellikle farklı kaynaklar arasında tutarsız tanımlarla. Boşluk pratikte açılıyor. Vendor materyalleri kavramları birbirine karıştırıyor; bir terimin ne anlama geldiğini bilmek de onu ne zaman kullanacağını nadiren söylüyor.

Her madde tanımı implementation bağlamıyla birlikte veriyor: kavramın pratikte neye mal olduğu, en sık nerede yanlış anlaşıldığı ve ne zaman başka bir yola sapmak gerektiği. Bir PM'e embedding'i anlatmakla, knowledge base'i embed etmenin doğru karar olup olmadığını bilmek arasındaki farkı da bu bağlam yaratıyor.

LLM Temelleri

LLM (Large Language Model)

Continue reading...

]]> <![CDATA[TypeScript Formatlama ve Linting Araçları Karşılaştırması: Biome, Oxlint, ESLint ve Prettier]]> https://sph.sh/tr/posts/compare-typescript-formatting-linting-tools/ https://sph.sh/tr/posts/compare-typescript-formatting-linting-tools/ Tue, 13 Jan 2026 00:00:00 GMT TypeScript araç ekosistemi, Rust tabanlı alternatiflerin sahneye çıkmasıyla değişti. Yeni bir projede makul varsayılan Biome: tek binary linting, formatlama ve import düzenlemeyi birlikte çözüyor ve ESLint + Prettier'a göre 15-25x daha hızlı çalışıyor. Çalışan bir ESLint kurulumu olan mevcut kod tabanlarında ilk adım, ESLint'in yanına Oxlint eklemek; güvendiğiniz konfigürasyona dokunmadan ölçülebilir bir hız kazancı sağlıyor.

Bu varsayılanın bir sınırı var. Rust tabanlı araçlar hız kazanırken ekosistem genişliğinden ve type-aware kural kapsamından ödün veriyor: Biome'un Biotype'ı typescript-eslint kurallarının yaklaşık %75-85'ini kapsıyor, Oxlint'in tsgolint'i ise 43 kural sunuyor. Bu boşlukların önem taşıdığı yerlerde doğru cevap hâlâ ESLint + Prettier.

Continue reading...

]]> <![CDATA[Beklenti Uçurumu: İşe Alım Vaatleri İşyeri Gerçekliğiyle Karşılaştığında]]> https://sph.sh/tr/posts/hiring-expectations-workplace-power-dynamics/ https://sph.sh/tr/posts/hiring-expectations-workplace-power-dynamics/ Fri, 09 Jan 2026 00:00:00 GMT İşverenlerin işe alım sürecinde vaat ettikleri ile çalışanların işe başladıktan sonra yaşadıkları çoğu zaman keskin biçimde ayrışıyor; anket verileri bu farkın yaygın olduğunu gösteriyor. Maliyet iki tarafa da yansıyor: çalışan tarafında erken istifa, bağlılık kaybı ve beceri körelmesi; şirket tarafında yeniden işe alım gideri ve zarar gören işveren markası.

Bu farkı kapatan disiplin her iki taraf için de aynı. Vaatleri teklif imzalanmadan önce yazıya dökün, işe başladıktan sonra da uyumu sabit aralıklarla kontrol edin; iki adım da karşı tarafın iyi niyetine bağlı değil.

Sorunun Boyutu

Continue reading...

]]> <![CDATA[Satın Alma Sonrası Kültürel Entegrasyon: Birleşmeler Neden Başarısız Olur]]> https://sph.sh/tr/posts/post-acquisition-cultural-erosion/ https://sph.sh/tr/posts/post-acquisition-cultural-erosion/ Wed, 07 Jan 2026 00:00:00 GMT Satın alma sonrası kültürel erozyon, anlaşma kapandıktan sonra satın alınan şirketin ayırt edici yeteneklerinin, insan kaynağının ve karar kalıplarının kademeli olarak kaybolmasıdır. Gerçekleşmeyen M&A değerinin en büyük tek kaynağıdır ve pazar, ürün ya da finansal nedenlerden çok kültürel uyumsuzluğa dayanır. Kültürel erozyon rastgele bir kayma değil; etnosentrik liderlik, iç-grup ve dış-grup dinamikleri ve karar otoritesini satın alan tarafın mevcut normlarına akıtan bilinçsiz önyargı tarafından yürütülen sistematik bir süreçtir.

Continue reading...

]]> <![CDATA[AWS Lambda'da Bun ve Alternatif JavaScript Runtime'ları Çalıştırma]]> https://sph.sh/tr/posts/bun-on-lambda-custom-runtimes/ https://sph.sh/tr/posts/bun-on-lambda-custom-runtimes/ Fri, 26 Dec 2025 00:00:00 GMT AWS Lambda resmi olarak Node.js'i destekliyor, ancak platformun custom runtime özelliği Bun ve Deno gibi alternatif JavaScript runtime'larına kapı açıyor. Bunu iki mekanizma mümkün kılıyor: Lambda Layer'ları ve container image'ları. İkisi de AWS'nin kendi yönetilen runtime'larına uyguladığı initialization ayarlarından vazgeçiyor ve bedeli cold start'ta ödeniyor.

Çoğu Lambda workload'ı için doğru varsayılan hâlâ yönetilen Node.js runtime'ı. Alternatif bir runtime'ın yerini hak etmesi için ölçülmüş bir kısıt gerekiyor; o noktada da cache'i önceden ısıtılmış Deno container image'ı iki yoldan daha öngörülebilir olanı.

Custom Runtime Sorusu

Continue reading...

]]> <![CDATA[Production Sistemleri için Prompt Engineering: Sistematik Bir Mühendislik Yaklaşımı]]> https://sph.sh/tr/posts/prompt-engineering-production/ https://sph.sh/tr/posts/prompt-engineering-production/ Fri, 26 Dec 2025 00:00:00 GMT Notebook'ta düzgün çalışan bir prompt, production'da genellikle aynı şekilde davranmıyor. Aynı template yük altında sapıyor, meraklı bir kullanıcıya system instruction'larını sızdırıyor ve token faturasını sessizce katlıyor. Bunların hiçbiri daha iyi cümle kurarak çözülmüyor. Güvenilir varsayılan, prompt'u sürümlenen bir altyapı parçası gibi ele almak: açık yapı, metadata'sıyla saklanan bir sürüm, her çağrıda tracing, girdi ve çıktıda katmanlı kontroller ve bir token bütçesi.

Bu varsayılandan beş karar çıkıyor: user data'yı veri olarak işaretleyip instruction'lardan ayıran bir prompt yapısı, değişikliklerin sürümlenmesi ve kademeli yayını, neyin trace edileceği, injection'a karşı savunma ve maliyetin gerçekte nereye gittiği.

Continue reading...

]]> <![CDATA[JavaScript'te SOLID Prensipleri: TypeScript ve React ile Pratik Rehber]]> https://sph.sh/tr/posts/solid-principles-javascript/ https://sph.sh/tr/posts/solid-principles-javascript/ Fri, 26 Dec 2025 00:00:00 GMT SOLID prensipleri object-oriented programming için formüle edilmişti, ama modern JavaScript geliştirme farklı görünüyor: functional pattern'ler, React hooks, dynamic typing. Prensipler hâlâ geçerli, tek bir adaptasyonla. Her prensibi class hierarchy'ye değil bir composition sınırına (function, modül, hook, component'in prop listesi) bağlayın; beşi de bu geçişten sağ çıkıyor.

Continue reading...

]]> <![CDATA[AWS ile Edge Computing: CloudFront Functions vs Lambda@Edge]]> https://sph.sh/tr/posts/edge-computing-aws/ https://sph.sh/tr/posts/edge-computing-aws/ Thu, 25 Dec 2025 00:00:00 GMT Edge computing, kod yürütmeyi merkezi data center'lardan kullanıcılara yakın konumlara taşıyor. AWS CloudFront dünya çapında geniş bir edge ağı işletiyor ve bu ağa kod yerleştirmek için iki yol sunuyor: CloudFront Functions ve Lambda@Edge. Varsayılan tercih CloudFront Functions olmalı: header işleri, redirect'ler ve cache key normalizasyonu burada çok daha düşük maliyetle çözülüyor. Lambda@Edge ise ancak request network erişimi, request body veya origin tarafındaki event'ler gerektirdiğinde bu maliyeti hak ediyor.

Edge Kodunun Çalıştığı Noktalar

Her iki servis de request'i origin yerine edge'de karşılayarak latency'yi düşürüyor, ancak request yaşam döngüsünde farklı noktalarda duruyor ve farklı sınırlar taşıyorlar.

Continue reading...

]]> <![CDATA[Amazon Cognito Derinlemesine: Temel Authentication'ın Ötesinde]]> https://sph.sh/tr/posts/cognito-deep-dive/ https://sph.sh/tr/posts/cognito-deep-dive/ Wed, 24 Dec 2025 00:00:00 GMT Amazon Cognito, sign-up ve sign-in tarafını çok az konfigürasyonla karşılıyor. Production sistemleri ise daha fazlasını istiyor: token'ın içinde taşınan tenant context, kurumsal SSO, mevcut bir sağlayıcıdan çıkış yolu ve AWS'nin region'lar arası kopyalamadığı bir dizin için yedekleme planı.

Continue reading...

]]> <![CDATA[Effect Öğrenmek: TypeScript Geliştiricileri için Pratik Bir Rehber]]> https://sph.sh/tr/posts/learning-effect-adoption-guide/ https://sph.sh/tr/posts/learning-effect-adoption-guide/ Tue, 23 Dec 2025 00:00:00 GMT Effect, TypeScript'e fonksiyonel bir effect sistemi getiriyor: typed error'lar, dependency injection ve structured concurrency, hepsini compiler zorunlu tutuyor. Ekosistem zengin ama öğrenme eğrisi dik. Dokümantasyon Discord tartışmalarına, GitHub issue'larına ve farklı tarihlerden blog yazılarına dağılmış durumda; "Hello World"den production'daki bir Lambda'nın arkasına koyacağın koda giden yol bu yüzden belirgin değil.

Continue reading...

]]> <![CDATA[AWS Secrets Manager & Parameter Store: Güvenlik Best Practices]]> https://sph.sh/tr/posts/secrets-manager/ https://sph.sh/tr/posts/secrets-manager/ Tue, 23 Dec 2025 00:00:00 GMT AWS'de çalışan mühendisler sık sık aynı dilemmayla karşılaşır: secrets management için Secrets Manager mi yoksa Parameter Store mu kullanmalı? Her iki servis de sensitive data saklıyor ama farklı amaçlara hizmet ediyorlar ve farklı maliyet yapıları var. Kısa kural: statik config → Parameter Store; RDS şifreleri ve rotate etmesi gereken her şey → Secrets Manager. Bundan sonrası maliyete, cross-account erişime ve workload'ların secret'ı runtime'da nasıl okuduğuna bağlı.

İki Servisin Farkları

İki servisi üç eksen ayırıyor: maliyet, rotation desteği ve native entegrasyonlar. Dördüncüsü cross-account paylaşım. Orada Secrets Manager resource policy'leri daha esnek, Parameter Store için ise RAM (Resource Access Manager) kullanman gerekiyor.

Continue reading...

]]> <![CDATA[API Versioning Stratejileri: İlk Release'den Sunset'a Kadar]]> https://sph.sh/tr/posts/api-versioning/ https://sph.sh/tr/posts/api-versioning/ Mon, 22 Dec 2025 00:00:00 GMT API versioning bir URL kuralı değil, bir sözleşme yönetimi problemidir. Bir sürüm, belirli bir istemci kümesine belirli bir kırıcı değişiklik kümesi hakkında verilen sözdür. Bu sözün arkasındaki strateji (URL yolu, header, content negotiation ya da sürümlenmiş kaynak grafı) her istemci migrasyonunun maliyetini, kullanımdan kaldırılan yüzeyin ne kadar süre deploy'da kalacağını ve geçiş boyunca altyapının ne kadar ikiye katlanacağını belirler. Çoğu versioning yeniden yazımı, ekibin sözleşmeyi örtük olarak ilettiğini fark ettiği anda başlar; asıl iş, o sözleşmeyi açık hale getirmektir.

Continue reading...

]]> <![CDATA[LaunchDarkly vs Unleash vs AWS AppConfig: Feature Flag Karşılaştırması]]> https://sph.sh/tr/posts/feature-flags-scale/ https://sph.sh/tr/posts/feature-flags-scale/ Sun, 21 Dec 2025 00:00:00 GMT Feature flag'ler, kodu production'a deploy ederken feature görünürlüğünü runtime'da kontrol etmeni sağlar. Bu kontrol olmadan, distributed bir sistemde feature deploy etmek iki kötü seçeneğe sıkıştırır: kesinti riski taşıyan big-bang release'ler ya da merge conflict biriktiren uzun ömürlü branch'ler. Her deployment, iş takvimine bağlanmış bir ya hep ya hiç olayına dönüşür.

Continue reading...

]]> <![CDATA[Playwright vs Cypress: Modern Web Uygulamaları için E2E Test Stratejileri]]> https://sph.sh/tr/posts/e2e-testing-strategies/ https://sph.sh/tr/posts/e2e-testing-strategies/ Sat, 20 Dec 2025 00:00:00 GMT E2E suite'ler her framework'te aynı birkaç sebeple çöküyor: testler arasında paylaşılan state, markup'a bağlanmış selector'ler ve gerçek bir koşulun yerine konan sabit bekleme süreleri. Framework debug deneyimini belirliyor. Mimari ise suite'in altı ay ve bir arayüz yenilemesi sonrasında hâlâ çalışıp çalışmayacağını belirliyor.

Continue reading...

]]> <![CDATA[Caching Stratejileri: Yerel Bellekten Distributed Sistemlere]]> https://sph.sh/tr/posts/caching-strategies/ https://sph.sh/tr/posts/caching-strategies/ Fri, 19 Dec 2025 00:00:00 GMT Etkili caching çok katmanlı bir problemdir. En hızlı katman süreç içi bir LRU, sonraki uzaktaki bir cache (Redis ya da Memcached), onun üstünde edge'de bir CDN. Her katmanın kendi geçersiz kılma semantiği, tutarlılık garantisi ve hata biçimi vardır. %15 hit rate'e sahip bir Redis cluster'ı genelde yanlış araç seçiminden çok, yanlış katmanda yapılan yanlış işi gösterir. Popüler bir anahtar expire olduğunda oluşan thundering herd ise bir sürü-koruma (stampede) problemidir ve tek katmanlı her cache bunu yaşar.

Continue reading...

]]> <![CDATA[AWS Maliyet Optimizasyonu Araç Seti - Production Workload'lar için Pratik Stratejiler]]> https://sph.sh/tr/posts/aws-cost-optimization/ https://sph.sh/tr/posts/aws-cost-optimization/ Thu, 18 Dec 2025 00:00:00 GMT AWS maliyet çalışmasının bir varsayılan sırası var: önce görünürlük, sonra right-sizing, en son commitment. Cost Explorer ve Budgets paranın nereye gittiğini gösterir, Compute Optimizer kimsenin kullanmadığı kapasiteyi işaretler, Savings Plans veya Reserved Instances de bu iki adımdan geriye kalanı indirime bağlar. Sırayı ters çeviren ekipler, aslında silmeleri gereken kapasiteyi indirimli fiyattan satın almış olur.

Ekipleri bu işe iten belirtiler production hesaplarında birbirine benziyor: trafikte karşılığı olmadan oynayan aylık faturalar, yalnızca mesai saatlerinde gerekirken 7/24 açık duran development kaynakları ve CPU'su boşta dururken tam kapasite faturalanan instance'lar.

Tekrar Eden Beş Maliyet Sürücüsü

Continue reading...

]]> <![CDATA[Mozilla SOPS: GitOps için Git'te Secret Şifreleme]]> https://sph.sh/tr/posts/mozilla-sops-gitops-secrets/ https://sph.sh/tr/posts/mozilla-sops-gitops-secrets/ Thu, 18 Dec 2025 00:00:00 GMT Mozilla SOPS (Secrets OPerationS), her GitOps kurulumunun karşılaştığı tek bir soruya cevap veriyor: secret'ları yayınlamadan version control'de nasıl tutarsın? SOPS, YAML ve JSON dosyalarındaki value'ları şifreliyor, key'leri okunur bırakıyor; böylece dosya yapısı code review'da ayakta kalırken password'ler ve API key'leri ciphertext olarak duruyor. Secret'lar da onları okuyan kodla aynı pull request'ten geçiyor.

Continue reading...

]]> <![CDATA[Transactional Outbox Pattern: Dağıtık Sistemlerde Güvenilir Event Publishing]]> https://sph.sh/tr/posts/outbox-pattern/ https://sph.sh/tr/posts/outbox-pattern/ Tue, 16 Dec 2025 00:00:00 GMT Her event-driven servis er ya da geç aynı anda iki şey yapmak zorunda kalıyor: kendi state'ini değiştirmek ve bunu sistemin geri kalanına duyurmak. Distributed transaction olmadan database write'ı ile broker publish'i atomik hale getirilemiyor; biri başarısız olurken diğeri başarılı olabiliyor. Geriye ya stoğu rezerve edilmemiş bir sipariş kalıyor ya da var olmayan bir sipariş için rezerve edilmiş stok.

Continue reading...

]]> <![CDATA[Tech Şirketlerinde Kariyer Seviyeleri - Entry'den Distinguished Engineer'a]]> https://sph.sh/tr/posts/career-levels-tech-companies/ https://sph.sh/tr/posts/career-levels-tech-companies/ Mon, 15 Dec 2025 00:00:00 GMT Kariyer seviyesi sistemleri şirketten şirkete o kadar farklı ki unvanlar karşılaştırılabilir olmaktan çıkıyor. Amazon'da Senior L6, Google'da Senior L5; 40 kişilik bir startup'taki Staff unvanı da Meta'daki Staff'ın taşıdığı scope'u nadiren taşıyor. Güvenilir karşılaştırma birimi scope, özerklik ve impact; numara ve etiket yalnızca her şirketin sonucu kaydetme biçimi. Eşdeğer seviyeni yanlış okumanın bir bedeli var: yeni bir rolde daha düşük bir banda razı olursun ya da bir yılı yanlış işin terfi dosyasını hazırlamakla geçirirsin.

Continue reading...

]]> <![CDATA[RAG Mimari Desenleri: Temel Vector Search'ün Ötesinde]]> https://sph.sh/tr/posts/rag-architecture-patterns/ https://sph.sh/tr/posts/rag-architecture-patterns/ Mon, 15 Dec 2025 00:00:00 GMT Retrieval-Augmented Generation (RAG) sistemleri genellikle düz vector similarity search ile başlar. Bu taban çizgisi üç noktada tıkanır: exact keyword eşleşmeleri, cevabı birkaç dökümana yayılan sorular ve relevance açısından kimsenin bakmadığı context.

İlk kurulacak varsayılan, hybrid search ile parent-child chunking birleşimi. Reranking, self-corrective retrieval (CRAG) ve knowledge graph'ler (GraphRAG) bunun üzerine binen birer üst basamak; ölçüm varsayılanın yetmediğini gösterdiğinde devreye girerler. Aşağıdaki pattern'lerin AWS Bedrock Knowledge Bases ve OpenSearch karşılıkları da var; hangi basamağın kendini amorti ettiğine RAGAS metrikleri karar veriyor.

Temel RAG'in Problemleri

Vector similarity tek başına production'da üç somut açık bırakır...

Continue reading...

]]> <![CDATA[AWS AppSync & GraphQL: Production-Ready Real-time API'ler Geliştirmek]]> https://sph.sh/tr/posts/appsync-graphql/ https://sph.sh/tr/posts/appsync-graphql/ Sun, 14 Dec 2025 00:00:00 GMT AWS AppSync; WebSocket subscription'ları, conflict resolution ve AWS data source'larına doğrudan bağlantı sunan yönetilen bir GraphQL endpoint veriyor. Çoğu ekip için geçerli kalan varsayılan dar olanı: resolver'ları JavaScript (APPSYNC_JS) runtime'ıyla doğrudan DynamoDB'ye bağla, Lambda'ya ancak bir field async I/O ya da runtime'ın ifade edemediği bir mantık istediğinde uzan.

Bu tek karar, latency ve maliyeti herhangi bir şema kararından daha fazla oynatıyor. Subscription filtering, caching katmanları, single-table ile multi-table modelleme ve bunların etrafındaki CDK bağlantıları hep bu kararın üzerine yapılan ince ayar.

Real-time API'lerin Zor Tarafları

Continue reading...

]]> <![CDATA[AI Agent Güvenliği: Production Sistemler için Guardrail'ler ve Defense Pattern'leri]]> https://sph.sh/tr/posts/ai-agent-security/ https://sph.sh/tr/posts/ai-agent-security/ Sat, 13 Dec 2025 00:00:00 GMT Otonom olarak tool çağıran ve harici API'lara erişen AI agent'ları, geleneksel uygulama güvenlik modellerinin karşılamak üzere tasarlanmadığı saldırı yüzeyleri ortaya çıkarır. Tek bir prompt injection veya yanlış yapılandırılmış bir tool izni; veri sızıntısına, yetkisiz eylemlere ya da kontrolden çıkan maliyetlere dönüşebilir.

Production'da tutan varsayılan, modelin dışına kurulan katmanlı zorlamadır: her invocation'da yönetilen bir guardrail, her tool çağrısında açık bir yetki kontrolü, her output'ta validation ve hepsinin arkasında sıkı bir token bütçesi. Prompt seviyesindeki talimatlar bu katmanların en zayıfı; bu yüzden önem taşıyan hiçbir şey yalnızca onlara bağlı kalmamalı.

Agent'ın Saldırı Yüzeyi

Continue reading...

]]> <![CDATA[Platform Engineering: Geliştiricilerin Gerçekten Kullanmak İsteyeceği Internal Developer Platformları Oluşturmak]]> https://sph.sh/tr/posts/platform-engineering-idp/ https://sph.sh/tr/posts/platform-engineering-idp/ Fri, 12 Dec 2025 00:00:00 GMT Bir Internal Developer Platform, mühendis ticket açmadan servisini production'a çıkarabildiği gün değerini kanıtlar. Oraya götüren varsayılan, çoğu platform yol haritasının varsaydığından dar: tek bir golden path, tek bir pilot ekiple kurulur, portal arayüzünden önce API veya CLI ile açılır ve zorunlu olduğu için değil en hızlı yol olduğu için benimsenir.

Catalog, self-servis aksiyonlar, IaC orchestration, metrikler ve araç seçimi bu varsayılanın etrafına asılır. Backstage, Port ve AWS bileşenleri, ilk golden path gönüllü benimseme kazandıktan sonra verilecek kararlardır.

Ticket Kuyruğundan Self-Servise

Continue reading...

]]> <![CDATA[Pact ile Contract Testing - Microservislerde API Uyumluluğunu Sağlama]]> https://sph.sh/tr/posts/contract-testing-pact/ https://sph.sh/tr/posts/contract-testing-pact/ Thu, 11 Dec 2025 00:00:00 GMT Consumer-driven contract testing, geçen bir unit test ile çalışan bir entegrasyon arasındaki boşluğu kapatıyor. Her consumer, provider API'den neye ihtiyaç duyduğunu bildiriyor; provider bunu karşılayabildiğini doğruluyor; deployment gate ise bağımlı bir servisi bozacak release'i durduruyor. Ayrı team'lerin sahiplendiği TypeScript microservisler için varsayılan tercih, can-i-deploy gate'i olan bir Pact Broker'ın arkasındaki Pact. End-to-end suite'i yeniden büyütmeden önce bakılacak yer burası.

Continue reading...

]]> <![CDATA[Custom MCP Server Geliştirme: Production-Ready Kılavuz]]> https://sph.sh/tr/posts/custom-mcp-servers/ https://sph.sh/tr/posts/custom-mcp-servers/ Wed, 10 Dec 2025 00:00:00 GMT Model Context Protocol (MCP), büyük AI sağlayıcıların ortak entegrasyon yüzeyi haline geldi. GitHub ya da Slack gibi açık servisler için hazır server'lar iş görüyor. Internal API'ler, proprietary database'ler ve legacy sistemler içinse böyle bir server yok; generic bir server da senin validation kurallarını, güvenlik gereksinimlerini ya da compliance ihtiyaçlarını encode edemiyor. Bu sistemlerde varsayılan, kendi server'ını yazmak. İş de göründüğünden küçük: bir TypeScript projesi, iyi tanımlanmış birkaç tool ve zaten her internal servise uyguladığın production disiplini.

Continue reading...

]]> <![CDATA[SNS/SQS Cross-Account Fan-Out: AWS'de Multi-Account Event Dağıtımı]]> https://sph.sh/tr/posts/sns-sqs-cross-account-fanout/ https://sph.sh/tr/posts/sns-sqs-cross-account-fanout/ Wed, 10 Dec 2025 00:00:00 GMT Cross-account SNS/SQS fan-out, publisher hesabındaki tek bir SNS topic'in başka hesaplara ait SQS queue'lara event dağıtmasını sağlıyor; iki taraf da diğerine credential vermek zorunda kalmıyor. İşin büyük kısmı izin tarafında: bir topic policy, bir queue policy ve şifreleme devreye girdiğinde ikisiyle de uyumlu bir KMS key policy.

Tasarımı üç varsayılan taşıyor. Subscription'ı queue owner oluştursun, şifreli her queue customer-managed bir KMS key kullansın ve filtreleme SNS subscription seviyesinde yapılsın ki consumer'lar zaten atacakları mesajların ücretini ödemesin. CDK bağlantıları, FIFO sıralaması ve hesaplar arası dashboard'lar bu üç kararın üstüne biniyor.

Pattern Ne Kazandırıyor

Continue reading...

]]> <![CDATA[AI Workload'ları için FinOps: Production'da LLM Maliyet Yönetimi]]> https://sph.sh/tr/posts/finops-ai-workloads/ https://sph.sh/tr/posts/finops-ai-workloads/ Tue, 09 Dec 2025 00:00:00 GMT Production'da large language model çalıştırmak, çoğu cloud ekibinin güvendiği maliyet modelini bozuyor. Compute-hour faturalandırma öngörülebilir, token faturalandırma değil. Aynı özellik, prompt'un taşıdığı context'e, soruyu hangi modelin yanıtladığına ve agent'ın durmadan önce kaç tool çağırdığına bağlı olarak çağrı başına kuruşun altında da kalabiliyor, birkaç dolara da çıkabiliyor.

Continue reading...

]]> <![CDATA[AI Agent Mimari Desenleri: ReAct, Plan-and-Execute, Multi-Agent]]> https://sph.sh/tr/posts/chatbots-to-autonomous-agents/ https://sph.sh/tr/posts/chatbots-to-autonomous-agents/ Mon, 08 Dec 2025 00:00:00 GMT Bir chatbot intent'i sınıflandırır ve scriptli bir flow'u tekrar oynatır. Bir agent ise reasoning loop çalıştırır, tool'ları runtime'da seçer ve task'lar arasında memory taşır. Aradaki fark sonradan takılabilen bir yetenek yükseltmesi değil; state, control flow ve hata yönetiminin tasarımını baştan değiştirir.

Başlangıç için makul varsayılan, hybrid memory'li tek bir ReAct agent. Multi-agent bir sistemin koordinasyon yükü olmadan dinamik tool kullanımını karşılar ve geriye debug edilecek tek bir control loop bırakır. Plan-and-Execute, görev temiz şekilde parçalanabiliyorsa ve task başına maliyet bağlayıcı kısıtsa yerini hak eder. Uzmanlaşmış birden fazla agent ise ancak domain'ler gerçekten ayrıysa ve yanlış cevabın bedeli koordinasyon katmanını ödeyecek kadar yüksekse anlamlı ol...

Continue reading...

]]> <![CDATA[Saga Pattern ile Dağıtık Transaction'lar: ACID Olmadan Consistency Sağlamak]]> https://sph.sh/tr/posts/saga-pattern-distributed-transactions/ https://sph.sh/tr/posts/saga-pattern-distributed-transactions/ Sun, 07 Dec 2025 00:00:00 GMT Microservices tek bir iş işlemini birden fazla database'e böler ve ACID garantileri servis sınırında biter. Saga pattern bu boşluğu local transaction'lar ve compensating transaction'larla dolduruyor: commit edilmiş her adım, sonraki bir adım başarısız olduğunda geri alınabiliyor ve sistem eventual consistency'ye oturuyor.

Sipariş benzeri akışlar için güvenli varsayılan AWS Step Functions ile orchestration: saga state'i ve hata yolları tek yerde görünür kalıyor. EventBridge choreography daha ucuz ve daha gevşek bağlı; üç-dört otonom servis zaten domain event paylaşıyorsa yerini hak ediyor. Hangi koordinasyon stilini seçersen seç, pattern'i retry'lar altında ayakta tutan şey idempotent step'ler, ters sırada compensation ve semantic locking.

Continue reading...

]]> <![CDATA[Serverless Uygulamaları Test Etmek: Pratik Bir Strateji Rehberi]]> https://sph.sh/tr/posts/testing-serverless-applications/ https://sph.sh/tr/posts/testing-serverless-applications/ Sat, 06 Dec 2025 00:00:00 GMT Serverless uygulamaları deploy döngüsünü dakikalara sıkıştırır; bu, test ekonomisini değiştirir: eskiden uzun sürüm süreciyle yakalanan bir hata artık bir insan incelemesinden önce production'a ulaşır. Test stratejisi, deploy hızının artık yakalayamadığı şeyi yakalamak zorundadır. Serverless mimarisi yerel öncelikli testi de kırar; Lambda cold start'ları, IAM izinleri, event şemaları ve yönetilen servisler arasındaki sınırlar yerelde canlı bir hesaptakinden farklı davranır.

Continue reading...

]]> <![CDATA[AWS Mesajlaşma Servisleri: SQS vs SNS vs EventBridge - Karar Verme Çerçevesi]]> https://sph.sh/tr/posts/aws-messaging-comparison/ https://sph.sh/tr/posts/aws-messaging-comparison/ Fri, 05 Dec 2025 00:00:00 GMT SQS, SNS ve EventBridge arasında seçim yapmak bir özellik karşılaştırması değil, iletişim modeli kararıdır. SQS bir noktadan noktaya iş kuyruğu, SNS pub/sub fan-out ve EventBridge şema farkında, replay destekli bir olay yönlendiricisidir. Özellik listesine bakarak seçim yapan ekipler uyumsuzluğu genellikle geç fark eder: yanlış servis modeli, doğru servisin doğal olarak sağladığı davranışı yeniden inşa eden özel bir katman yazmayı zorunlu kılar. AWS mesajlaşma yeniden yazımlarının çoğu buradan çıkar.

Continue reading...

]]> <![CDATA[AWS Step Functions Derinlemesine: Dayanıklı Workflow Orchestration Geliştirme]]> https://sph.sh/tr/posts/step-functions-deep-dive/ https://sph.sh/tr/posts/step-functions-deep-dive/ Thu, 04 Dec 2025 00:00:00 GMT AWS Step Functions orchestration mantığını Lambda kodundan çıkarıp bir state machine'e taşıyor ama sonrasındaki her şeyi iki karar belirliyor: Standard mı Express workflow ve error handling'in ne kadarının state machine'e taşınacağı. Dakikalar içinde biten yüksek hacimli işler için doğru varsayılan Express. Standard'ın daha yüksek transition fiyatı ise workflow günlerce sürüyorsa, exactly-once semantiği gerekiyorsa veya audit trail bırakması gerekiyorsa kendini ödüyor.

Continue reading...

]]> <![CDATA[LangChain Production'da: Çalışan Patternler ve İşe Yaramayan Anti-Patternler]]> https://sph.sh/tr/posts/langchain-production-patterns/ https://sph.sh/tr/posts/langchain-production-patterns/ Wed, 03 Dec 2025 00:00:00 GMT Prototip ile Production Arasındaki Boşluk

LangChain uygulamalarını prototipten production'a taşıdığında dokümantasyon örnekleri ile gerçek dünya gereksinimleri arasındaki fark ortaya çıkıyor. Development'ta mükemmel çalışan şeyler, production yükü altında pahalı, yavaş veya güvenilmez hale gelebiliyor.

Prototip iş yükleri yalnızca ölçekte görünen hata biçimlerini gizler: belirsiz girdiler üzerinde döngüye giren agent'lar, her konuşma turuyla artan token harcaması ve sana kullanıcı şikayeti olarak ulaşan sessiz hatalar. Framework'ün soyutlamaları prototyping'i hızlandırır ama production yükü altında ihtiyaç duyduğun maliyet, gecikme ve güvenilirlik kollarını gizler.

Continue reading...

]]> <![CDATA[TypeScript ile MCP Sunucusu Geliştirme: Production Rehberi]]> https://sph.sh/tr/posts/mcp-standard-ai-integration/ https://sph.sh/tr/posts/mcp-standard-ai-integration/ Tue, 02 Dec 2025 00:00:00 GMT Entegrasyon Problemi

AI entegrasyonları tekrarlayan bir pattern ortaya koyuyor: her yeni AI modeli, her veri kaynağı ve tool için custom bağlantılara ihtiyaç duyuyor. Matematik acımasız; M model çarpı N tool, M×N custom implementation demek. Ekipler Slack, GitHub ve database'ler için haftalarca bespoke entegrasyon geliştiriyor ve AI provider değiştiğinde tüm süreci baştan tekrarlıyor.

Geleneksel API'ler bunun için tasarlanmamış. REST endpoint'leri tahmin edilebilir request pattern'leri bekliyor, ama AI agent'ları conversation başına yüzlerce request üretiyor, latency gereksinimleri çok farklı. GraphQL flexible query'lerde yardımcı olsa da, dynamic tool discovery veya multiple invocation'lar arası session management için built-in desteği yok.

Continue reading...

]]> <![CDATA[AWS Bedrock AgentCore ile Production-Ready AI Agentları Geliştirmek]]> https://sph.sh/tr/posts/bedrock-agentcore-production/ https://sph.sh/tr/posts/bedrock-agentcore-production/ Mon, 01 Dec 2025 00:00:00 GMT LangChain veya CrewAI agentlarını production'a taşımak; session isolation, credential management, memory persistence ve observability gerektirir: sıfırdan doğru şekilde inşa etmek aylar alan bir altyapı. Bu olmadan agentlar kullanıcılar arasında güvenlik sınırlarından yoksun kalır ve oturumlar arası kalıcı durum tutamaz; bu da onları gerçek iş yükleri için yetersiz kılar.

Continue reading...

]]> <![CDATA[Aurora vs RDS: Amazon Aurora Ne Zaman Tercih Edilmeli (Mimari ve Maliyet)]]> https://sph.sh/tr/posts/amazon-aurora-introduction/ https://sph.sh/tr/posts/amazon-aurora-introduction/ Sat, 29 Nov 2025 00:00:00 GMT Amazon Aurora ile standart RDS arasında seçim yapmak basit değil. Aurora, 5x MySQL ve 3x PostgreSQL performansı, 128TB'ye kadar otomatik storage scaling ve %99.99 availability vaat ediyor. Ama I/O pricing modeline aşina olmayan ekipleri şaşırtabilecek ek karmaşıklık ve maliyetle geliyor.

Karar; workload özelliklerine, operasyonel gereksinimlere ve maliyet kısıtlarına bakıyor. High availability ya da beşten fazla read replica gerektiren production MySQL veya PostgreSQL workload'ları için makul varsayılan Aurora Standard. I/O, faturanın kabaca dörtte birini aştığında I/O-Optimized'a geç; engine bunların dışındaysa ya da workload küçük, öngörülebilir ve bütçesi darsa RDS'te kal.

Amazon Aurora Nedir?

Continue reading...

]]> <![CDATA[CloudFormation'un 500 Kaynak Sınırını Aşmak: Büyük Ölçekli Altyapı için Pratik Stratejiler]]> https://sph.sh/tr/posts/cloudformation-500-resource-limit-strategies/ https://sph.sh/tr/posts/cloudformation-500-resource-limit-strategies/ Tue, 18 Nov 2025 00:00:00 GMT CloudFormation her stack'i 500 kaynakla sınırlıyor ve bu sınır service quota talebiyle yükseltilemiyor. Serverless uygulamalar bu tavana çoğu takımın beklediğinden hızlı çarpıyor: tek bir Lambda function, role'ü, policy'si, log group'u, version'ı ve alarmlarıyla birlikte sekiz ila on iki kaynağa mal oluyor. Altmış function, daha tek bir tablo ya da kuyruk tanımlanmadan bütçenin tamamını tüketiyor.

Continue reading...

]]> <![CDATA[DynamoDB Single-Table Design: Kapsamlı Modelleme Rehberi]]> https://sph.sh/tr/posts/dynamodb-single-table-design-comprehensive-guide/ https://sph.sh/tr/posts/dynamodb-single-table-design-comprehensive-guide/ Mon, 17 Nov 2025 00:00:00 GMT DynamoDB kullanırken relational tablo mantığıyla düşünmek sorun çözmekten çok sorun yaratır. Tipik yaklaşımda Users, Orders ve Products için ayrı tablolar oluşturulur; sonuç birden fazla round-trip, karmaşık uygulama mantığı ve öngörülemeyen maliyettir.

Single-table design, birden fazla entity type'ı generic partition ve sort key'ler kullanarak tek tabloda saklar. Bir customer'ı bir tablodan, order'larını başka bir tablodan çekmek yerine her şeyi tek request'te alırsın. Birlikte okunan entity'ler için varsayılan seçenek bu olsun; birlikte okunmayanlar için ayrı tablolarda kal. Pattern kendini az tablo sayısıyla değil, data locality ile amorti eder.

Temel İlkeler

Continue reading...

]]> <![CDATA[AWS CDK Proje Yapısı: Service-Based ve Domain-Based Organizasyon]]> https://sph.sh/tr/posts/aws-cdk-code-organization-service-vs-domain-based/ https://sph.sh/tr/posts/aws-cdk-code-organization-service-vs-domain-based/ Sun, 16 Nov 2025 00:00:00 GMT Bir AWS CDK uygulaması aslında bir program; klasör ve stack düzenini framework sana dayatmaz, bu bir tasarım kararıdır. Karar verilmeyince bedeli sonra çıkar: tight coupling, stack'ler arasında circular dependency ve başka bir ekibe sormadan çalıştırılamayan deployment'lar. Ölçek büyüdükçe ayakta kalan düzen, ince bir foundation katmanıyla birlikte domain-based organizasyondur: bir business domain'in sahip olduğu her şey tek klasörde ve tek stack'te durur, VPC, security ve monitoring ise altlarında ortak bir stack'te kalır.

Continue reading...

]]> <![CDATA[Tekrar Kullanılabilir AWS CDK Construct'ları: Factory Function, Builder ve Aspect'ler]]> https://sph.sh/tr/posts/aws-cdk-functional-patterns-reusable-configurations/ https://sph.sh/tr/posts/aws-cdk-functional-patterns-reusable-configurations/ Sat, 15 Nov 2025 00:00:00 GMT AWS CDK, infrastructure'ı gerçek kod olarak ele almanı sağlar. Ortak pattern'ler olmadan ise takımlar duplicate konfigürasyonlarla, tutarsız ayarlarla ve type checker'ın yakalayabileceği deployment hatalarıyla baş başa kalır. Sorunun büyük kısmını iki hamle çözer: tekrarlayan her kaynağı bir factory function'ın arkasına koymak ve kimsenin unutmayı göze alamayacağı ayarları (RemovalPolicy, encryption, log retention) CDK Aspects ile enforce etmek. Builder'lar, composer'lar ve custom L3 construct'lar bu ikisinin uzantısıdır; sonradan eklenir.

Continue reading...

]]> <![CDATA[IoT Lojistik Uygulamaları için Mesajlaşma Protokolü Seçimi: MQTT, AMQP, ZeroMQ, CoAP ve DDS Karşılaştırması]]> https://sph.sh/tr/posts/iot-messaging-protocols-logistics-tracking/ https://sph.sh/tr/posts/iot-messaging-protocols-logistics-tracking/ Sun, 09 Nov 2025 00:00:00 GMT IoT lojistik yığınında protokol seçimi; teslimat garantisinin, latency'nin ve aylık bant genişliği faturasının tavanını belirliyor. Filo takibi ve soğuk zincir izleme için doğru varsayılan MQTT: güvenilmez hücresel bağlantılara dayanıyor, üç QoS seviyesi sunuyor, olgun broker ve istemci kütüphaneleri neredeyse her dilde hazır. AMQP, ZeroMQ, CoAP ve DDS'nin her biri MQTT'yi tek bir eksende geçiyor; asıl soru senin deployment'ının hangi eksende sıkıştığı.

Seçimi Belirleyen Kısıtlar

Continue reading...

]]> <![CDATA[TypeScript'te Davranışsal Tasarım Kalıpları: Observer, Strategy, Command, State]]> https://sph.sh/tr/posts/behavioral-patterns-reactive-programming/ https://sph.sh/tr/posts/behavioral-patterns-reactive-programming/ Thu, 06 Nov 2025 00:00:00 GMT Davranışsal (behavioral) kalıplar, nesnelerin nasıl iletişim kurduğunu ve sorumlulukların nasıl dağıtıldığını tanımlar. Gang of Four; Observer, Strategy, Command, State ve Mediator kalıplarını C++ ve Smalltalk için belgeledi. O dillerde her kalıp, işe yarar bir şey yapmadan önce bir sayfa boilerplate'e mal oluyordu. TypeScript bu hesabı değiştirdi: first-class function'lar, closure'lar ve discriminated union'lar bu kalıpların bir kısmını tek başına karşılıyor, kalanının çoğunu da RxJS, Redux ve XState framework convention'larına dönüştürdü.

Continue reading...

]]> <![CDATA[TypeScript'te Creational Design Pattern'ler: Singleton, Factory, Builder, Prototype]]> https://sph.sh/tr/posts/creational-patterns-modern-typescript/ https://sph.sh/tr/posts/creational-patterns-modern-typescript/ Thu, 06 Nov 2025 00:00:00 GMT TypeScript'te nesne yaratmak artık nadiren bir Gang of Four pattern'i gerektiriyor. Varsayılan, dilin kendi özelliği: tek bir paylaşılan instance için ES modülü, koşullu yaratım için factory function, kopyalama için object spread ya da structuredClone(). Bir modül export'unun zaten hallettiği işi class hiyerarşisiyle sarmalamak gereksiz soyutlama getirir, test edilebilirliği zedeler ve niyeti gizler.

Singleton, Factory, Builder ve Prototype hala yerini hak ediyor ama tetikleyici, ders kitaplarının anlattığından dar: birçok nesnenin tutarlı biçimde uygulaması gereken ortak konfigürasyon ya da adım adım doğrulanması gereken bir kurulum.

Class Olmadan Singleton

Continue reading...

]]> <![CDATA[Gang of Four'un Ötesinde Modern React ve TypeScript Tasarım Kalıpları]]> https://sph.sh/tr/posts/design-patterns-beyond-gof/ https://sph.sh/tr/posts/design-patterns-beyond-gof/ Thu, 06 Nov 2025 00:00:00 GMT Gang of Four, 1994'te C++ ve Smalltalk için pattern'leri dokümante etti; asenkron programlama, component composition ve reactive data flow uygulama yazma biçimini henüz değiştirmemişti. JavaScript ve TypeScript kendi cevaplarını üretti: stateful logic paylaşımı için React Hooks, esnek API'ler için Compound Components, data access için Repository pattern ve kapsülleme için ES module'ler. Front-end'de ya da Node tarafında TypeScript yazıyorsan işin ağırlığını tek bir varsayılan taşıyor: önce dilin veya framework'ün hazır özelliğine bak, pattern'i ancak adını koyabildiğin bir problemi ortadan kaldırıyorsa ekle.

Continue reading...

]]> <![CDATA[React ve TypeScript'te Yapısal Design Pattern'ler]]> https://sph.sh/tr/posts/structural-patterns-component-composition/ https://sph.sh/tr/posts/structural-patterns-component-composition/ Thu, 06 Nov 2025 00:00:00 GMT Yapısal patternler, objeler ve classlar arasındaki ilişkileri organize eder. Gang of Four, 1994'te Decorator, Adapter, Facade, Composite ve Proxy patternlerini C++ ve Smalltalk için belgeledi. Modern TypeScript ve React beşini de framework konvansiyonlarına, hook'lara ve type-safe wrapper'lara dönüştürdü.

Bir React kod tabanında asıl soru, wrapper'ın nereye ait olduğu. Kendi yazdığın kodda varsayılan composition: cross-cutting davranış için hook'lar, hiyerarşi için düz component'ler. Wrap etmek ise kontrol etmediğin sınırlarda yerini buluyor; third-party API'lar, SDK kurulumu ve erişim kuralları gibi.

TypeScript'te Üç Farklı Decorator Anlamı

"Decorator" terimi TypeScript ekosisteminde üç farklı şey ifade ediyor:

Continue reading...

]]> <![CDATA[TypeScript'te Builder Pattern: Modern Uygulamalarda Tip Güvenli Konfigürasyon]]> https://sph.sh/tr/posts/builder-pattern-typescript/ https://sph.sh/tr/posts/builder-pattern-typescript/ Wed, 05 Nov 2025 00:00:00 GMT TypeScript'teki Builder pattern, geleneksel nesne yönelimli dillerdekinden farklı bir amaca hizmet eder. Java ve C# builder'ları çoğunlukla uzun opsiyonel parametre listelerini yönetmek için kullanır. TypeScript daha ileri gidebiliyor: generic'ler ve conditional type'lar sayesinde builder, kısıtlamaları compile time'da zorunlu kılabiliyor. Yanlış konfigürasyon deployment'ta patlamak yerine IDE'de tip hatası olarak görünüyor.

Bu da pattern'in işe yaradığı alanı daraltıyor. Konfigürasyon nesnesi birbirine bağımlı kısıtlamalar taşıyorsa builder'a geç; pratikte bu grup altyapı tanımları, query builder'lar ve test verisi fabrikalarından oluşuyor. Geri kalan her yerde düz nesne literali veya options parametresi yeterli.

TypeScript'te Karmaşık Nesnelerin Sorunu

Continue reading...

]]> <![CDATA[Middy ve Zod: Type-Safe AWS Lambda Middleware Doğrulama]]> https://sph.sh/tr/posts/middy-builder-pattern-zod-validation/ https://sph.sh/tr/posts/middy-builder-pattern-zod-validation/ Wed, 05 Nov 2025 00:00:00 GMT Lambda codebase'inde middleware zamanla dağılır. Proje birkaç fonksiyonu geçtiğinde her handler kendi Middy zincirini kuruyor: error handler'lar farklı pozisyonlara düşüyor, bazı endpoint'ler authenticate ediyor bazıları etmiyor ve handler imzasıyla artık uyuşmayan bir schema ancak trafik geldiğinde hata veriyor.

Middy'nin önüne konan ince bir builder bunu çözer. Middleware sırasını tek yerde sabitler, context type'larını ileri taşır (böylece TypeScript handler'ın ne aldığını bilir) ve validation için JSON Schema yerine Zod kullanır. Bedeli birkaç yüz satır glue kod ve biraz daha ağır bir cold start; birkaç endpoint'i geçen her API için bu takas kârlı.

Standart Middleware Kurulumunun Sorunları

Continue reading...

]]> <![CDATA[OpenTelemetry Temelleri: Modern Observability için Başlangıç Rehberi]]> https://sph.sh/tr/posts/opentelemetry-fundamentals-beginner-guide/ https://sph.sh/tr/posts/opentelemetry-fundamentals-beginner-guide/ Wed, 05 Nov 2025 00:00:00 GMT Dağıtık sistemlerde tek bir kullanıcı request'i düzinelerce servisten geçer; bu yüzden bir hatayı ya da latency spike'ını sadece log'larla açıklamak çoğu zaman mümkün olmaz. Ortak bir telemetri standardı olmadan her servis kendi formatında veri üretir ve mühendisler trace, metrik ve log'ları uyumsuz backend'ler arasında elle eşleştirmek zorunda kalır. OpenTelemetry (OTel), bu uyumsuzluğu ortadan kaldıran açık kaynak framework'tür: telemetriyi üretmek, işlemek ve export etmek için dilden ve runtime'dan bağımsız tek bir yol.

Continue reading...

]]> <![CDATA[7 Az Bilinen TypeScript Özelliği: satisfies, Branded Types ve Daha Fazlası]]> https://sph.sh/tr/posts/typescript-essential-underutilized-features/ https://sph.sh/tr/posts/typescript-essential-underutilized-features/ Tue, 04 Nov 2025 00:00:00 GMT tsconfig.json içinde strict açmak, type güvenliği meselesinin kapandığı hissini verir. Kapanmaz. Indexed access hâlâ undefined ihtimalini gizleyen bir type döndürür, bir UserID hâlâ OrderID bekleyen fonksiyona sorunsuz geçer, union'a eklenen yeni bir member da önceden yazdığın her switch bloğundan sessizce kaçar.

En yüksek getirili değişiklik noUncheckedIndexedAccess: strict modun açmadığı bir compiler flag'i. Önce onu ekle, ardından geri kalan boşlukları kapatan type seviyesindeki araçlara geç: satisfies, branded types, exhaustiveness kontrollü discriminated unions, type predicates, template literal types ve infer. Yedisi de yalnızca derleme zamanında var olur; runtime'a hiçbir maliyet çıkarmaz.

Strict Mode'un Kapatmadığı Boşluklar

Continue reading...

]]> <![CDATA[Her Yazılım Geliştiricinin Bilmesi Gereken Ağ Temelleri]]> https://sph.sh/tr/posts/network-fundamentals-developers-guide/ https://sph.sh/tr/posts/network-fundamentals-developers-guide/ Thu, 30 Oct 2025 00:00:00 GMT Distributed sistemlerdeki gizemli timeout'lar, yavaş API'lar ve TLS hataları neredeyse her zaman uygulama sorunu gibi görünen ağ sorunlarıdır. Geliştiriciler TCP, DNS ve HTTP'nin çalışma modelinden yoksun olduğunda teşhis yanlış katmanda takılır, düzeltmeler ise tahmine dayalı kalır.

Aşağıdaki kavramlar backend geliştirmede ve production troubleshooting'inde en sık karşılaşılanlar: protokoller, bağlantı yaşam döngüsü, debugging araçları ve güvenlik temelleri. Her başlık kavramın ne olduğunu, ne zaman önem kazandığını ve hangi komutun cevabı verdiğini anlatıyor.

Ağ Bilgisi Nerede İşe Yarar

Mükemmel uygulama kodu bile, verinin client ile server arasında nasıl hareket ettiği anlaşılmadığında yetersiz kalır. Geliştiriciler şu konularda zorlanır:

Continue reading...

]]> <![CDATA[TypeScript için CloudEvents SDK: Serverless Mimarilerde Event Standardizasyonu]]> https://sph.sh/tr/posts/cloudevents-sdk-typescript-serverless/ https://sph.sh/tr/posts/cloudevents-sdk-typescript-serverless/ Wed, 29 Oct 2025 00:00:00 GMT Event-driven mimarilerde her event kaynağı event'leri farklı şekilde tanımlama eğilimindedir: bir Lambda { userId: string } beklerken, diğeri { user_id: string }, üçüncüsü ise { sub: string } kullanır. Bu heterojenliğin maliyeti, kaynak sayısıyla büyüyen entegrasyon kodu ve sistemler arasında event'leri ilişkilendiremeyen gözlemleme araçlarıdır. Standartlaştırılmış bir event zarfı her iki sorunu da çözer; karşılığında her üreticinin aynı şemayı benimsemesini gerektirir.

Continue reading...

]]> <![CDATA[Domain-Driven Design: Giriş ve Temeller]]> https://sph.sh/tr/posts/domain-driven-design-introduction/ https://sph.sh/tr/posts/domain-driven-design-introduction/ Wed, 29 Oct 2025 00:00:00 GMT Domain-Driven Design (DDD), kodun yapısını hizmet ettiği business domain'iyle hizalar. Karmaşık ve uzun ömürlü sistemlerde bu hizalama karşılığını verir: sınıflar ve method'lar domain uzmanlarının zaten kullandığı isimleri taşıdığında, business kuralları controller'lara ve servislere dağılmak yerine tek bir yerde toplanır. Bedeli, işi bilen kişilerle birlikte harcanan modelleme zamanıdır.

Karar da tam olarak bu bedelin üzerine kuruludur. Sık değişen kurallar, yıllarca sahipleneceğiniz bir sistem ve sizinle oturmaya istekli domain uzmanları: bu üç koşul varsa yatırım kendini amorti eder. Yoksa sade bir katmanlı mimari daha iyi hizmet eder.

Domain-Driven Design Nedir?

Continue reading...

]]> <![CDATA[Event Storming: Karmaşık Domain'leri Anlamak İçin Pratik Rehber]]> https://sph.sh/tr/posts/event-storming-guide/ https://sph.sh/tr/posts/event-storming-guide/ Tue, 28 Oct 2025 00:00:00 GMT Bir business süreci kâğıda dökülürken hep bir şeyler kayboluyor. Görüşmeler sürecin yalnızca tek bir kişiye görünen kısmını yakalıyor; o görüşmelerden yazılan requirement dokümanı da kimsenin söylemeyi akıl etmediği adımları atlıyor. Event Storming bu boşluğu bir workshop ile kapatır: business uzmanları ve developer'lar domain event'lerini kronolojik sırayla duvara dizer, süreç herkese aynı anda görünür hale gelene kadar.

Daha önce hiç oturum yönetmediysen Big Picture formatıyla başla ve business uzmanlarını baştan sona odada tut. Tekniğin sunduğu diğer her şey (detaylı süreç tasarımı, aggregate sınırları, servis sınırları) o ilk oturumun ürettiği ortak haritaya dayanır; domain uzmanı olmadan yapılan oturum ise developer'ların tahmin yürüttüğü bir tasarım toplantısına dönüşür.

Continue reading...

]]> <![CDATA[VPS Üzerinde Dokploy ve Cloudflare Tunnel Kurulumu]]> https://sph.sh/tr/posts/cost-effective-vps-dokploy-cloudflared-setup/ https://sph.sh/tr/posts/cost-effective-vps-dokploy-cloudflared-setup/ Sun, 26 Oct 2025 00:00:00 GMT Private sunucu çalıştırmak için pahalı cloud faturalarına ya da karmaşık infrastructure'lara ihtiyacınız yok. En iyi çözüm genellikle kurumsal platformlar yerine basit, odaklanmış araçları birleştirmekte yatıyor.

Production-ready bir private sunucu üç parçadan oluşuyor: - VPS uygun maliyetli compute için (~\$5-20/ay) - Dokploy temiz bir UI ile Docker-tabanlı deployment'lar için - Cloudflared port açmadan güvenli erişim için

Üçünün toplam maliyeti ayda yaklaşık \$6-8 ve bu bütçe birden fazla uygulamayı güvenli şekilde çalıştırmaya yetiyor.

Gereksinimler

Continue reading...

]]> <![CDATA[Event-Driven Mimari ile CRM Sistemleri Geliştirmek]]> https://sph.sh/tr/posts/crm-event-driven-architecture/ https://sph.sh/tr/posts/crm-event-driven-architecture/ Sun, 26 Oct 2025 00:00:00 GMT Geleneksel CRM sistemleri müşteri durumunu doğrudan saklar: müşteri başına bir kayıt, her etkileşimde yerinde güncellenir. Bu model; ürün aynı anda gerçek zamanlı kişiselleştirme, GDPR uyumlu denetim izi ve çok kanallı orkestrasyon istediğinde çöker. Güncel-durum satırının oraya nasıl geldiğine dair bir hafızası yoktur. Event-driven CRM bu modeli tersine çevirir: her etkileşim değişmez bir event olarak kaydedilir ve herhangi bir görüntü (profil, consent defteri, kanal geçmişi) bu event akışı üzerinde bir projeksiyon olur.

İşe yarayan varsayılan: AWS üzerinde EventBridge ve DynamoDB ile event sourcing, üstüne kişiselleştirme ve consent için CQRS projeksiyonları. Faturası da belli: depolama maliyeti, eventual-consistency bütçeleri ve replay pencereleri.

Continue reading...

]]> <![CDATA[Strapi vs Contentful vs Storyblok vs Kontent.ai: Headless CMS Karşılaştırması]]> https://sph.sh/tr/posts/multi-channel-content-management-headless-cms/ https://sph.sh/tr/posts/multi-channel-content-management-headless-cms/ Sun, 26 Oct 2025 00:00:00 GMT Headless CMS seçimi, tek bir içerik setinin hem web sitesini hem mobil uygulamayı hem de sıradaki kanalı beslemesi gerektiği anda zorlaşıyor. Kısa listeye genelde dört platform giriyor: Strapi, Contentful, Kontent.ai ve Storyblok. Depolayabildikleri içerik açısından birbirlerine yakınlar; asıl ayrıştıkları yer, kullanım maliyetini kimin üstlendiği. Karar da tek bir soruya iniyor: darboğaz içerik ekibiniz mi, geliştirme ekibiniz mi?

Continue reading...

]]> <![CDATA[Traefik vs Nginx: nginx Kullanıcıları İçin Giriş]]> https://sph.sh/tr/posts/traefik-101-introduction/ https://sph.sh/tr/posts/traefik-101-introduction/ Sun, 26 Oct 2025 00:00:00 GMT Traefik, çalışırken değişen altyapılar için tasarlanmış bir reverse proxy ve load balancer. Container orchestrator'ünü izler ve routing kurallarını kendisi günceller; nginx ise config dosyasını düzenleyip reload etmeni bekler. Seçimin büyük kısmını bu tek fark belirliyor. Servislerin kendi takvimine göre gelip giden container'larsa, o kenara Traefik koy; topolojinin sabit olduğu yerde nginx'te kal.

Takas şu: operasyonel kolaylığa karşılık daha ince bir veri yolu. Traefik düzenle-test-et-reload döngüsünü ortadan kaldırıyor, bedelini de daha büyük bir runtime ayak izi ve daha az olgun bir rewrite/caching motoruyla ödüyor. Sabit bir upstream listesi statik dosya sunuyorsa bu kötü bir takas. Günde birkaç kez yeniden deploy edilen bir container filosu içinse kolay bir takas.

Continue reading...

]]> <![CDATA[AI Yardım Spektrumu: Profesyonel Yazılım Geliştirmede Doğru Seviyeyi Seçmek]]> https://sph.sh/tr/posts/ai-assistance-spectrum-professional-software-engineering/ https://sph.sh/tr/posts/ai-assistance-spectrum-professional-software-engineering/ Fri, 24 Oct 2025 00:00:00 GMT Profesyonel bir mühendislik workflow'una ne kadar AI yardımı girmeli? İşe yarayan cevap evet ya da hayır değil, bir seviye. Tamamen manuel bir baseline'ın üstünde altı seviye duruyor: sadece inceleme amaçlı sorgular, inline autocomplete, fonksiyon üretimi, çok dosyalı refactoring, otonom ajanlar ve kimsenin çıktıyı okumadığı "vibe coding". Her basamak hız kazandırır, anlama payından harcar.

Production kodunun çoğu için savunulabilir varsayılan fonksiyon seviyesi generation'dır. Signature'ı ve niyeti siz yazarsınız, model gövdeyi yazar, siz de onu her diff gibi incelersiniz. Regulated veya güvenlik açısından kritik yollarda bu seviyeyi düşürün; ancak test coverage modelin kaçırdıklarını yakalayacak kadar güçlüyse yükseltin.

Temel Problem

Continue reading...

]]> <![CDATA[AI Geliştirici Araçları: Benimseme Verileri ve Trendler]]> https://sph.sh/tr/posts/ai-tools-developers-part-1/ https://sph.sh/tr/posts/ai-tools-developers-part-1/ Fri, 03 Oct 2025 00:00:00 GMT AI kodlama asistanları neredeyse evrensel bir benimsenmeye ulaştı: DORA'nın 2025 araştırması kullanım oranını teknoloji çalışanlarının yaklaşık %90'ı olarak veriyor. Aynı dönemde METR'in yürüttüğü randomize deney, deneyimli açık kaynak geliştiricilerinin AI araçlarını kullanmalarına izin verildiğinde görevleri %19 daha yavaş tamamladığını ölçtü. Aynı geliştiriciler araçların kendilerini %20 hızlandırdığına inanıyordu. İki bulgu aynı anda doğru olabilir ve birlikte, pek çok yaygınlaştırmanın neden tıkandığını açıklıyorlar.

Continue reading...

]]> <![CDATA[AI Kodlama Araçları Nasıl Benimsenir: Pilottan Üretime]]> https://sph.sh/tr/posts/ai-tools-developers-part-2/ https://sph.sh/tr/posts/ai-tools-developers-part-2/ Fri, 03 Oct 2025 00:00:00 GMT AI kodlama araçlarını mevcut bir mühendislik organizasyonuna yaymak, araçlar yüzünden değil ikincil maliyetler yüzünden tökezler. İnceleme kuyrukları uzar, insan eliyle yazılmış kod varsayımıyla kurulmuş güvenlik kontrolleri yeni yüzeyi kapsamaz ve verimlilik hikâyesi pilot sunumundaki gibi çıkmaz: METR'in randomize çalışması, deneyimli geliştiricilerin kendi depolarında AI yardımı kullanmalarına izin verildiğinde işleri %19 daha uzun sürede bitirdiğini ölçtü; üstelik geliştiriciler daha hızlı olacaklarını bekliyordu. METR o tahmini sonradan genişletti ve ters yöne işaret eden bir takip çalışması yayımladı. Verimlilik etkisinin büyüklüğünü tartışmalı kabul edin; planlayabileceğiniz kısım ikincil maliyetlerdir.

Continue reading...

]]> <![CDATA[AI Kodlama Araçlarında Güvenlik Riskleri ve Yönetişim]]> https://sph.sh/tr/posts/ai-tools-developers-part-3/ https://sph.sh/tr/posts/ai-tools-developers-part-3/ Fri, 03 Oct 2025 00:00:00 GMT AI kodlama asistanları kendine özgü bir güvenlik riski sınıfı ortaya çıkarır: eğitim verisinden gerçekmiş gibi görünen gizli bilgiler üretir ve standart secret scanning buluşsal yöntemlerini atlayan kalıpları normalleştirir. Bu riske karşı ayakta kalan varsayılan dar bir kural. Her AI önerisini güvenilmeyen girdi olarak kabul edin, commit'e ulaşmadan tarayın ve araca çalışabileceği en dar repo erişimini verin. Bir AI yönetişim programındaki diğer her şey, bu varsayılanı kurumsal ölçekte uygulatmanın yoludur.

Continue reading...

]]> <![CDATA[AI Kodlama Araçlarında ROI: Gerçek İş Değerini Ölçmek]]> https://sph.sh/tr/posts/ai-tools-developers-part-4/ https://sph.sh/tr/posts/ai-tools-developers-part-4/ Fri, 03 Oct 2025 00:00:00 GMT AI geliştirici araçlarının bütçeleri hep aynı yönde şaşar. Koltuk fiyatı kararın kendisi gibi görünür; oysa GitHub, Copilot'u Haziran 2026'da kullanıma dayalı faturalamaya geçirdiğinden beri o fiyat sabit bir sayı bile değil. Birinci yılın harcamasını asıl belirleyen kalemler hiçbir satıcı modelinde yer almaz: koltuğun üzerine binen ölçümlü kullanım, herkes araçları öğrenirken yaşanan verimlilik düşüşü, büyüyen PR kuyruğunu karşılayacak inceleme kapasitesi ve ilk olaydan sonra sonradan eklenen güvenlik kontrolleri.

Continue reading...

]]> <![CDATA[Lambda Layer Versiyon Yönetimi: Çok Ortamlı Deployment Stratejileri]]> https://sph.sh/tr/posts/lambda-layer-versioning-multi-environment/ https://sph.sh/tr/posts/lambda-layer-versioning-multi-environment/ Fri, 03 Oct 2025 00:00:00 GMT AWS Lambda bir layer'a otomatik artan bir tam sayı veriyor, üstüne hiçbir şey vermiyor. Semantic versiyon yok, ortamlar arasında terfi yolu yok, hangi fonksiyonun hangi build'i çalıştırdığına dair kayıt yok. Takımlar bu boşluğu ellerinin altındaki en kolay yöntemle kapatıyor; dev, staging ve production'ın birbirinden farklı üç layer versiyonunda kalması ve hiçbirinin bir değişikliğe bağlanamaması da böyle oluyor.

Başlangıç için doğru varsayılan bir version manifest: repoda duran, her ortam için explicit bir layer ARN'i sabitleyen, commit ile terfi ettirilen ve revert ile geri alınan bir YAML dosyası. Git üzerinde tam bir audit trail veriyor, deploy sırasında hiçbir lookup gerektirmiyor. Elle düzenlenen bir dosyanın yetmediği durumlar için diğer üç strateji devreye giriyor.

Continue reading...

]]> <![CDATA[Yazılım Ekiplerinde Rol Beklentileri: RACI ve DACI Çerçeveleri]]> https://sph.sh/tr/posts/role-expectations-team-performance/ https://sph.sh/tr/posts/role-expectations-team-performance/ Fri, 03 Oct 2025 00:00:00 GMT Yazılım takımlarında rol belirsizliği kendini rol tartışması olarak değil, duran iş olarak gösterir. Gallup'un 2024 ABD işyeri araştırmasına göre çalışanların %46'sı kendisinden ne beklendiğini söyleyemiyor. Mühendisler bir kararın kime ait olduğunu bilmediğinde iş ya bir toplantıyı bekler ya da iki ayrı branch'te iki kez yazılır.

İki hafif çerçeve bu sorunun büyük kısmını kapatır. Tekrar eden akışlar için (API tasarımı, deployment, gereksinimler) RACI'yi, tek seferlik kararlar için (mimari, araç seçimi) DACI'yi kullanın. Başlangıç için varsayılan dar tutulmalı: en çok yeniden iş doğuran iki üç akışı seçin, kararı kimin verdiğini yazın, geri kalanı size bir bedel çıkarana kadar informal bırakın.

Rol Belirsizliğinin Maliyeti

Continue reading...

]]> <![CDATA[Vercel Alternatifleri: Next.js Deployment Kapsamlı Rehberi]]> https://sph.sh/tr/posts/vercel-alternatives-nextjs-deployment/ https://sph.sh/tr/posts/vercel-alternatives-nextjs-deployment/ Tue, 30 Sep 2025 00:00:00 GMT Vercel, Next.js için en pürüzsüz deployment deneyimini sunar; ama fatura trafikten daha hızlı büyür. Bandwidth aşımları GB başına \$0.15'e gelir ve function invocation'lar sessizce birikir; tek bir marketing zirvesi, tam da dönüşümlerin en kritik olduğu anda maliyeti katlayabilir. Deployment'ı kolaylaştıran platforma özel API'ler, aynı zamanda ileride taşınmayı zorlaştıran bir lock-in yaratır.

Çoğu Next.js uygulaması için ilk denenecek varsayılan, OpenNext adapter'ıyla Cloudflare Workers: bandwidth ölçülmüyor ve adapter uygulamayı taşınabilir tutuyor. Bu varsayılanın yetmediği durumları AWS üzerinde SST ve CDN arkasındaki Docker VPS karşılıyor. Her hedefin kendi maliyet profili ve dokümantasyonun atladığı kendi migration detayları var.

Continue reading...

]]> <![CDATA[GitHub Spec Kit: Spesifikasyon Güdümlü AI Geliştirme Rehberi]]> https://sph.sh/tr/posts/github-speckit-ai-specification-framework/ https://sph.sh/tr/posts/github-speckit-ai-specification-framework/ Wed, 24 Sep 2025 00:00:00 GMT AI araçlarının ürettiği kod genellikle yerel bir smoke test'i geçer ama üretim çıtasını geçemez: belirsiz arayüzler, yukarı akış verisi hakkında doğrulanmamış varsayımlar, eksik hata yönetimi ve kod tabanının konvansiyonlarını değil prompt'u yansıtan bir yapı. Arayüzün, girdilerin, değişmezlerin ve hata modlarının açık, makine okunabilir bir spesifikasyonu, modelin tek satır üretmesinden önce bu boşluğun çoğunu kapatır.

Continue reading...

]]> <![CDATA[AWS CDK ve Serverless ile Geçici Preview Ortamları Oluşturma]]> https://sph.sh/tr/posts/ephemeral-preview-environments-aws-serverless-cdk/ https://sph.sh/tr/posts/ephemeral-preview-environments-aws-serverless-cdk/ Sun, 21 Sep 2025 00:00:00 GMT Paylaşılan Staging Ortamlarının Problemi

Paylaşılan tek bir staging ortamı, bir ekip günde birden fazla pull request açmaya başladığı an darboğaza dönüşür. Eşzamanlı PR'lar birbirlerinin veritabanı durumunu üzerine yazar, aynı feature flag'lerde çakışır ve aynı DNS kaydı için yarışır; test sinyali düşer çünkü bir hata, gerçek bir regresyon kadar "başka birinin PR'ı" anlamına da gelebilir.

Continue reading...

]]> <![CDATA[Key-Value Store Nedir? Doğru Çözümü Seçme Rehberi]]> https://sph.sh/tr/posts/redis-key-value-storage-fundamentals/ https://sph.sh/tr/posts/redis-key-value-storage-fundamentals/ Mon, 15 Sep 2025 00:00:00 GMT Relational database pattern'lerini key-value erişim workload'larına (session storage, caching, sepet verisi) uygulamak önlenebilir gecikmeye ve şema karmaşıklığına yol açar. Yanlış storage modelini seçmek, takımları temel bir mimari uyumsuzluğu gideremeyen index ayarlama döngülerine sürükler. Key-value storage bu uyumsuzluğu ortadan kaldırır: veri modeli erişim pattern'iyle örtüşür, böylece bir lookup sorgu planı yerine tek bir hash probe'a iner.

Dağıtık workload'larda varsayılan Redis'tir; onu geçmek için somut bir gerekçe gerekir. İstisnalar dar ve tahmin edilebilir: configuration ve coordination için etcd, dalgalanan serverless trafik için DynamoDB, tek sunucu varsa in-process cache ve tüm deployment JVM üzerinde koşuyorsa gömülü Hazelcast.

Continue reading...

]]> <![CDATA[Claude Code MCP Sunucuları: Kurulum ve Yapılandırma Rehberi]]> https://sph.sh/tr/posts/claude-code-mcp-ecosystem-mastery/ https://sph.sh/tr/posts/claude-code-mcp-ecosystem-mastery/ Sat, 13 Sep 2025 00:00:00 GMT Claude Code'un verimlilik tavanı, MCP (Model Context Protocol) sunucuları devreye girdiğinde belirgin biçimde yükselir. Onlar olmadan akış kopyala-yapıştır modunda kalır; doğru MCP sunucuları bağlandığında Claude Code altyapı, veritabanı ve servislerle doğrudan etkileşim kurabilir. Başlangıç için doğru kurulum küçüktür: filesystem sunucusu ve tek bir dokümantasyon sunucusu; geri kalanı göreve göre eklenir ve iş bitince kapatılır.

Claude Code Nedir

Claude Code, çoğu geliştiricinin hiç keşfetmediği yeteneklere sahip bir geliştirme ortamıdır. Bunların üçü diğerlerinden daha çok işe yarar.

Üç Etkileşim Modu

Continue reading...

]]> <![CDATA[Kültürel Körlüğün Gizli Maliyeti: Global Engineering Takımları Nasıl Başarısız Oluyor]]> https://sph.sh/tr/posts/cultural-misunderstandings-global-engineering-teams/ https://sph.sh/tr/posts/cultural-misunderstandings-global-engineering-teams/ Sat, 13 Sep 2025 00:00:00 GMT Global engineering takımlarında kültürel körlüğün bedeli sessizce ödenir: her takım "hazır" derken farklı şeyler kasteder; bu uçurum kodda değil, entegrasyon aşamasında ortaya çıkar. İletişim tarzı, hiyerarşi beklentisi ve geri bildirim biçimi kültürler arasında keskin farklılaşır; bu farkları hiç adlandırmayan dağıtık bir takım bedelini yeniden çalışmayla, kaçırılan eskalasyonlarla ve susmayı seçen mühendislerle öder.

Continue reading...

]]> <![CDATA[RACI ve DACI: Yazılım Ekiplerinde Rol Belirsizliği]]> https://sph.sh/tr/posts/hidden-cost-role-ambiguity-software-team-performance/ https://sph.sh/tr/posts/hidden-cost-role-ambiguity-software-team-performance/ Sat, 13 Sep 2025 00:00:00 GMT Rol belirsizliği (kararların ve çıktıların sahipliğinin net olmaması) sprint board'da hiç görünmeyen tekrarlayan iş, karar felci ve eskalasyon yüküyle mühendislik verimini sessizce tüketir. Çözüme kavuşturulmazsa, gayri resmi koordinasyonun artık boşlukları dolduramadığı dağıtık ekiplerde katlanarak büyür. Üç somut çerçeve, süreci ağırlaştırmadan bu israfın büyük kısmını ortadan kaldırır: RACI matrisleri, swim-lane tanımları ve eskalasyon protokolleri.

Tek bir tanesini seçeceksen RACI'yi seç ve tekrarlayan işlere uygula: API tasarımı, deployment, gereksinim onayı. DACI'yi tek seferlik mimari kararlara sakla. İkisinin altındaki kural aynı: bir karardan yalnızca tek bir kişi hesap verir, geri kalan herkes kendisine danışıldığını mı yoksa yalnızca bilgilendirildiğini mi bilir.

Continue reading...

]]> <![CDATA[Yazılım Ekiplerinde Zor Meslektaşlarla Çalışmak: Teorinin Ötesinde Pratik Çözümler]]> https://sph.sh/tr/posts/managing-difficult-coworkers-software-engineering-teams/ https://sph.sh/tr/posts/managing-difficult-coworkers-software-engineering-teams/ Sat, 13 Sep 2025 00:00:00 GMT Zor meslektaşlar hakkındaki genel workplace tavsiyeleri yazılım ekiplerinde yetersiz kalır, çünkü sürtünmenin teknik kökleri vardır. Engellenen bir deployment, 47 mesajlık bir naming tartışmasına dönüşen kod review veya outage sırasında ortadan kaybolan bir takım arkadaşı; standart Kötümser, Pasif-Agresif ve Bilgiç reçetesiyle çözebileceğiniz kişilik çatışmaları değildir. Davranış; kod ownership'i, review yetkisi ve on-call baskısıyla büyür.

Bu uyumsuzluk, management literatürünün kapsamadığı arketipler üretir: mükemmeliyetçi engelleyici, teknik pürist, hayalet meslektaş. Her biri farklı bir karşılık ister ve bu karşılık çoğu zaman bir süreç değişikliğidir; doğrudan yüzleşme nadiren ilk adımdır.

Yazılım Ekiplerindeki Beş Arketip

Continue reading...

]]> <![CDATA[Güvenlik Sözlüğü: Her Geliştirici Ekibinin Bilmesi Gereken 50+ Terim]]> https://sph.sh/tr/posts/security-glossary-appendix/ https://sph.sh/tr/posts/security-glossary-appendix/ Sat, 13 Sep 2025 00:00:00 GMT Güvenlik terimlerindeki karışıklık mimari hataya dönüşür. Login'i yalnızca OAuth2 üzerine kuran bir ekip, haftalar sonra OAuth2'nin yetki verdiğini ama kimlik hakkında hiçbir şey söylemediğini fark eder. Çözüm OIDC'dir; o noktada token akışı hem client hem API tarafında yanlış kurulmuştur.

Aşağıdaki terimler authentication, token, erişim kontrolü ve tasarım incelemelerinde geçen Zero Trust sözlüğünü kapsıyor. Her madde tanımı, işe yarayıp yaramayacağını belirleyen implementasyon detayını ve genelde zaman kaybettiren yanlış anlamayı veriyor. Makul bir varsayılan varsa adı konuyor: yeni sistemlerde OIDC, birincil faktör olarak passkey, rotasyonlu refresh token ile kısa ömürlü access token.

Authentication Temelleri

Continue reading...

]]> <![CDATA[Takım Çatışması Çözümü: Yüksek Performansa Giden Yol Haritası]]> https://sph.sh/tr/posts/team-conflict-resolution-field-guide/ https://sph.sh/tr/posts/team-conflict-resolution-field-guide/ Sat, 13 Sep 2025 00:00:00 GMT Çözümsüz kalan mimari kilitlenmeler, tırmanan code review thread'leri ve artan işten ayrılmalar aynı kök nedeni paylaşır: takımda sürtüşmeyi erken yüzeye çıkaracak ortak bir süreç ve verimli anlaşmazlığı toksik işlev bozukluğundan ayıracak bir ölçüt yoktur. Benimsenmeye değer varsayılan yaklaşım dar kapsamlı: müdahaleyi seçmeden önce çatışmayı türüne göre sınıflandırın ve bu sınıflandırmayı takımın kendi yazdığı bir çalışma anlaşmasına bağlayın.

Psikolojik güvenliğin olduğu bir takımda görev çatışması kararı keskinleştirir. Aynı anlaşmazlık bu güvenlik olmadan sertleşip ilişki çatışmasına dönüşür; çözmesi pahalı olan da ilişki çatışmalarıdır. Erken tespit ile yazılı bir karar framework'ü, birincinin ikinciye dönüşmesini engelleyen şeydir.

Continue reading...

]]> <![CDATA[pnpm Catalogs: Monorepo'da Dependency Drift Çözümü]]> https://sph.sh/tr/posts/pnpm-catalog-dependency-drift-solution/ https://sph.sh/tr/posts/pnpm-catalog-dependency-drift-solution/ Wed, 10 Sep 2025 00:00:00 GMT JavaScript monorepo'larında dependency drift sessizce başlar. Bir service lodash'i ^4.17.20, diğeri ^4.17.21 olarak tanımlar; installer ikisini de kurar. Haftalar sonra ortak bir helper, hangi service'in import ettiğine göre farklı davranır ve hata beş makineden yalnızca birinde tekrarlanır.

pnpm catalog'ları bu açığı kaynağında kapatır. Paylaşılan her versiyon pnpm-workspace.yaml içinde bir kez tanımlanır, paketler ona catalog: ile referans verir ve bir paket versiyonu satır içinde yazdığında CI kontrolü build'i düşürür. Bedeli şu: tek bir dosya ortak bir darboğaza dönüşür. react için tam olarak istediğiniz şey budur; yalnızca tek bir service'in kullandığı bir parser için ise tam olarak istemediğiniz şeydir.

Dependency Drift Sorunu

Continue reading...

]]> <![CDATA[Teknik RFC Nasıl Yazılır: Bölüm Bölüm Rehber]]> https://sph.sh/tr/posts/anatomy-of-technical-rfc/ https://sph.sh/tr/posts/anatomy-of-technical-rfc/ Mon, 08 Sep 2025 00:00:00 GMT Kritik bir sistem için yazılan bir RFC iki nedenden takılır: değerlendiriciler hangi problemi çözdüğünü anlayamaz ya da kendilerini ilgilendiren bölümü bulamaz. İkisi de yapısal sorundur ve ikisi de ilk inceleme yorumu gelmeden çözülebilir.

RFC'yi bir satış dokümanı gibi ele alın. Tek bir çözümü, öncelikleri çatışan dört kitleye satar: işi finanse eden yöneticiler, tasarımı denetleyen mimarlar, onu inşa eden uygulayıcılar ve sonrasında nöbeti tutan operasyon ekibi. Her kitle kendi cevabını dokümanın tamamını okumadan bulabilsin; cevapları da kitlelerin sorduğu sıraya koyun.

Sırayı Kitle Belirler

Continue reading...

]]> <![CDATA[Sektöre Göre Kimlik Doğrulama Stratejileri: Bankacılık, Sağlık, E-ticaret, SaaS]]> https://sph.sh/tr/posts/authentication-authorization-strategies-by-business-domain/ https://sph.sh/tr/posts/authentication-authorization-strategies-by-business-domain/ Mon, 08 Sep 2025 00:00:00 GMT Kimlik doğrulama ve yetkilendirme, iş alanına göre keskin biçimde farklılaşan dört girdinin üzerine oturur: düzenleyici kısıtlamalar, kullanıcı beklentileri, hata biçimleri ve denetim gereksinimleri. Bir bankacılık kimlik doğrulama akışı ile sosyal medya akışı aynı mekanik soruya ("bu istek iddia edilen kullanıcıdan mı geliyor?") cevap verir, ancak kabul edilebilir cevaplar oturum uzunluğu, çok faktörlü güç, kurtarma yolları ve bir kilitlemenin nasıl göründüğü noktalarında birbirinden ayrılır.

Continue reading...

]]> <![CDATA[Code Review Kültürü: Hatabulma'dan Bilgi Paylaşımına]]> https://sph.sh/tr/posts/code-review-culture-nitpicking-to-knowledge-sharing/ https://sph.sh/tr/posts/code-review-culture-nitpicking-to-knowledge-sharing/ Mon, 08 Sep 2025 00:00:00 GMT Ekip retrospektiflerinde tekrar eden bir sinyal vardır: bir developer'ın kodu review için göndermek yerine iki hafta boyunca tek başına bir feature üzerinde çalışmayı tercih etmesi. Bu tercih, review kültüründe belirli bir başarısızlık moduna işaret eder.

Sıkı review'ların ardındaki niyet sağlamdır. Uygulama ise pull request'i çoğu zaman bir tez savunmasına çevirir; karşıda da kişinin başarılı olmasına yardım etmektense hata bulmakla ilgilenen bir kurul oturur.

Continue reading...

]]> <![CDATA[GitHub Copilot ROI: Kurumsal Maliyet Analizi Çerçevesi]]> https://sph.sh/tr/posts/copilot-to-production-cost-analysis/ https://sph.sh/tr/posts/copilot-to-production-cost-analysis/ Mon, 08 Sep 2025 00:00:00 GMT Bir AI kodlama asistanının geri dönüşünü ölçmek, verimlilik-vekil metriklerini (tuş vuruşu hızı, tamamlama kabul oranı) aracın hareket ettirmesi gereken sonuçlardan (teslim döngü süresi, hata oranı, bakım maliyeti) ayırmayı gerektirir. Satıcı raporlarındaki rakamlar genellikle birinci kümedir; yatırımın kendini amorti edip etmediğini ikinci küme belirler. GitHub araştırmacılarının yürüttüğü kontrollü bir deney, dar kapsamlı bir görevde %55,8 daha hızlı tamamlanma ölçtü. Yaklaşık 5.000 yanıtlayanın teslimat sonuçlarını tarayan DORA'nın 2025 raporu ise AI benimsemesini teslimat verimiyle olumlu, teslimat kararlılığıyla hâlâ olumsuz ilişkili buluyor. İki bulgu aynı anda doğru olabilir ve bütçe tam da aradaki bu boşlukta erir.

Continue reading...

]]> <![CDATA[Veritabanı Query Profiling: Sistematik Optimizasyon Yolculuğu]]> https://sph.sh/tr/posts/database-query-profiling-100k-optimization/ https://sph.sh/tr/posts/database-query-profiling-100k-optimization/ Mon, 08 Sep 2025 00:00:00 GMT Yavaş veritabanı query'leri, SaaS ürünlerinde altyapı maliyetlerinin kontrolden çıkmasının en yaygın nedenidir: 8 saniye süren ürün aramaları ve 45 saniyede yüklenen dashboard'lar semptomlar, kök neden değildir. Sunucu eklemek semptomları bastırırken faturayı büyütür. Önce profiling yapın, yalnızca profiling'in açıklayamadığı kısmı ölçekleyin. PostgreSQL tarafında bu pgstatstatements ve EXPLAIN demek; MongoDB tarafında database profiler ve pipeline üzerinde explain planı demek.

Çok Kiracılı Bir SaaS'ta Semptomlar

Continue reading...

]]> <![CDATA[Mühendislik Takımlarında Lewis Deep Democracy: Sahte Konsensüsün Ötesinde]]> https://sph.sh/tr/posts/deep-democracy-engineering-teams/ https://sph.sh/tr/posts/deep-democracy-engineering-teams/ Mon, 08 Sep 2025 00:00:00 GMT Oybirliğiyle alınmış gibi görünen teknik kararların arkasında çoğu zaman gerçek bir mutabakat yoktur. Sebep çoğunlukla mühendislik yetersizliğinden çok rütbe farkları ve zayıf psikolojik güvenliktir. Arnold Mindell'in Deep Democracy yaklaşımı burada işe yarar bir varsayılan sunar: muhalefeti tasarım girdisi say, kararın yanına yaz ve azınlık endişesi haklı çıktığında devreye girecek inceleme tetikleyicileri tanımla.

Gölge Monolit

Pek çok mimari incelemede herkes açıkça katılıyor görünür, sonra altı ay sonra kimse endişesini dile getirmediği için karar sessizce tersine döner. Sessizlik onay diye okunur ve bu okumanın doğruluğu neredeyse hiç sınanmaz.

Continue reading...

]]> <![CDATA[AI Kod İncelemesi ile İnsan İncelemesi: Hangisi Neyi Yakalar]]> https://sph.sh/tr/posts/llm-code-review-ai-finds-what-humans-miss/ https://sph.sh/tr/posts/llm-code-review-ai-finds-what-humans-miss/ Mon, 08 Sep 2025 00:00:00 GMT İnsan kod incelemesi, öngörülebilir bir hata sınıfını kaçırır: tek başına bakıldığında düzgün görünen bir query builder içindeki ince SQL injection, kopyalandığı her serviste tekrarlanan aynı hatalı pattern, uzun bir haftanın sonunda atlanan güvenlik kontrolü. İnceleyiciler önlerindeki diff'e odaklanır; bu yüzden en deneyimli mühendis onaylasa bile sistemik ve kod tabanları arası sorunlar gözden kaçar.

Continue reading...

]]> <![CDATA[Microservislerden Modüler Monolite Geçiş]]> https://sph.sh/tr/posts/monolith-revenge-microservices-technical-debt/ https://sph.sh/tr/posts/monolith-revenge-microservices-technical-debt/ Mon, 08 Sep 2025 00:00:00 GMT Microservis mimarisi dağıtık monolit haline geldiğinde ekipler, kaçınmaya çalıştıkları sorunların tam ortasında kalır. Deployment coupling, veri tutarlılığı zorlukları ve koordinasyon yükü bunun görünen belirtileri.

Bu servisleri modüler monolite konsolide etmek geçerli bir mimari pattern. Yaklaşık 50 mühendis ve altındaki ekipler için makul varsayılan, ürün takımı başına iyi yapılandırılmış tek bir deployable. Bir modülü ancak ölçülebilir bir ihtiyaç operasyonel maliyeti karşıladığında servis olarak ayır.

Sepete Ürün Eklemek 47 Servise Dokunduğunda

Continue reading...

]]> <![CDATA[Node.js'ten Go'ya AWS Lambda Geçişi: Pratik Rehber]]> https://sph.sh/tr/posts/nodejs-to-go-serverless-migration-guide/ https://sph.sh/tr/posts/nodejs-to-go-serverless-migration-guide/ Mon, 08 Sep 2025 00:00:00 GMT Serverless faturaları beklenenden hızlı büyüme eğilimindedir ve takımların ilk uzandığı kollardan biri dil seçimidir. Node.js'den Go'ya geçiş bu kolun alışılmış adayı: aynı Lambda platformunda, aynı event payload'larıyla çalışan, bellekte az yer kaplayan derlenmiş bir binary.

İşe yarayan varsayılan dar kapsamlı. Tek bir serviste ölçülebilir bir hacim, gecikme veya bellek maliyeti problemi yoksa Node.js'de kal; varsa yalnızca o servisi taşı. Go, mantığı basit ve trafiği yüksek handler'larda kendini amorti eder. İki yılda oturmuş karmaşık business logic servisinde ise nadiren amorti eder; kararın zor yarısı da zaten ne zaman taşımamak gerektiğini görmektir.

Go Lambda'da Ne Zaman Mantıklı

Continue reading...

]]> <![CDATA[Moment.js Alternatifleri: Node.js Geçiş Rehberi ve Karşılaştırması]]> https://sph.sh/tr/posts/nodejs-zaman-yonetimi-zamana-hukmetmek/ https://sph.sh/tr/posts/nodejs-zaman-yonetimi-zamana-hukmetmek/ Mon, 08 Sep 2025 00:00:00 GMT Production sistemlerde zaman yönetimi, varsayılanların (yerel sistem saati, örtük timezone, new Date() ayrıştırması) düğümler, diller ve katmanlar arasında farklılaşması nedeniyle sessiz bir hata kaynağıdır. İstek güncel yerel bir tarih taşımasına rağmen "geçmiş tarihli işlem" hatası veren bir ödeme, genellikle istemcinin duvar saati, uygulama sunucusunun yorumu ve veritabanının saklama formatı arasında bir timezone-offset hatasıdır. Her yerde UTC kullanmak ve ofset dönüşümünü yalnızca görüntüleme sınırında yapmak bu hata sınıfını tamamen ortadan kaldırır; ancak her API, log, şema ve test fikstürü sınırında disiplin gerektirir.

Continue reading...

]]> <![CDATA[Metriklerin Ötesinde Observability: Sistem Hikaye Anlatıcılığı Sanatı]]> https://sph.sh/tr/posts/observability-beyond-metrics-system-storytelling/ https://sph.sh/tr/posts/observability-beyond-metrics-system-storytelling/ Mon, 08 Sep 2025 00:00:00 GMT Bütün dashboard'lar yeşil, her metrik eşiğinin içinde, ama müşteriler checkout'un çalışmadığını söylüyor. Toplulaştırılmış metrikler bileşenleri tek tek anlatır; bileşenlerin arasındaki yolda yaşayan bir hata hiçbirine görünmez.

Distributed tracing bu boşluğu kapatır. Tek bir trace, bir isteği dokunduğu her servis boyunca takip eder ve olayların hangi sırayla gerçekleştiğini kaydeder. Varsayılan yaklaşım şu: uçtan uca enstrümente edilmiş tek bir kullanıcı yolculuğu ve her span'a iliştirilmiş iş bağlamı.

Tek Bir Trace Neyi Gösterir

Continue reading...

]]> <![CDATA[Ürün ve Teknoloji Ekipleri Arasında Derinlemesine Demokrasi: Deadline Diktatörlüğünden İşbirlikçi Teslimata]]> https://sph.sh/tr/posts/product-tech-deep-democracy/ https://sph.sh/tr/posts/product-tech-deep-democracy/ Mon, 08 Sep 2025 00:00:00 GMT Ürün ve Mühendislik aynı scope üzerinde sık sık zıt yönlere çeker. Ürün altı haftaya üç ayın feature'ını ister; Mühendisliğin tahminleri on iki hafta gösterir; toplantı, hiçbirini tatmin etmeyen bir "uzlaşma" ile biter, buggy kod sevkiyatına ve yangın söndürmeyle geçen bir sonraki çeyreğe yol açar. Eksik olan bir karar verme sistemi.

Bu kısır döngüden çıkan ekipler farklı bir karar süreci işletir. Buradaki varsayılan, Arnold Mindell'ın "Derinlemesine Demokrasi" yaklaşımı: grup karara bağlamadan önce muhalif olanlar dahil her ses masaya gelir. Ürün ve mühendisliğe uygulandığında sprint planlama, pazarlık olmaktan çıkıp gücün, varsayımların ve ödünleşimlerin açıkça konuşulduğu bir tasarım oturumuna dönüşür.

Çekişmenin Faturası

Continue reading...

]]> <![CDATA[RFC'den Production'a: Implementation Hakkında Anlatmadıkları]]> https://sph.sh/tr/posts/rfc-to-production-implementation-reality/ https://sph.sh/tr/posts/rfc-to-production-implementation-reality/ Mon, 08 Sep 2025 00:00:00 GMT RFC'ler production'la temas ettikten sonra nadiren değişmeden kalır ve bu kendiliğinden bir başarısızlık sayılmaz. İncelemede temiz görünen mimari diyagramlar altı ay sonra karmaşıklaşır; timeline baskısı, eksik gereksinimler ve operasyonel gerçekler tasarımda hiç yer almayan trade-off'ları dayatır.

Sorunun kaynağı kötü tasarım ya da kötü mühendislik değil. Bu, iş kısıtları altında karmaşık sistem kurmanın olağan maliyeti. Asıl beceri, sinyali sürüklenmeden ayırmakta: bir boşluk, tasarımın inceleme sırasında bilemeyeceği bir gereksinimi karşılıyorsa sinyaldir; tasarıma uymak zahmetli geldiği için terk edilmişse sürüklenmedir. Bildirim sistemleri iyi bir örnek, çünkü spesifikasyonu kısa, operasyonel yüzeyi ise beklenenden geniştir.

Continue reading...

]]> <![CDATA[Ölçeklenebilir Kullanıcı Bildirim Sistemi: Mimari ve Veritabanı Tasarımı]]> https://sph.sh/tr/posts/user-notification-system-part-1-architecture/ https://sph.sh/tr/posts/user-notification-system-part-1-architecture/ Mon, 08 Sep 2025 00:00:00 GMT Çok kanallı bildirim sistemleri, ekipler bunları şablon-ve-gönder pipeline'ı olarak modellediğinde başarısız olur. Bildirim aslında kullanıcı başına verilen bir yönlendirme kararıdır: e-posta, SMS, push ve uygulama içi kanallar arasında dağıtılabilir, birleştirilebilir, bastırılabilir veya ertelenebilir. Açık bir router katmanı olmadan teslim garantileri çöker, kullanıcı tercihleri göz ardı edilir ve uyumluluk denetimi imkânsız hale gelir.

Continue reading...

]]> <![CDATA[Gerçek Zamanlı Bildirimler ve Çok Kanallı Teslimat: WebSocket, Push, Email ve Ötesi]]> https://sph.sh/tr/posts/user-notification-system-part-2-realtime-delivery/ https://sph.sh/tr/posts/user-notification-system-part-2-realtime-delivery/ Mon, 08 Sep 2025 00:00:00 GMT Bir bildirim sistemi aynı kişiye birbirine hiç benzemeyen kanallardan ulaşmak zorunda: dakikalarla ölçülen bir socket, iki gönderim arasında geçersizleşebilen bir push token, çoktan suppression listesine düşmüş olabilecek bir e-posta adresi.

WebSocket'te connection drain, push'ta token geçersizleşmesi, email'de bounce yönetimi: her mekanizmanın kendi sınırları, hata modları ve gecikme beklentisi var. WebSocket saniyenin altında teslimat isterken email için birkaç dakika kabul edilebilir. Aşağıda her kanalın teslimat desenleri ve hangi kanalın ne zaman devreye gireceğine karar veren koordinasyon katmanı var.

WebSocket Bağlantı Yönetimi

Bağlantı Durumunu Saklamak

Continue reading...

]]> <![CDATA[Ölçekte Bildirim Teslimatı Hatalarını Debug Etmek]]> https://sph.sh/tr/posts/user-notification-system-part-3-production-debugging/ https://sph.sh/tr/posts/user-notification-system-part-3-production-debugging/ Mon, 08 Sep 2025 00:00:00 GMT Bildirim sistemleri en kötü zamanlarda sessizce başarısız olur: yoğun yükte, bir lansman ya da kampanyanın bağımlı olduğu anda. Hoş geldin e-postaları gelmez, push timeout olur, uygulama içi alert'ler gecikir, ama dashboard'lar yeşil görünmeye devam eder, çünkü her alt-sistem izole bakıldığında sorunsuzdur.

İzleme sinyallerini kullanıcıya olan uzaklığına göre sırala ve kontrol etmediğin her bağımlılığın önüne bir circuit breaker koy, çünkü CPU ve memory alertleri enkazı anlatır ama hangi alt-sistemin başlattığını söylemez.

Yoğun Trafik Altında Kademeli Hata

Continue reading...

]]> <![CDATA[Bildirim Analitikleri ve Performans Optimizasyonu: A/B Testleri, Metrikler ve Ölçekte Ayarlama]]> https://sph.sh/tr/posts/user-notification-system-part-4-analytics-optimization/ https://sph.sh/tr/posts/user-notification-system-part-4-analytics-optimization/ Mon, 08 Sep 2025 00:00:00 GMT Bildirim sistemleri, kapsamlı analitikler, sistematik A/B testleri ve performans optimizasyonu ile temel teslimat mekanizmalarından büyüme altyapısına dönüşür.

Bildirim sistemleri temel işlevsellik ve kararlılığa ulaştığında, organizasyonlar yeni bir zorlukla karşılaşıyor: basit teslimat metriklerinin ötesine geçerek iş büyümesini yönlendirmek. Ürün ekipleri etkileşim oranları, optimal zamanlama ve içerik etkinliği hakkında yanıtlara ihtiyaç duyuyor. Engineering ekipleri hacim büyüdükçe performans darboğazlarıyla karşılaşıyor. Geleneksel izleme yaklaşımları, sistemlerin maliyet verimliliğini korurken milyonlarca kullanıcıyı desteklemesi gerektiğinde yetersiz kalıyor.

Continue reading...

]]> <![CDATA[Etkili RFC Nasıl Yazılır: Mühendisler İçin Rehber]]> https://sph.sh/tr/posts/writing-effective-rfcs-principal-engineer-guide/ https://sph.sh/tr/posts/writing-effective-rfcs-principal-engineer-guide/ Mon, 08 Sep 2025 00:00:00 GMT Mimari anlaşmazlıklar geç ortaya çıkar: tam da feature yarı yapılmışken ve rotayı değiştirmenin maliyeti en yüksekken. Aynı karar üzerine Slack thread'leri haftalarca sürüklenir, iyi fikirler komitede ölür ve ekipler herkesin "anlaştığı" ama farklı yorumladığı sistemleri sevk eder. RFC süreci, bu tartışmayı implementasyon cevabı kilitlemeden önce ileri taşımak için vardır.

Etkili bir RFC dokümantasyon değildir; ekibi bir problemi sonuna kadar düşünmeye ve kalıcı bir karara varmaya zorlayan artefakttır. Biçimi organizasyon büyüklüğüne göre değişir: startup'ta bir-iki sayfa yeterken, enterprise daha fazla yapı ister. Buradaki örnek bir kullanıcı bildirim sistemi RFC'si; formatın neyi kazandırdığını da nerede tökezlediğini de aynı örnek üzerinden gösteriyor.

Continue reading...

]]> <![CDATA[AWS CDK ile URL Kısaltıcı 3. Bölüm: Güvenlik ve Özel Alan Adları]]> https://sph.sh/tr/posts/aws-cdk-link-shortener-part-3/ https://sph.sh/tr/posts/aws-cdk-link-shortener-part-3/ Fri, 05 Sep 2025 00:00:00 GMT Production bir link shortener kurmak, kısa URL üretmekten fazlasını gerektirir. Meşru trafiği kaldırırken kötüye kullanımı engelleyen güvenlik önlemleri de gerekir. Link shortener'lar; zararlı içerik dağıtmak, güvenlik filtrelerini atlatmak ve phishing kampanyası yürütmek isteyen kötü niyetli aktörler için çekici hedeflerdir.

Modern link shortener servisleri, input validasyonu, rate limiting, authentication ve gerçek zamanlı monitoring'i birleştiren defense-in-depth koruma gerektirir. Bu yaklaşım hem servisinizi hem de kısaltılmış linklere tıklayan kullanıcıları korur.

1. Bölüm ve 2. Bölüm'de temel yapı ve redirect fonksiyonalitesini oluşturduk. Şimdi bir oyuncak projeyi production servisten ayıran gelişmiş özellikleri ve güvenlik önlemlerini ekleyelim.

Continue reading...

]]> <![CDATA[AWS CDK URL Kısaltıcı Bölüm 4: Production Deployment]]> https://sph.sh/tr/posts/aws-cdk-link-shortener-part-4/ https://sph.sh/tr/posts/aws-cdk-link-shortener-part-4/ Fri, 05 Sep 2025 00:00:00 GMT Production optimizasyonu, gerçek trafik altında performansın tutmasıyla ilgilidir. Staging'de kusursuz çalışan bir infrastructure, trafik ilk kez sıçradığında ölçeklendirme darboğazlarını ortaya çıkarabilir.

En sık gözden kaçan nokta, database'in peak yük yerine steady-state trafiğe göre provisionlanmasıdır. Normal operasyona göre boyutlandırılmış bir DynamoDB table, kampanya veya ürün lansmanında trafik 10x arttığında darboğaza dönüşür.

Bölüm 1-3'te temel yapıyı, core fonksiyonları ve güvenliği kurduk. Sırada production katmanı var: environment konfigürasyonundan blue-green deployment'a kadar.

Dört Deployment Ortamı

Continue reading...

]]> <![CDATA[AWS CDK URL Shortener Part 5: Ölçeklendirme ve Uzun Vadeli Bakım]]> https://sph.sh/tr/posts/aws-cdk-link-shortener-part-5/ https://sph.sh/tr/posts/aws-cdk-link-shortener-part-5/ Fri, 05 Sep 2025 00:00:00 GMT Tek bölgede çalışan bir CDK link shortener, trafik coğrafyalara yayıldıkça gecikme ve erişilebilirlik sorunları göstermeye başlar. DynamoDB tablosu da tek hata noktasına dönüşür. Multi-region replikasyon ve bir disaster recovery planı olmadan, tek bir bölgesel kesinti redirect servisinin tamamını devre dışı bırakır. Tercih edilmesi gereken varsayılan kurulum şu: global bir CloudFront dağıtımının arkasında DynamoDB Global Tables ve bir bölge tamamen düştüğünde devreye giren Route 53 failover yönlendirmesi.

1. Bölümde, link shortener altyapısının temelini kurmuştuk. Bu bölüm onu global ölçeğe taşıyor ve çalışır durumda tutan operasyonel katmanı ekliyor: kapasite planlaması, yedekleme otomasyonu ve uzun ömürlü bir sistemin biriktirdiği teknik borcun bakımı.

Continue reading...

]]> <![CDATA[AWS API Gateway ve CDK ile API Versiyonlama Rehberi]]> https://sph.sh/tr/posts/api-versioning-aws-cdk-complete-guide/ https://sph.sh/tr/posts/api-versioning-aws-cdk-complete-guide/ Thu, 04 Sep 2025 00:00:00 GMT Yol tabanlı versiyonlama (/v1/users, /v2/users) ve versiyon başına tutulan açık bir yaşam döngüsü kaydı, API Gateway üzerinde tercih edilmesi gereken varsayılan yaklaşımdır. Sürekli değişen tek bir endpoint'e göre daha fazla altyapı maliyeti getirir; buna karşılık sizin takviminize göre güncelleme yapamayan istemcilerle birlikte ayakta kalan yaklaşım budur.

Continue reading...

]]> <![CDATA[Auth0 vs Firebase Auth vs Cognito vs Supabase Auth: Hangisini Seçmeli?]]> https://sph.sh/tr/posts/auth-providers-mobile-web-api-comparison/ https://sph.sh/tr/posts/auth-providers-mobile-web-api-comparison/ Thu, 04 Sep 2025 00:00:00 GMT Kimlik doğrulama sağlayıcısı seçimi; geliştirme hızını, uyumluluk tavanını ve aylık faturayı yıllarca belirler. Sonradan sağlayıcı değiştirmek, bir ürünün göze alabileceği en riskli geçişlerden biridir. Başlangıç için doğru varsayılan, ana platformunuza zaten yerleşik olan yönetilen sağlayıcıdır: mobil öncelikli tüketici uygulamaları için Firebase Auth, PostgreSQL tabanlı ürünler için Supabase Auth, AWS-native serverless yığınlar içinde Cognito, SAML/SSO ve uyumluluk belgeleri sözleşme şartı olduğunda Auth0. Özel JWT bir öğrenme alıştırması olarak kalır.

Continue reading...

]]> <![CDATA[Auth0 ile Çoklu Audience: Micro Frontend'lerde Token Yönetimi]]> https://sph.sh/tr/posts/auth0-multi-audience-micro-frontends-token-management/ https://sph.sh/tr/posts/auth0-multi-audience-micro-frontends-token-management/ Thu, 04 Sep 2025 00:00:00 GMT Auth0 access token'ı tek bir audience taşır. Üç ayrı API ile konuşan bir micro frontend kümesi bu yüzden üç token'a ihtiyaç duyar ve kısıtın ilk okunuşu "üç kez login" der. Gerek yok. Auth0 session'ını shell application'da tek noktada tutun. Shell, bu session'ı istendiğinde audience başına access token'a çevirir ve token'ları origin'i doğrulanmış bir postMessage kanalıyla micro frontend'lere dağıtır. Diğer düzenlemeler (micro frontend başına ayrı Auth0 application, ince taneli scope'larla tek geniş audience, sunucu tarafında token değişimi) daha pahalıya mal olur ve daha azını verir.

Continue reading...

]]> <![CDATA[React Native'de Auth0 Oturum Yönetimi ve Biyometrik Giriş]]> https://sph.sh/tr/posts/auth0-react-native-session-management-biometrics/ https://sph.sh/tr/posts/auth0-react-native-session-management-biometrics/ Thu, 04 Sep 2025 00:00:00 GMT Mobil uygulamalarda oturum yönetimi, web geliştiricilerinin nadiren karşılaştığı zorluklar çıkarır. Bir mobil uygulama; arka plan durumlarını, ağ kesintilerini, biyometrik kimlik doğrulamayı ve platforma özgü güvenlik kısıtlamalarını, kullanıcı deneyimini bozmadan yönetmek zorundadır. React Native tarafında ayakta kalan varsayılan şu: refresh token rotasyonunu Auth0 tenant'ına bırakın, token'ları Keychain veya Keystore içinde biyometrik kapının arkasında tutun ve 401'e tepki vermek yerine süre dolmadan yenileyin.

Continue reading...

]]> <![CDATA[AWS CDK Link Kısaltıcı Bölüm 1: Proje Kurulumu & Temel Altyapı]]> https://sph.sh/tr/posts/aws-cdk-link-shortener-part-1/ https://sph.sh/tr/posts/aws-cdk-link-shortener-part-1/ Thu, 04 Sep 2025 00:00:00 GMT AWS üzerinde link kısaltıcı yapmak; yönlendirme gecikmesi, URL doğrulama ve link bazlı analitik zorunlu hale gelene kadar kolay görünür. Aylık milyonlarca yönlendirmede her mimari karar (depolama motoru, caching katmanı, CDN konumu) hem maliyeti hem de kuyruk gecikmesini doğrudan etkiler.

Sağlam duran varsayılan şu: tek bir DynamoDB tablosu, her rota için ayrı ve küçük birer Lambda, yönlendirme yolunun önünde CloudFront. Proje yapısını ve tablo şemasını ilk günden doğru kurarsanız serinin sonraki bölümleri migration değil ekleme olur. Yönlendirme döngüleri, kötü niyetli URL'ler ve kötüye kullanım trafiği de sonraya bırakılacak başlıklar değil: create handler'ın yazmadan önce neyi doğrulayacağını bunlar belirler.

Mimariye Genel Bakış

Continue reading...

]]> <![CDATA[AWS CDK Link Kısaltıcı Bölüm 2: Temel Fonksiyonlar & API Geliştirme]]> https://sph.sh/tr/posts/aws-cdk-link-shortener-part-2/ https://sph.sh/tr/posts/aws-cdk-link-shortener-part-2/ Thu, 04 Sep 2025 00:00:00 GMT Bir link kısaltıcı aslında bir redirect motorudur. Kısa kod araması ve HTTP 301 yanıtı, kritik gecikme bütçesindeki tek işlemlerdir; her ikisinin de yüksek eşzamanlılıkta bile kullanıcının anlık algıladığı eşiğin (yaklaşık 200ms) altında kalması gerekir. Bu sıcak yolun etrafındaki iş mantığı (analitik, hız sınırlama, link süresinin dolması, özel slug'lar) redirect'i engellememelidir; redirect handler'a eklenen her özelliğin bedeli doğrudan gecikme olarak ödenir.

Bu serinin Bölüm 1'i temeli kurdu (DynamoDB tablosu, API Gateway, temel Lambda). Sıra çekirdek işlevsellikte: DynamoDB cache'li redirect Lambda'sı, kısa kod oluşturma ve yönetme API'si, yan kanal üzerinden analitik olay yayını ve upstream servisler bozulduğunda redirect'i hızlı tutan hata yönetimi desenleri.

Continue reading...

]]> <![CDATA[AWS Fargate 101: Serverless Container Nedir, Nasıl Çalışır?]]> https://sph.sh/tr/posts/aws-fargate-101-serverless-containers/ https://sph.sh/tr/posts/aws-fargate-101-serverless-containers/ Thu, 04 Sep 2025 00:00:00 GMT EC2 üzerinde container çalıştırmak; OS yamalarını, cluster kapasitesini ve host düzeyindeki hataları yönetmek demektir. Bu iş, uygulama karmaşıklığıyla değil, host sayısıyla birlikte büyür. AWS Fargate bu katmanı ortadan kaldırır: AWS'ye bir container image'ı ile CPU/bellek çiftini verirsiniz, task'ı hiç giriş yapmayacağınız bir altyapıda çalıştırır.

Yeni container workload'ları için makul varsayılan Fargate'tir. Hesaplama birimi başına daha fazla ödersiniz, karşılığında host bakımını tamamen bırakırsınız. Bu takasın ters döndüğü durumlar bellidir: GPU iş yükleri, privileged container'lar ve Reserved Instance ya da Spot'un zaten ucuzlattığı sürekli yüksek kullanım. Kararın büyük kısmı, workload'un bu çizginin hangi tarafında durduğunu görmekten ibaret.

Continue reading...

]]> <![CDATA[AWS Fargate Production Pattern'leri: Maliyet, İzleme, Blue-Green]]> https://sph.sh/tr/posts/aws-fargate-102-advanced-patterns/ https://sph.sh/tr/posts/aws-fargate-102-advanced-patterns/ Thu, 04 Sep 2025 00:00:00 GMT Fargate 101'de temelleri ele aldık. Aşağıdaki pattern'ler, o temelden sonra bozulan şeylerden geliyor: fatura, Fargate'in sizden sakladığı altyapı katmanı ve geri dönüş yolu olması gereken deployment'lar. Sırasıyla maliyet optimizasyonu, stateful container'lar, monitoring ve blue-green deployment.

Maliyet Optimizasyonu

Fargate'in aynı compute için EC2'den daha pahalı olduğunu söylemiştik. Bu farkın büyük kısmını dört kaldıraç kapatır: Spot kapasite, right-sizing, ARM ve Savings Plans.

Kesintiye Dayanıklı İşler için Fargate Spot

Fargate Spot %70'e varan tasarruf sağlar; karşılığında AWS container'larınızı 2 dakikalık uyarıyla sonlandırabilir. Kulağa riskli gelse de, doğru kurgulandığında birçok workload için sorunsuz çalışır.<...

Continue reading...

]]> <![CDATA[AWS Fargate Sorun Giderme: ENI Limitleri, Timeout, Debugging]]> https://sph.sh/tr/posts/aws-fargate-103-production-lessons/ https://sph.sh/tr/posts/aws-fargate-103-production-lessons/ Thu, 04 Sep 2025 00:00:00 GMT Fargate, ENI limitleri, memory leak'ler ve subnet tükenmesi gibi kaynak kısıtlarını yeşil dashboard'ların arkasında gizler; ta ki bir trafik artışı bunları görmezden gelmenin imkânsız hâle getirdiği ana kadar. Bu arızaların ortak bir örüntüsü var: temel neden standart CloudWatch metrikleriyle görünmez, bu yüzden task'lar yanıltıcı hatalarla takılır ya da çöker. Vakaların çoğunu beş arıza biçimi açıklar ve her birinin dakikalar içinde sonuç veren bir kontrolü vardır.

Bu serinin önceki bölümleri (101, 102) temelleri ve gelişmiş pattern'leri ele aldı. Serideki bir sonraki bölüm olan 104 Infrastructure-as-Code deployment pattern'lerini kapsar.

ENI Tükenmesi

Continue reading...

]]> <![CDATA[AWS Fargate Deploy Etmek: CDK vs Terraform vs SAM]]> https://sph.sh/tr/posts/aws-fargate-104-iac-deep-dive/ https://sph.sh/tr/posts/aws-fargate-104-iac-deep-dive/ Thu, 04 Sep 2025 00:00:00 GMT Fargate servislerini CDK, Terraform veya SAM ile deploy etmek çalışan bir altyapı üretir; ancak yanlış araç seçimi her yeni servisle katlanarak büyüyen bir bakım yükü yaratır. Yalnızca AWS üzerinde yaşayacak yeni bir servis için varsayılan CDK'dır: üst düzey construct'ları düzinelerce CloudFormation kaynağını birkaç satıra indirir. Terraform'a geçmek, aynı değişim yüzeyini birden fazla ekip paylaştığında ya da ikinci bir bulut ihtimali gerçekçiyse anlam kazanır. SAM ise ancak Fargate, Lambda'nın yanında küçük bir ayrıntı kaldığında uygundur.

Aradaki fark ilk deployment'ta pek görünmez. Bir yıl sonra görünür: bir değişiklik nasıl inceleniyor, drift nasıl fark ediliyor ve her yeni servis kaç satır koda mal oluyor.

Fargate için IaC Araç Karşılaştırması

Continue reading...

]]> <![CDATA[AWS Lambda Cold Start Optimizasyonu: Production Dersleri]]> https://sph.sh/tr/posts/aws-lambda-guide-101-cold-start-optimization/ https://sph.sh/tr/posts/aws-lambda-guide-101-cold-start-optimization/ Thu, 04 Sep 2025 00:00:00 GMT Cold start gecikmesinin faturasını kullanıcı öder. İnteraktif bir API'nin arkasındaki bir Lambda function'ında en ucuz kazançlar üç yerden gelir: seçtiğin runtime, deployment package boyutu ve handler çalışmadan önce initialization kodunun yaptığı iş. Önce bu üçüyle uğraş.

Provisioned concurrency, kapsadığı isteklerin üstünden init maliyetini alır; latency SLA'i olan bir checkout endpoint'i için doğru cevap da budur. Provisioned sayısını aşan trafik on-demand environment'lara taşar ve orada yine cold start'a yakalanabilir; yani scaling policy en az rezervasyon kadar önemli. Yalnız faturayı, devreye almadan önce hesap yapmayı gerektirecek kadar değiştiriyor.

Cold Start'ın Bedeli Nerede Ödenir

Continue reading...

]]> <![CDATA[AWS Lambda Memory Allocation ve Performance Tuning: Kapsamlı Rehber]]> https://sph.sh/tr/posts/aws-lambda-guide-102-memory-performance-tuning/ https://sph.sh/tr/posts/aws-lambda-guide-102-memory-performance-tuning/ Thu, 04 Sep 2025 00:00:00 GMT Serinin ilk bölümünde cold start'ları optimize ettikten sonra, sıradaki zorluk Lambda function'larınızın warm olduklarında verimli çalışmasını sağlamak. Memory allocation, etki alanı en geniş konfigürasyon ayarı; tek bir değer aynı anda CPU payını, execution süresini ve faturayı belirliyor.

Pratik varsayılan: 1024 MB ile başlayın, sonra yalnızca ölçülmüş bir eğrinin gösterdiği yöne doğru hareket edin. 128 MB varsayılanı hesaplama yapan hiçbir function için doğru değil; doğrudan 3008 MB'ye sıçrama refleksi ise çoğunlukla tek thread'li kodun harcayamayacağı bir kapasite satın alır.

Memory boyutu yalnızca bir girdi. Taşımaya değer model şu: ayrılan memory, onunla birlikte gelen CPU ve ikisinden doğan GB-saniye faturası.

Lambda'nın Memory-CPU Modeli

...

Continue reading...

]]> <![CDATA[AWS Lambda Production Monitoring ve Debugging: Kanıtlanmış Stratejiler]]> https://sph.sh/tr/posts/aws-lambda-guide-103-production-monitoring-debugging/ https://sph.sh/tr/posts/aws-lambda-guide-103-production-monitoring-debugging/ Thu, 04 Sep 2025 00:00:00 GMT Lambda function'ları production'da sessizce başarısız olur; varsayılan CloudWatch metrikleri, cold-start gürültüsü ve eksik distributed trace'ler bir araya geldiğinde kök nedeni gizler. Yapılandırılmış bir observability stratejisi olmadan debugging, veri odaklı analizden baskı altında tahmine kayar. Çoğu Lambda iş yükünde işe yarayan kurulum küçüktür: business sonuçlarına bağlanmış custom metrikler, X-Ray active tracing ve her satırında request ID taşıyan JSON log'lar.

Bu üç sinyal farklı işleri görür. Metrikler bir şeyin bozulduğunu, trace'ler nerede bozulduğunu, log'lar ise nedenini söyler. Birini eksik bıraktığınızda diğer ikisi en kötü anda ortaya çıkan bir boşluk bırakır: hata log'lamadan timeout'a düşen bir ödeme handler'ı ya da hiçbir alarmı tetiklemeyen bir retry fırtınas...

Continue reading...

]]> <![CDATA[AWS Lambda Maliyet Optimizasyonu: VPC, Layers ve Advanced Pattern'ler]]> https://sph.sh/tr/posts/aws-lambda-guide-104-advanced-patterns-cost-optimization/ https://sph.sh/tr/posts/aws-lambda-guide-104-advanced-patterns-cost-optimization/ Thu, 04 Sep 2025 00:00:00 GMT Serverless faturaları ilk ayda kimseyi şaşırtmaz. Ölçek büyüdükçe şaşırtır. Fazla ayrılmış memory, boşta duran provisioned concurrency ve monolitik bir handler aynı invocation sayısını her ay yeniden çarpar; Lambda'nın invocation başına fiyatlandırması bu üç hatayı yapması ucuz, taşıması pahalı hale getirir.

Birkaç düzine function'dan sonra sorular değişir. Cold start'ı bozmadan dependency nasıl paylaşılır, VPC bağlantısı ne zaman maliyetine değer, hesaplar arası erişim nasıl güvenli kurulur ve fatura aslında nereye gider? Son sorunun yanıtı gösterişsiz: başka hiçbir şeye dokunmadan önce memory ve concurrency ayarlarını CloudWatch verisiyle denetleyin, çünkü konfigürasyon kayması genellikle kod seviyesindeki optimizasyonun kazandırdığından fazlasına mal olur.

Continue reading...

]]> <![CDATA[Middy Alternatifleri: Özel AWS Lambda Middleware Framework'ü Geliştirme]]> https://sph.sh/tr/posts/aws-lambda-middleware-middy-custom-framework/ https://sph.sh/tr/posts/aws-lambda-middleware-middy-custom-framework/ Thu, 04 Sep 2025 00:00:00 GMT Middy, küçük bir Lambda filosunun tipik middleware ihtiyaçlarını karşılar ama jenerik middleware-zinciri modelinin dengeleri, bir servis ortak bir middleware yığınını paylaşan yaklaşık 50 fonksiyona ulaştığında ölçülebilir hale gelir: çağrı başına ek yük, middleware zincirinin cold-start maliyeti ve ortak bir wrapper'ın başka türlü bağlantısız fonksiyonlar arasında yarattığı kenetlenme. Bu ölçekte soru şuna döner: Middy'nin soyutlamaları üzerine katmanlamaya devam mı edilir, AWS Lambda Powertools ile değiştirilir mi, yoksa yalnızca filonun gerçekten kullandığı hook'lar için ödeme yapan projeye özel bir middleware framework'ü mü yazılır.

Continue reading...

]]> <![CDATA[AWS Lambda Middleware ile Middy - Temiz Kod ve En İyi Uygulamalar]]> https://sph.sh/tr/posts/aws-lambda-middleware-middy-introduction/ https://sph.sh/tr/posts/aws-lambda-middleware-middy-introduction/ Thu, 04 Sep 2025 00:00:00 GMT Lambda handler'ları zamanla aynı girişi biriktirir: JSON body'yi parse et, doğrula, hataları yakala, CORS ve güvenlik header'larını ekle. Her endpoint bunu yeniden yazar ve her kopya bir öncekinden biraz uzaklaşır.

Middy, API Gateway arkasındaki Node.js handler'ları için makul bir varsayılan. Handler'ı birbirine geçen middleware katmanlarıyla sarar; parse, doğrulama, hata biçimlendirme ve header'lar tek bir ortak zincirde toplanır, her fonksiyonda yeniden yazılmaz. Bedeli fazladan bir bağımlılık ve bir miktar cold start yükü, bu yüzden bazı fonksiyon tipleri Middy'siz daha iyi çalışır.

Middy Nedir?

Continue reading...

]]> <![CDATA[AWS Lambda Performans Optimizasyonu: 10ms Altı Gecikme]]> https://sph.sh/tr/posts/aws-lambda-millisecond-optimization-guide/ https://sph.sh/tr/posts/aws-lambda-millisecond-optimization-guide/ Thu, 04 Sep 2025 00:00:00 GMT Latency-kritik Lambda iş yükleri warm path'te kazanılır ya da kaybedilir. Dikkat çeken şey cold start olsa da, bir isteği tek haneli milisaniyede yanıtlayan fonksiyon aslında üç sorunun cevabıdır: handler'ı hangi runtime yüklüyor, invocation başına kaç network handshake yapılıyor ve fonksiyona ne kadar memory verilmiş.

Başlangıç için varsayılan: hot path'te derlenen bir runtime, handler dışında oluşturulan client'lar, arkada DynamoDB veya ElastiCache ve tahminle değil AWS Lambda Power Tuning ile seçilen memory. Node.js de aynı aralığa inebilir; ama bunun için bundle disiplini çok daha sıkı olmalı.

Milisaniyeler Nereye Gidiyor

Continue reading...

]]> <![CDATA[S3 Presigned URL ile Büyük Dosya Yükleme: Lambda ve CDK]]> https://sph.sh/tr/posts/aws-lambda-s3-signed-urls-large-file-uploads/ https://sph.sh/tr/posts/aws-lambda-s3-signed-urls-large-file-uploads/ Thu, 04 Sep 2025 00:00:00 GMT Dosya yüklemelerini Lambda üzerinden geçirmek ilk akla gelen tasarımdır ve dosyalar büyüyene kadar da iş görür. API Gateway bir REST API isteğinin gövdesini 10 MB, Lambda ise senkron çağrı payload'ını 6 MB ile sınırlar; dolayısıyla 2 GB'lık bir video fonksiyona hiç ulaşmaz. Payload sınırın altında kaldığında bile transfer sürdüğü her saniye için Lambda faturalanır.

Birkaç megabaytın üzerindeki dosyalarda daha iyi varsayılan S3 presigned URL'dir. Lambda bir URL imzalayıp döner, client byte'ları doğrudan S3'e PUT eder, nesne yerine oturunca S3 event notification bir işleme fonksiyonunu uyandırır. Bedeli şudur: Lambda'nın akış sırasında uyguladığı kontroller (dosya tipi, boyut limiti, virüs taraması) ya imzalama anına ya da sonraki event handler'a taşınmak zorundadır.

Continue reading...

]]> <![CDATA[AWS Lambda ve TypeScript: Production İçin En İyi Uygulamalar]]> https://sph.sh/tr/posts/aws-serverless-typescript-guide/ https://sph.sh/tr/posts/aws-serverless-typescript-guide/ Thu, 04 Sep 2025 00:00:00 GMT EC2 üzerinde çalışan geleneksel bir Express.js API'si sabit maliyet, öngörülebilir ölçeklendirme ve %99.9 uptime sunar. Lambda'ya geçiş kararı genellikle belirli bir uyumsuzluktan doğar: ayda bir kez, 10 dakikadan kısa sürede 50.000 webhook işlemesi gereken bir özellik.

Aylık 10 dakikalık bir yoğunluk için EC2 instance'larını 7/24 çalışır tutmak israftır; Lambda bu boşta bekleme maliyetini ortadan kaldırır. Karşılığında farklı bir hata kümesi getirir: hesap genelinde geçerli bir concurrency limiti, kritik yol üzerindeki cold start'lar ve dikkatsiz tek bir DynamoDB Scan'inin çevresindeki tüm compute'tan pahalıya geldiği bir faturalama modeli.

Serverless'a Yaygın İtirazlar

Continue reading...

]]> <![CDATA[Mühendislik Ekiplerinde Bus Factor: Bilgi Riski Nasıl Azaltılır]]> https://sph.sh/tr/posts/bus-factor-knowledge-management-engineering-teams/ https://sph.sh/tr/posts/bus-factor-knowledge-management-engineering-teams/ Thu, 04 Sep 2025 00:00:00 GMT Bir sisteme dair kritik bilgi tek bir kişinin kafasında toplandığında o kişi tek hata noktasına dönüşür. İşte bus factor riski budur. Asıl can yakan kısım bu bilginin çoğu zaman yazıya dökülmemiş olmasıdır. Ödeme akışları, dolandırıcılık tespitinin incelikleri ve herkesin güvendiği deploy adımları mühendisle birlikte kapıdan çıkar; toparlanma ise tam bir olay patlak verdiği anda yavaşlar. Kritik yollardan başlayın: önce onları belgeleyin, sonra bu dokümantasyonu sistemi kurmamış birine verip nerede takıldığına bakın.

Kazara Oluşan Tek Hata Noktası

"Bus factor" ekip dayanıklılığını ölçmenin biraz karamsar bir yolu: Projeniz sürdürülemez hale gelmeden önce kaç kişinin ayrılması gerekir? Bu sayı bir ise konumunuz tehlikelidir.

Continue reading...

]]> <![CDATA[Circuit Breaker Pattern: Zincirleme Hataları Önleyen Dayanıklı Mikroservisler]]> https://sph.sh/tr/posts/circuit-breaker-pattern-resilient-microservices/ https://sph.sh/tr/posts/circuit-breaker-pattern-resilient-microservices/ Thu, 04 Sep 2025 00:00:00 GMT Yavaş bir bağımlılık, çökmüş olandan daha tehlikelidir: 30 saniye timeout bekleyen request'ler thread pool'ları tüketir ve hatayı sağlıklı servisler üzerinden upstream'e yayar. Bir kapsama mekanizması olmadan, tek bir degraded downstream çağrısı tüm dağıtık sistemi saniyeler içinde doyurabilir. Circuit Breaker pattern'i bu hatayı üç state ve iki sayıyla kapsama alır: request timeout'u ve breaker'ı trip eden error rate. En kritik olanı timeout: client kütüphanesinin varsayılan değeri yerine P99 latency'nizin iki-üç katı. Böyle ayarlandığında breaker, thread pool tükenmeden önce trip eder.

Problem: Yavaş Yanıt Veren Bağımlılıkların Bedeli

Continue reading...

]]> <![CDATA[AWS Lambda, EventBridge ve DynamoDB ile CQRS]]> https://sph.sh/tr/posts/cqrs-pattern-serverless-nodejs/ https://sph.sh/tr/posts/cqrs-pattern-serverless-nodejs/ Thu, 04 Sep 2025 00:00:00 GMT CQRS (Command Query Responsibility Segregation), yazma işlemlerini (commands) okuma işlemlerinden (queries) ayıran bir mimari pattern'dir. Aynı modeli iki iş için birden kullanmak yerine her taraf kendi işine uygun bir şekil alır: yazma tarafı doğrular ve saklar, okuma tarafı soruları hızlıca yanıtlar.

Ayrımı, iki iş yükünün şekli gerçekten farklıysa yap: 10:1 veya daha yüksek okuma-yazma oranı, farklı gecikme bütçeleri ya da yazma için optimize edilmiş bir şemanın karşılayamadığı query pattern'leri. Aşağıdaki kurulum her taraf için ayrı bir DynamoDB tablosu, her yol için ayrı bir Lambda fonksiyonu ve read model'i güncel tutan event'leri taşıyan EventBridge kullanıyor. Okuma ile yazma birbirine benziyorsa pattern yalnızca hareketli parça ekler.

Temel Prensip

Continue reading...

]]> <![CDATA[Veritabanı Nasıl Seçilir: SQL, NoSQL, NewSQL ve Edge Karşılaştırması]]> https://sph.sh/tr/posts/database-selection-comprehensive-guide/ https://sph.sh/tr/posts/database-selection-comprehensive-guide/ Thu, 04 Sep 2025 00:00:00 GMT Bir iş yükü için yanlış veritabanı motoru seçmek, ilerleyen süreçte pahalı migration'lara zemin hazırlar: MongoDB üzerinde 1.000 kayıtla sorunsuz çalışan bir ürün kataloğu, doğru şema ve index tasarımı olmadan 100.000 kayıtta tüm koleksiyon taramalarına dönüşebilir. Sorunun kökeni veri modeli ile erişim örüntüsü arasındaki uyumsuzluktur, veritabanının kendisi değil. SQL, NoSQL, NewSQL ve edge veritabanı kategorilerinin her biri, ilk migration zorunlu hale gelmeden doğru seçime yön veren somut trade-off'lar taşır.

Continue reading...

]]> <![CDATA[Dead Letter Queue Stratejileri: Dayanıklı Olay-Güdümlü Sistemler için Production-Ready Kalıplar]]> https://sph.sh/tr/posts/dead-letter-queue-production-strategies/ https://sph.sh/tr/posts/dead-letter-queue-production-strategies/ Thu, 04 Sep 2025 00:00:00 GMT Dead Letter Queue, bir tüketicinin retry bütçesini tükettikten sonra işleyemediği mesajları tutan kuyruktur. DLQ olmadan bir poison pill ya birincil kuyruğu baştan (head-of-line) tıkar ya da başarısız handler ile birlikte sessizce kaybolur; her iki sonuçta da hem event hem de bir şeylerin yanlış gittiğine dair operasyonel sinyal kaybedilir. DLQ, "işlenecek mesajlar" ile "insan ya da tool müdahalesi gerektiren mesajlar" arasındaki görev ayrımıdır ve yalnızca etrafındaki retry politikası, uyarı ve replay araçları birlikte tasarlandığında işe yarar.

Continue reading...

]]> <![CDATA[Altyapı Olarak Dokümantasyon: Mühendislik Takımlarında Bilgiyi Ölçeklendirme]]> https://sph.sh/tr/posts/documentation-as-infrastructure-scaling-knowledge/ https://sph.sh/tr/posts/documentation-as-infrastructure-scaling-knowledge/ Thu, 04 Sep 2025 00:00:00 GMT Dokümantasyon borcu, mühendislik takımlarını yanlış kişi ayrılana kadar fark edilmeyen şekillerde yavaşlatır. Maliyet bir ödeme olayında, bir migration'da ya da bir denetimde ortaya çıkar: yazılı prosedür mevcuttur ama derin sistem anlayışı yoktur. O anı atlatan dokümantasyonun üç katmanı vardır: RFC ve ADR olarak yakalanan kararlar, sistemlerin kendisinden türetilen sistem referansı ve gerçek örneklerle yazılmış süreç dokümanları. Geri kalan her şey, bu üç katmanı güncel tutan araçlar ve inceleme alışkanlıklarıdır.

Wiki Mezarlıkları ve README Ruleti

Continue reading...

]]> <![CDATA[Kafka vs SQS vs EventBridge: Hangisini Seçmeli?]]> https://sph.sh/tr/posts/event-driven-systems-tools-comparison/ https://sph.sh/tr/posts/event-driven-systems-tools-comparison/ Thu, 04 Sep 2025 00:00:00 GMT Olay güdümlü araç seçimi hype'tan çok üç şekilden birine oturtmakla ilgili: kuyruk, fan-out topic ya da router. O şekil için bulutunuzun zaten sunduğu yönetilen servisle başlayın. Kafka'ya ancak event replay, partition bazlı sıralama ya da yönetilen kuyruk kotasının karşılamadığı bir hacim gerektiğinde geçin.

Kararın geri kalanı teslimat garantilerine, mesaj boyutu limitlerine ve kimsenin işleyemediği bir mesaja ne olacağına bakar.

Mesaj Kalıpları: Üç Temel Şekil

Her pattern farklı araçlar ve trade-off'lar getirir:

Continue reading...

]]> <![CDATA[Frontend Build Araçları Tarihi: jQuery, Grunt, Bower]]> https://sph.sh/tr/posts/frontend-tooling-evolution-101-the-early-web-era/ https://sph.sh/tr/posts/frontend-tooling-evolution-101-the-early-web-era/ Thu, 04 Sep 2025 00:00:00 GMT Frontend tooling, birleştir-ve-minify problemi olarak başladı: elle yönetilen script sırası, deploy için shell script'leri ve manuel sürecin aşılmasıyla gelen ilk task runner dalgası (Make, sonra Grunt, sonra Gulp). Bu erken tooling üzerindeki baskı build hızından değil, bağımlılık sıralaması ve tarayıcılar arası uyumluluktan geliyordu: yüklenen bir site ile sessiz JavaScript hataları üreten bir site arasındaki fark.

Hikâye, elle yazılmış script'lerin ve tarayıcıya özel hack'lerin build öncesi döneminde (1995-2006) başlıyor; jQuery'nin bir uyumluluk katmanı olarak gelişiyle devam ediyor ve 2012'de Bower'la, yani frontend tarafındaki ilk ciddi paket yönetimi denemesiyle bitiyor.

jQuery Öncesi Karanlık Çağ (1995-2006)

Continue reading...

]]> <![CDATA[Grunt vs Gulp vs Webpack: Modern Bundling Nasıl Doğdu]]> https://sph.sh/tr/posts/frontend-tooling-evolution-102-task-runners-and-bundlers/ https://sph.sh/tr/posts/frontend-tooling-evolution-102-task-runners-and-bundlers/ Thu, 04 Sep 2025 00:00:00 GMT Manuel shell-script build pipeline'ları makineden makineye sessiz sedasız bozulur, kabile bilgisi biriktirir ve anlayan tek developer ayrıldığında çöker. Belgelenmemiş build hataları deployment'ları bloke eder ve toolchain'in kendisini bir risk kaynağına dönüştürür. Grunt buna declarative task otomasyonuyla yanıt verdi, Gulp ise configuration bloklarının yerine code stream'leri koydu. Browserify ve webpack de modeli task orchestration'dan dependency-graph bundling'e taşıdı.

Grunt bu ortama net bir ilerleme olarak girdi. İlk kez takımların elinde, karmaşık projeleri handle edecek kadar configure edilebilirken sıkıcı ve hata eğilimli işleri otomatize eden bir tool vardı.

Grunt Devrimi (2012-2015)

Continue reading...

]]> <![CDATA[esbuild, SWC ve Vite: Native Araçlar Webpack'in Yerini Neden Aldı]]> https://sph.sh/tr/posts/frontend-tooling-evolution-103-performance-revolution/ https://sph.sh/tr/posts/frontend-tooling-evolution-103-performance-revolution/ Thu, 04 Sep 2025 00:00:00 GMT webpack gibi JavaScript tabanlı bundler'lar sert bir performans tavanına çarptı: single-threaded çalışma, dosya başına AST parsing ve garbage collection duraklarıyla büyük React uygulamalarında production build'leri 60 saniyeyi aştı. Yavaş feedback döngüleri developer odağını kırıyor ve her merge'de CI maliyetlerini şişiriyor. esbuild, SWC ve Vite bu tavanı, kritik yolu native derlenmiş koda taşıyarak aştı.

Zorluklar takımlar büyüdükçe arttı. Build zamanları her şey için darboğaz haline geldi: local development, CI/CD pipeline'ları ve deployment processleri. Geliştirme takımları kod yazmaktan çok build beklemekle vakit geçiriyordu.

Frontend tooling'deki performans devrimini ateşleyen baskı buydu: JavaScript tabanlı tool'lardan native derlenmiş olanlara doğru bir kayış.

...

Continue reading...

]]> <![CDATA[Gelecek Manzarası: Edge Computing ve Ötesi]]> https://sph.sh/tr/posts/frontend-tooling-evolution-104-the-future-landscape/ https://sph.sh/tr/posts/frontend-tooling-evolution-104-the-future-landscape/ Thu, 04 Sep 2025 00:00:00 GMT Frontend build tooling, bundler hızının artık geliştirici deneyimini sınırlayan asıl etken olmadığı bir eşiği geçti; sıradaki sınır, build tooling'in kodun nerede ve nasıl çalışacağıyla nasıl etkileşeceği. Edge runtime'lar, deployment platformları ve framework seviyesindeki temel yapılar (React Server Components, streaming SSR, partial hydration), build boru hattını artık bundler'ın kendisi kadar etkiliyor. "Build" ile "deploy" arasındaki sınır, tek bir sunucuyu değil bir runtime kümesini hedefleyen tek bir boru hattına dönüşüyor.

Continue reading...

]]> <![CDATA[Git Branching Stratejileri: Farklı Takımlar ve Ürünler için Gerçek Dünya Dersleri]]> https://sph.sh/tr/posts/git-branching-strategies-real-world/ https://sph.sh/tr/posts/git-branching-strategies-real-world/ Thu, 04 Sep 2025 00:00:00 GMT Takım büyüklüğüne ve release temposuna uymayan bir Git dallanma stratejisi seçmek koordinasyon yükü, kırılan main branch'ler ve tıkanan deployment'lar doğurur. Takım büyüdükçe bu uyumsuzluk katlanır: üç geliştirici için ayarlanmış bir strateji yirmi beşte gereksiz sürtüşme yaratır, tersi de geçerlidir. Takımların çoğu için doğru varsayılan GitHub Flow'dur: kısa feature branch'ler, tek bir pull request kapısı, main'e merge. Kalan dört model ise yükünü yalnızca belirli bir kısıt altında hak eder: sürekli deploy, QA onay kapıları, environment programları ya da compliance audit trail'leri.

Sahada Kullanılan Beş Model

Continue reading...

]]> <![CDATA[Google Closure Compiler: Mirası, Dersler ve Modern Alternatifler]]> https://sph.sh/tr/posts/google-closure-compiler-legacy-modern-web-development/ https://sph.sh/tr/posts/google-closure-compiler-legacy-modern-web-development/ Thu, 04 Sep 2025 00:00:00 GMT Google'ın Closure Compiler'ı 2009'da JavaScript'e tüm program kapsamında statik analizi getirdi: dosyalar arası dead code elimination ve JSDoc tabanlı type checking. Bu, webpack, esbuild ya da TypeScript bu yetenekleri yaygınlaştırmadan yıllar önceydi. Bu kökenin farkında olmayan ekipler aynı fikirleri sık sık yeniden keşfediyor ve yeni araçlara atfediyor.

2009'da Tüm Program Kapsamında Analiz

Gelişmiş Dead Code Elimination

Closure Compiler fonksiyon çağrılarını tüm codebase'iniz boyunca takip ediyor, hiçbir yerden referans verilmeyen kodu tamamen kaldırıyordu. Dönemin diğer araçları boşluk kaldırmak ve değişken yeniden adlandırmakla yetiniyordu:

[code block]

Continue reading...

]]> <![CDATA[Mermaid Diyagram Tipleri: Her Grafik Türü için Örnekler]]> https://sph.sh/tr/posts/mermaid-diagram-showcase/ https://sph.sh/tr/posts/mermaid-diagram-showcase/ Thu, 04 Sep 2025 00:00:00 GMT Mermaid, düz metni diyagrama çevirir; böylece bir şema, belgelediği kodun yanında durabilir. Aşağıdaki her diyagram tipi, kopyalayıp uyarlayabileceğiniz çalışan bir örnekle geliyor. Diyagramı tam ekran açmak için üzerine tıklayın.

1. Akış Şeması - Süreç Akışı Görselleştirme

Akış şemaları süreçleri, karar ağaçlarını ve sistem akışlarını görselleştirmek için mükemmeldir.

Aşağıdaki stilli düğümler tek nötr dolgu (#1e293b) kullanır ve anlamı stroke renginde taşır; bu, yoğun bir diyagramı koyu zeminde okunur tutar.

[code block]

2. Sıralı Diyagram - Etkileşim Zaman Çizelgesi

API çağrıları, kullanıcı etkileşimleri ve sistem iletişimlerini belgelemek için mükemmel.

[code block]

Continue reading...

]]> <![CDATA[Micro Frontend'ler: İleri Düzey Pattern'ler, Performans ve Production Dersleri]]> https://sph.sh/tr/posts/micro-frontends-advanced-patterns-debugging/ https://sph.sh/tr/posts/micro-frontends-advanced-patterns-debugging/ Thu, 04 Sep 2025 00:00:00 GMT Micro Frontend Serisi Navigasyonu

- Kısım 1: Mimari temelleri ve uygulama türleri - Kısım 2: Module Federation, iletişim kalıpları ve entegrasyon stratejileri - Kısım 3 (Burada bulunuyorsunuz): İleri düzey kalıplar, performans optimizasyonu ve production hata ayıklama

Ön Koşullar: Kısım 1 temelleri ve Kısım 2 uygulama kalıpları.

---

Continue reading...

]]> <![CDATA[Micro Frontend Mimarisi Temelleri: Modern Web Uygulamaları İçin Eksiksiz Rehber]]> https://sph.sh/tr/posts/micro-frontends-architecture-fundamentals/ https://sph.sh/tr/posts/micro-frontends-architecture-fundamentals/ Thu, 04 Sep 2025 00:00:00 GMT Micro frontend mimarileri, tek sayfalı bir frontend'i bağımsız olarak deploy edilebilen, bağımsız olarak sahiplenilen ve runtime'da birleşen dilimlere böler. Belirli bir dizi sorunu çözerler (ekip büyüklüğü ölçeklendirme, bağımsız sürüm temposu, teknoloji esnekliği) ve buna karşılık yeni bir dizi problem getirirler (runtime kompozisyon karmaşıklığı, paylaşılan bağımlılık yönetimi, dilimler arası state, dilimler arası performans). Benimseme kararı nadiren net bir kazançtır; koordinasyon yükünü sürüm bağımsızlığıyla değiş tokuş eder ve bu takas yalnızca belirli ekip büyüklüklerinde ve ürün yapısı sınırlarında kendini amorti eder.

Continue reading...

]]> <![CDATA[Micro Frontend Uygulama Pattern'leri: Pratik Rehber]]> https://sph.sh/tr/posts/micro-frontends-implementation-patterns/ https://sph.sh/tr/posts/micro-frontends-implementation-patterns/ Thu, 04 Sep 2025 00:00:00 GMT Micro Frontend Serisi Navigasyonu

- Bölüm 1: Mimari temelleri ve uygulama türleri - Bölüm 2 (Şu anda buradasınız): Module Federation, iletişim pattern'leri ve entegrasyon stratejileri - Bölüm 3: İleri düzey pattern'ler, performans optimizasyonu ve production hata ayıklama

Ön Koşullar: Aşağıdaki bölümler Bölüm 1'deki kavramları veri kabul eder. Micro frontend'lere yeniyseniz, önce oradan başlayın.

---

Bölüm 1 micro frontend'ler için temel mimari pattern'leri ele aldı. Module Federation, runtime entegrasyonunda baskın yaklaşımdır ve asıl pratik iş onun kurulumunda, etrafındaki iletişim pattern'lerinde ve production sistemlerinin gerektirdiği hata ayıklama stratejilerinde yatar....

Continue reading...

]]> <![CDATA[Node.js'te Factory ve DI Yerine Saf Fonksiyonlar]]> https://sph.sh/tr/posts/microservices-to-serverless-functions-nodejs/ https://sph.sh/tr/posts/microservices-to-serverless-functions-nodejs/ Thu, 04 Sep 2025 00:00:00 GMT Bir Node.js ödeme servisinde tek bir validation kuralını değiştirmek, kural bir factory'nin, bir dependency injection container'ının ve her biri tek implementasyonu olan bir yığın interface'in arkasında duruyorsa yarım günü yiyebilir. Maliyet, yapmak istediğiniz değişiklik ile o değişikliğin durduğu dosya arasındaki mesafedir. Xia ve arkadaşları bu zamanın nereye gittiğini IEEE Transactions on Software Engineering için yürüttükleri saha çalışmasında ölçtü: yedi proje, 79 profesyonel geliştirici, 3.244 çalışma saati. Kodu anlamak çalışma gününün %57,62'sini, dosyalar arasında gezinmek %23,96'sını, düzenleme ise %5,02'sini aldı.

Continue reading...

]]> <![CDATA[Çapraz Platform Micro Frontend'lerde Re.Pack ve Rspack]]> https://sph.sh/tr/posts/mobile-micro-frontends-multi-channel-production/ https://sph.sh/tr/posts/mobile-micro-frontends-multi-channel-production/ Thu, 04 Sep 2025 00:00:00 GMT Mobil öncelikli micro frontend mimarileri, ikinci bir kanalla (web, desktop) karşılaştıklarında değişmeden nadiren ayakta kalır. Mimariyi mobilde çalıştıran varsayımlar (WebView yaşam döngüsü, native köprü, native gesture'lar, kanal başına asset bundle'ları) ya web ve desktop'a hiç eşlenmez ya da kodu paylaşmanın amacını ortadan kaldıran bir performans maliyetine eşlenir. Gerçek çok kanallı micro frontend'ler (mobil, web, desktop Electron) sadece "bir kez yaz, her yere deploy et" değil, bir runtime soyutlama katmanı ve kanala özel kod yollarında bir disiplin gerektirir.

Continue reading...

]]> <![CDATA[Mobil Micro Frontend'ler: React Native, Expo ve WebView'lar]]> https://sph.sh/tr/posts/mobile-micro-frontends-react-native-expo-webviews/ https://sph.sh/tr/posts/mobile-micro-frontends-react-native-expo-webviews/ Thu, 04 Sep 2025 00:00:00 GMT Mobil takımlar giderek yaygınlaşan bir sorunla karşılaşır: her birinin kendi deployment döngüleri ve teknoloji stack'leri olan farklı takımlardan web tabanlı servisleri entegre etmek. Sıkı teslimat zaman dilimleri bu karmaşıklığı artırır; web takımları mobil entegrasyon için geliştirmelerini durduramaz.

Buradaki varsayılan yaklaşım, her web uygulamasını kendi WebView'ında barındıran native bir React Native kabuğu. Her web takımı kendi bundler'ını ve release temposunu korur. Bunun bedeli mobil tarafta ödenir: bellek baskısı, bundle boyutu ve elle yazmanız gereken navigasyon kodu.

Mobil Micro Frontend Serisi

Bu, mobil micro frontend serisinin 1. Bölümü:

Continue reading...

]]> <![CDATA[React Native WebView İletişimi: postMessage Bridge Pattern'leri]]> https://sph.sh/tr/posts/mobile-micro-frontends-webview-communication-patterns/ https://sph.sh/tr/posts/mobile-micro-frontends-webview-communication-patterns/ Thu, 04 Sep 2025 00:00:00 GMT Mobil micro frontend'lerde WebView-native iletişimi üç somut biçimde bozulur: mesajlar sırasız gelir, TypeScript tipleri web ve native tarafta ayrışır, WebView içindeki JavaScript istisnaları native crash reporter'larda stack trace bırakmaz. Yapılandırılmış bir bridge katmanı yoksa bu hatalar birbirini besler; mesaj geçişindeki bir race condition, ödeme onaylarını veya auth token'larını sessizce yutabilir.

Continue reading...

]]> <![CDATA[Node.js'te Monolitten Mikroservislere Geçiş Rehberi]]> https://sph.sh/tr/posts/monolith-to-microservices-nodejs-evolution/ https://sph.sh/tr/posts/monolith-to-microservices-nodejs-evolution/ Thu, 04 Sep 2025 00:00:00 GMT Monolitlerin Sürdürülemezliği

Node.js monolitleri öngörülebilir biçimde bozulur. Tek bir ortak deployment sınırı, yavaş bir domain'in tüm release döngüsünü bloke etmesine izin verir; yoğun trafikte tek bir feature'da çıkan arıza aynı process'teki diğer her şeyi de birlikte götürür. Mimari çözüm monoliti yeniden düzenlemek değil; onu bağımsız olarak deploy edilebilen, event-driven fonksiyonlara ayrıştırmaktır.

Sonucu sınırlar belirler. Sınırları, kodun gerçekte nasıl değiştiğine ve nerede birlikte bozulduğuna bakarak seçin; bölme sürerken sistemi release edilebilir tutun. Böylece migrasyon her adımda geri alınabilir kalır.

Monolit Nasıl Büyüdü

Continue reading...

]]> <![CDATA[Multi-Account AWS Mimarisi: Ölçeklenebilir Event-Driven Sistemler]]> https://sph.sh/tr/posts/multi-account-aws-event-driven-architecture/ https://sph.sh/tr/posts/multi-account-aws-event-driven-architecture/ Thu, 04 Sep 2025 00:00:00 GMT Single-Account Mimarisinin Sınırları

Multi-account AWS mimarisi, organizasyonlar belirli ölçek ve karmaşıklık eşiklerine ulaştığında gerekli hale gelir. Varsayılan olarak benimsenmeye değer yapı şu: servis takımı başına bir hesap, aralarında paylaşılan bir EventBridge bus'ı ve merkezi bir orchestrator yerine event choreography.

Dokuz geliştirme takımının aynı AWS hesabına deploy ettiği çok servisli bir platform düşünün. Bu yaklaşım küçük organizasyonlarda işe yarar, ancak ölçek arttıkça kritik sorunlar üretir.

Yaygın Single-Account Anti-Pattern'leri

Birden fazla takımın aynı AWS hesabını paylaşması kaynak çakışmalarına, güvenlik sorunlarına ve operasyonel karmaşıklığa yol açar. Örnek bir anti-pattern konfigürasyonu:

Continue reading...

]]> <![CDATA[React Native Uygulamalarda OpenTelemetry ve Firebase ile Gözlemlenebilirlik]]> https://sph.sh/tr/posts/opentelemetry-react-native-firebase-observability/ https://sph.sh/tr/posts/opentelemetry-react-native-firebase-observability/ Thu, 04 Sep 2025 00:00:00 GMT Birçok React Native ekibi production görünürlüğü olmadan yayına çıkar. Yerel ortamda bir türlü tekrarlanamayan çökmeler, arkasında zamanlama verisi bulunmayan performans şikayetleri, belirtiyi anlatan ama uygulamanın o anki durumunu anlatmayan destek kayıtları.

İşe yarayan varsayılan şu: uygulamanın içinde OpenTelemetry JavaScript SDK, OTLP üzerinden kendi işlettiğiniz bir collector'a export, ikinci sinyal olarak da Firebase Performance ve Crashlytics. Vendor SDK'ları daha hızlı kurulur; collector ise backend değiştirmenizi yeni bir sürüm yayınlamadan mümkün kılar ve APM kimlik bilgilerinin uygulama paketine girmesini engeller.

Mobil Gözlemlenebilirlik Gereksinimleri

Continue reading...

]]> <![CDATA[Axios vs Fetch vs Undici: Node.js HTTP Client Karşılaştırması]]> https://sph.sh/tr/posts/server-side-http-clients-comparison/ https://sph.sh/tr/posts/server-side-http-clients-comparison/ Thu, 04 Sep 2025 00:00:00 GMT Node.js sunucudan sunucuya çağrılar için HTTP client seçimi nadiren tek seferlik bir karar olur: native fetch, Axios, undici ve Effect, bağlantı baskısı, retry fırtınaları ve kısmi başarısızlıklar karşısında birbirinden farklı davranır. Gününü başka servisleri çağırarak geçiren bir servis için varsayılan tercih undici'dir. Kendi connection pool'unu yönetir, timeout'ları açıktır ve native fetch'in zaten üzerinde koştuğu motorun ta kendisidir.

Continue reading...

]]> <![CDATA[Serverless Framework mi AWS CDK mi? Geçiş Yapmalı mısınız? (Bölüm 1)]]> https://sph.sh/tr/posts/serverless-to-cdk-migration-part-1/ https://sph.sh/tr/posts/serverless-to-cdk-migration-part-1/ Thu, 04 Sep 2025 00:00:00 GMT Serverless Framework ve AWS CDK, örtüşen sorunları farklı felsefelerle çözer. Serverless Framework, Lambda merkezli bir deploy birimi üzerinde YAML güdümlü, sağlayıcıdan bağımsız bir soyutlamadır; CDK ise CloudFormation üzerinde tip güvenli, AWS-native bir sentez katmanıdır. Serverless Framework ücretli lisans modeline geçtiğinde, olduğun yerde kalmak artık bedelsiz varsayılan olmaktan çıktı ve karşılaştırmayı yeniden yapmak anlamlı hale geldi.

Continue reading...

]]> <![CDATA[Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 2 - CDK Environment'ınızı Kurma]]> https://sph.sh/tr/posts/serverless-to-cdk-migration-part-2/ https://sph.sh/tr/posts/serverless-to-cdk-migration-part-2/ Thu, 04 Sep 2025 00:00:00 GMT Tek bir geliştirici için işe yarayan bir CDK projesi, ekiple buluşunca nadiren ayakta kalır. Çoğu tutorial'daki düz, tek stack'li yapı; birden fazla mühendis aynı anda farklı environment'larda Lambda fonksiyonu deploy etmeye başlayınca çöker. Paylaşılan stack'ler merge conflict üretir, ownership bulanıklaşır ve yeni bir dosyanın nereye gideceği konusunda kimse anlaşamaz.

Çözüm, iş birimlerini birbirinden yalıtan bir proje yapısı: mühendisler paralel ilerlerken Serverless Framework kullanıcılarının zaten bildiği konvansiyonlar korunur. Serverless Framework'ten CDK'ya geçen ekipler için, ilk migration'dan production platformuna kadar ölçeklenen yapı budur.

Continue reading...

]]> <![CDATA[Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 3 - Lambda Fonksiyonları ve API Gateway]]> https://sph.sh/tr/posts/serverless-to-cdk-migration-part-3/ https://sph.sh/tr/posts/serverless-to-cdk-migration-part-3/ Thu, 04 Sep 2025 00:00:00 GMT Lambda fonksiyonları ve API Gateway konfigürasyonları, migration karmaşıklığının yoğunlaştığı yerdir. YAML'dan TypeScript'e geçiş mekanik bir iş gibi görünür; ta ki bundling, memory boyutlandırma ve hata yönetimi ayrı birer karara dönüşene kadar.

İşe yarayan yaklaşım tek bir ortak NodejsFunction construct'ıdır: runtime, architecture, memory, tracing ve bundling varsayılanları tek yerde durur, farklı davranması gereken fonksiyonlar için her prop override edilebilir kalır. API Gateway tarafında da aynı yöntem geçerlidir; validator'lar, authorizer'lar ve integration response'lar bir kez tanımlanıp route'lar arasında yeniden kullanılır.

Continue reading...

]]> <![CDATA[Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 4 - Veritabanı ve Ortam Yönetimi]]> https://sph.sh/tr/posts/serverless-to-cdk-migration-part-4/ https://sph.sh/tr/posts/serverless-to-cdk-migration-part-4/ Thu, 04 Sep 2025 00:00:00 GMT Bir CDK migration'ında en yüksek risk database ve environment tarafındadır. Stateless Lambda fonksiyonlarının aksine bu bileşenler uygulamanın kalıcı durumunu ve konfigürasyonunu tutar. Yanlış bir adım tabloyu siler, veri kaybettirir veya staging'i hiçbir hata mesajı vermeden production key'ine bağlar.

Güvenli yol dar. Bir tabloyu import etmeden önce var olduğunu doğrulayın, environment değerlerini eksik key durumunda synth'i başarısız kılan type-safe bir builder'dan üretin ve her secret'ı tek bir stage'e kilitleyin. Aşağıdaki bölümler bu varsayılanı DynamoDB import'larına, Parameter Store'a, Secrets Manager'a ve VPC'ye bağlı fonksiyonlara uygular.

Continue reading...

]]> <![CDATA[Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 5 - Authentication, Authorization ve IAM]]> https://sph.sh/tr/posts/serverless-to-cdk-migration-part-5/ https://sph.sh/tr/posts/serverless-to-cdk-migration-part-5/ Thu, 04 Sep 2025 00:00:00 GMT Serverless Framework'ten AWS CDK'ya authentication ve authorization migrasyonu, genellikle birikmiş bir güvenlik borcunu ortaya çıkarır: organik büyüyen ve hiç gözden geçirilmemiş izinler ve authorization logic'i.

Yaygın pattern'lar arasında aşırı geniş IAM izinleri olan fonksiyonlar, multiple custom authorizer'lara dağılmış authorization logic'i ve erişim kontrol kararları için yetersiz audit trail'ler bulunur. Bu sorunlar migration değerlendirmeleri sırasında belirgin hale gelir ve compliance gereksinimlerini önemli ölçüde etkileyebilir.

Continue reading...

]]> <![CDATA[Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 6 - Migration Stratejileri]]> https://sph.sh/tr/posts/serverless-to-cdk-migration-part-6/ https://sph.sh/tr/posts/serverless-to-cdk-migration-part-6/ Thu, 04 Sep 2025 00:00:00 GMT Bir CDK migrasyonunun son aşamasında mesele, üretilen altyapının doğruluğu değildir. Mesele, geçiş anındaki operasyonel hazırlıktır: trafiği almak için bir plan, migrasyon production'ı bozarsa geri dönmek için bir plan ve canlı yük altında ortaya çıkan drift'i gidermek için bir plan. Onlarca Lambda fonksiyonu ve birden fazla DynamoDB tablosu içeren bir migrasyonda geçiş planı, migrasyon kodunun kendisinden daha büyüktür.

Continue reading...

]]> <![CDATA[DynamoDB Toolbox Rehberi: TypeScript Single-Table Tasarımı]]> https://sph.sh/tr/posts/streamline-dynamodb-toolbox-serverless-typescript/ https://sph.sh/tr/posts/streamline-dynamodb-toolbox-serverless-typescript/ Thu, 04 Sep 2025 00:00:00 GMT Raw DynamoDB SDK call'ları ile serverless API'lerin inşası önemli bakım yükü yaratır. Binlerce satır AttributeValue mapping'i, onlarca dağınık UpdateExpression string'i ve sıfır type safety kırılgan sistemlere yol açar. Schema değişiklikleri yanlışlıkla kullanıcı kayıtlarını bozduğunda, daha iyi bir yaklaşımın gerekli olduğu açık hale gelir.

Burada varsayılan olarak DynamoDB Toolbox'a uzanmak mantıklı. Kütüphane table'ı tipli entity tanımlarıyla sarar; key üretimi, default'lar ve marshalling artık her çağrı noktasında elle yazılmaz. İşin çoğu üç yerde toplanır: entity tasarımı, iş kurallarını üstlenen bir servis katmanı ve raw SDK'dan kademeli geçiş.

Continue reading...

]]> <![CDATA[React Native'de Feature Flag: Stale-While-Revalidate Deseni]]> https://sph.sh/tr/posts/swr-style-feature-flags-react-native/ https://sph.sh/tr/posts/swr-style-feature-flags-react-native/ Thu, 04 Sep 2025 00:00:00 GMT Feature flag'ler checkout akışının kritik yolunda durur; bu yüzden onları nasıl yüklediğiniz bir erişilebilirlik kararıdır. Senkron bir API çağrısı her render'a bir ağ gidiş dönüşü ekler. Cold start koşullarında bu gidiş dönüş saniyelere uzar, checkout timeout'a düşer ve kullanıcı sepeti terk eder. Stale-while-revalidate okumayı kritik yoldan çıkarır: cache'deki değer anında döner, taze değer arka planda çekilir. Cache'i varsayılan cevap, ağı ise bir arka plan tazelemesi olarak görün; asla bir kapı olarak değil.

Senkron Flag Yüklemesinin Bedeli

Temel bir flag implementasyonu her değere ihtiyaç duyulduğunda senkron API çağrısı yapar:

[code block]

Bu kurulumdan dört arıza biçimi doğar:

Continue reading...

]]> <![CDATA[Holakrasi vs Team Topologies: Takım Otonomisi Modelleri Karşılaştırması]]> https://sph.sh/tr/posts/team-autonomy-structures/ https://sph.sh/tr/posts/team-autonomy-structures/ Thu, 04 Sep 2025 00:00:00 GMT Liderliğin "takımlara daha çok otonomi veriyoruz" açıklaması her zaman karışık tepkilerle karşılanır, çünkü sınırları olmayan otonomi genelde çözdüğünden çok problem yaratır.

Senaryo tanıdıktır. Matriks proje takımlarından ürün moduna, akışa-hizalanmış takımlara geçiş hız kazanımı üretir; yanında istenmeyen sonuçları da getirir: daha fazla defekt, tekrarlanan çaba, takımların birbirinin ayağına basması.

Burada uygulanabilir varsayılan Team Topologies. Takım tiplerini ve etkileşim modlarını çerçeve olarak alın; sonra Holakrasi'den rol tüzüklerini, Spotify modelinden uygulama topluluklarının dilini ödünç alın. Bağlam değişir; ancak bu birleşim yeniden yapılanmanın deneme-yanılma maliyetini düşürür.

Otonominin Tanımı

Continue reading...

]]> <![CDATA[Kapsamlı Markdown Tipografi Rehberi]]> https://sph.sh/tr/posts/typography/ https://sph.sh/tr/posts/typography/ Thu, 04 Sep 2025 00:00:00 GMT Markdown işlemcileri başlıklar, listeler ve kod bloklarında hemfikir. Bunun ötesinde destek dağılır: dipnotlar, tanım listeleri, katlanabilir bölümler ve uyarı kutuları render motoruna göre farklı davranır. Aşağıdaki bölümler her özelliği kaynak sözdizimiyle birlikte gösterir; bir özelliğe güvenmeden önce kendi render motorunuzda çalışıp çalışmadığını görebilirsiniz.

Başlıklar

Başlık 1 Stili (H1 = Yazı Başlığı) Başlık 2 (H2) Başlık 3 (H3) Başlık 4 (H4) Başlık 5 (H5) Başlık 6 (H6)

Metin Formatlaması

Temel Formatlama

Continue reading...

]]> <![CDATA[Zod + OpenAPI + AWS Lambda: CDK ile Şema Öncelikli API Geliştirme]]> https://sph.sh/tr/posts/zod-openapi-aws-lambda-cdk/ https://sph.sh/tr/posts/zod-openapi-aws-lambda-cdk/ Thu, 04 Sep 2025 00:00:00 GMT Bir Lambda API'si ile OpenAPI spec'i ayrı ayrı bakıldığında şema kayması kaçınılmazdır. Zod doğrulamasına eklenen bir alan, istemcilerin kod ürettiği sözleşmeden sessizce düşer ve aşağı yöndeki tüketiciler uyarı almadan bozulur. Çözüm tek bir doğruluk kaynağıdır: Zod şemalarını doğrudan OpenAPI spec üretimine ve CDK dağıtımına bağlarsanız, yayınlanan sözleşme her istekte çalışan doğrulamadan ayrışamaz.

Dokümantasyon Kaymasının Bedeli

Klasik serverless API geliştirme tuzağı, dört farklı doğruluk kaynağının sessizce birbirinden sapmasıdır:

[code block]

Continue reading...

]]>