<![CDATA[sph.sh Blog]]> https://sph.sh/tr RSS for Node Sun, 17 May 2026 20:54:52 GMT Sun, 17 May 2026 20:54:51 GMT 60 <![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 açık 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: Anatomi ve Confluence Şeklindeki Soru]]> 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 mağazasını 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 mağazası kararıdır: AWS dokümantasyonu, Confluence Cloud'un "şu anda" yalnızca OpenSearch Serverless vektör mağazası ile kullanılabildiğini açıkça belirtir ve 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[Kafka mı, Event Bus mı? SNS/SQS/EventBridge'i Aşmanız Gerektiğini Söyleyen Sinyaller]]> 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 ekiplerin çoğu 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.

Yazı, bugün üretimde bir event bus çalıştıran backend geliştiricileri ve cloud mimarları için. Yedi sinyali, sizi bus'ta tutması gereken karşı sinyalleri ve outbox desenine dayanan dört aşamalı geçiş planını sıralıyor.

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. Bu yazı tam orada bırakıyor ve deployment sorusunu soruyor: AgentCore artık @aws-cdk/aws-bedrock-agentcore-alpha üzerinden CDK'dan erişilebilir, peki uçtan uca çalışan bir trial neye benziyor? Pratikte kod kısa ve ağırlığı alpha L2 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 Tek bir reviewer'ın darboğaza dönüştüğü küçük takımlarda PR'lar geç merge edilir ve gün sonunda yorgun bir gözle onaylanır. Sıkıcı hata sınıfı (eksik null kontrolü, yutulmuş bir hata, yanlış logger, eklenmiş ama hiç çalıştırılmamış bir test) dikkatli bir ilk okuyucunun otuz saniyede yakaladığı, yorgun bir insanın ise üzerinden geçtiği şeydir. Anthropic'in baktığı anthropics/claude-code-action, bugün bir PR pipeline'ına AI ilk-okuma reviewer'ı eklemenin doğru varsayılanı: en düşük sürtünmeyle çalışan kurulum, Anthropic'in auth ve prompt injection sıkılaştırmalarını miras alıyor, kendisi gerekli reviewer sayılmadan normal branch protection ile birlikte çalışıyor.

Continue reading...

]]> <![CDATA[TypeScript Geliştiricilerin Monolitten Lambda'ya Taşıdığı Beş 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 Problem

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 geri tepiyor. 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. Aşağıdaki her bölüm semptomu adlandırır, maliyeti açıklar ve fonksiyonel alternatifi verir.

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. Bu yazı POC çalışmadan önce hangi limitin önce, hangi sırayla ve hangi sinyalle ısıracağını adlandırır.

İş

Continue reading...

]]> <![CDATA[WebAssembly 101: Üç Bahis, Tek Bytecode]]> 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ı. Bu yazı üç bahsi ayırıyor; böylece sonraki Wasm sohbetinde hangisinin masada olduğunu anlayabilesin.

30 Saniyede WASM

Yazının tezi, herhangi bir ekseni açmadan önce: Tek bytecode, üç ayrı bahis. Tarayıcıda performans, sunucuda WASI runtime, edge'de compute. Her biri farklı bir soruya cevap.

Continue reading...

]]> <![CDATA[İzole Consumer Hesaplarına Event Fan-Out: Sıfır Dokunuşlu Producer, Domain Başına Sahiplik]]> 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 yazı, çok takımlı bir AWS organizasyonunda event omurgasının sahibi olan platform ve backend mühendisleri içindir. Audit, Customer Center, Marketing ve gelecekteki consumer'lar için varsayılan bir topoloji tanımlar ve farklı bir omurgaya ne zaman geçmek gerektiğini gösterir.

Tez: fan-out event bus katmanında yaşar, uygulama kodunda değil

Continue reading...

]]> <![CDATA[wasmCloud + NATS: Kilitlenme Aslında Event Bus Topolojisinde Yaşar]]> 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 Somut Problem

Serverless kilitlenmesi üzerine konuşmaların çoğu runtime katmanına takılıyor: Lambda'ya karşı Cloud Functions, Workers'a karşı Containers. Event bus ise tesisat gibi ele alınıyor. Event-driven sistemlerde bu çerçeveleme tersine, çünkü runtime haftalar içinde değiştirilebilir, bus topolojisi ise çeyrekler içinde. Bu yazı, Lambda ve EventBridge ile zaten rahat çalışan ama wasmCloud ve NATS'a daha yakından bakmak gerekip gerekmediğini merak eden mühendisler için bir tez denemesi.

Tez

Continue reading...

]]> <![CDATA[Web ve Mobil için Asenkron API Desenleri: Görüşlü Bir Varsayılan]]> 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 Somut Problem

Ç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[Hepsine Hükmeden Tek Kurulum: Model-Bağımsız AI Kodlama Yapılandırması]]> 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 Özet

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. Bu yazı, AGENTS.md dosyasını tek kaynak olarak kullanan somut bir düzen gösterir: diğer araçların beklediği her dosya adı için symlink ya da @-import, araçlar arası tool katmanı için MCP. Aynı zamanda hayalin kırıldığı yerleri de işaretler: skill'ler, slash komutları ve Windows symlink tuzakları.

Problem

Continue reading...

]]> <![CDATA[Async Backend'ler İçin UX Rehberi: Optimistic, Decoupled, ya da Hiçbiri]]> 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 Spinner'lar Backend'inizden Gelen Bir Hata Raporudur

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.

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; çünkü altta yatan taşıma katmanları (HTTP, mobil radyolar, mesaj aracıları) başarısızlık durumunda niyetten bağımsız olarak retry yapar. Idempotent olmayan bir endpoint, her retry'ı bir duplicate yazmaya çevirir: çift ücretlendirme, tekrarlanan siparişler, iki kez işlenen işler.

Continue reading...

]]> <![CDATA[Döngüyü Kapatmak: Mobil Uygulamalarda Reklam Harcamasından Ücretli Aboneye]]> 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 Özet

Abonelik uygulamalarında attribution, bir reklam tıklamasını veri ambarındaki doğrulanmış bir ücretli abonelik olayına bağlamak zorundadır; install ara bir sinyaldir, gelir olayı değildir ve SKAN 4 ile ATT, click-to-install bağlantısını install-to-subscription bağlantısından daha zor gözlemlenir hale 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; ancak brüt gelir üzerinden alınan %1 MTR ücreti yaklaşık 100 bin dolar MTR'ın üstünde matematiği değiştirir ve 2026 pazarı, varsayılanı belirli bir eksende güç karşılığında bırakan birkaç alternatif sunar: 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 ile İzin Kontrol Katmanı: AI Agent'lar için Geniş API Erişimini Yönetmek]]> 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 Özet

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 özel kapsamlı proxy'ler nasıl oluşturulur göstermiştik. Zapier MCP, yönetilen bir alternatif sunuyor: aksiyon bazlı beyaz liste, merkezi kimlik yönetimi ve insan onay mekanizması; proxy kodu yazmadan. Bu yazı, Zapier MCP'nin ne zaman doğru seçim olduğunu, yönetilen çoklu uygulama erişimi için nasıl yapılandırılacağını ve özel proxy'lerin hâlâ nerede avantajlı olduğunu ele alıyor.

Sorun: 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 Mobil monetizasyon ilk bakışta basit görünür -- ta ki ilk App Store red yanıtını alana ya da makbuz doğrulamanızda jailbreak'li cihazların premium içeriğe ücretsiz erişmesine izin veren bir açık keşfedene kadar. Uygulama mağazası ödeme kuralları, komisyon yapıları ve teknik gereksinimler, her mobil geliştiricinin dikkatli şekilde yönetmesi gereken karmaşık bir alan oluşturur.

Bu yazıda mobil IAP'nin pratik tarafını ele alıyoruz: her iki mağazanın gereksinimleri, farklı iş modelleri için çalışan paywall kalıpları, RevenueCat'in çapraz platform abonelik yönetimini neden basitleştirdiği ve event-driven mimari ile güvenilir bir makbuz doğrulama pipeline'ı nasıl kurulur.

Continue reading...

]]> <![CDATA[Omnichannel Yetkilendirme Senkronizasyonu: Platformlar Arası Abonelik Erişimi]]> https://sph.sh/tr/posts/omnichannel-entitlement-sync/ https://sph.sh/tr/posts/omnichannel-entitlement-sync/ Thu, 02 Apr 2026 00:00:00 GMT Özet

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.

Bu yazı, SaaS işletmeleri için beş sağlayıcıyı (Stripe, Adyen, Chargebee, Paddle, PayPal) karşılaştırır. Payment Processor ve Merchant of Record ayrımını, PSD2/SCA ve KDV yükümlülüklerini ve ekip büyüklüğüne, coğrafyaya, iş modeline dayalı bir karar çerçevesini ele alır.

Payment Processor ve Merchant of Record Farkı

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ı kısa bir mutlu yola ve gelir kaybedilmeden fark edilmeyen uzun bir uç durumlar kuyruğuna sahiptir. Naif bir proration adımı plan yükseltmelerinde çift ücret keser; varsayılan bir yeniden deneme politikası dunning sırasında kartları yakar; 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ı çalıştırılabilen, başarısız olabilen veya tekrarlayabilen bir geçiştir.

Continue reading...

]]> <![CDATA[Başkalarının Claude Code Skill'lerini Kopyalamak Neden İşe Yaramaz]]> 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 Özet

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 klonlama dürtüsü güçlü. Ancak konfigürasyonları kopyalamak üç birleşik soruna yol açar. Birincisi, gerçek koda yer bırakmayan context window şişmesi. İkincisi, modelin doğru aracı seçme yeteneğini düşüren araç kalabalığı. Üçüncüsü, kod tabanınla uyuşmayan iş akışları. Bu yazıda token matematiğini, araştırma verilerini ve bilinçli konfigürasyon oluşturmak için pratik bir çerçeve sunuyorum.

Sorun: Kopyala-Yapıştır Konfigürasyon

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 Abstract

AWS Cognito kimlik doğrulamayı yönetir. AWS Verified Permissions (AVP) yetkilendirmeyi yönetir. Birlikte AWS'nin yerel SaaS yetkilendirme altyapısını oluşturur. Bu yazıda iki servisin nasıl entegre edildiğini, Cedar politikalarının kiracı izolasyonunu nasıl sağladığını ve B2B SaaS ürünleri için çok kiracılı yetkilendirmenin nasıl yapılandırılacağını inceliyoruz. TypeScript entegrasyon kodu, Cedar politika örnekleri, maliyet analizi ve Microsoft Entra ID yaklaşımıyla bir karşılaştırma içerir.

> Note: Bu yazı Harici Yetkilendirme Sistemleri serisinin 2. bölümüdür. 1. bölüm, daha geniş yetkilendirme platformu haritasını ve karar çerçevesini kapsar.

Cognito'nun Yetkilendirmedeki Rolü

Continue reading...

]]> <![CDATA[Harici Yetkilendirme Yönetim Sistemleri: Mimarınız İçin Doğru Platformu Seçmek]]> 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 Özet

Özel yetkilendirme sistemleri geliştirmek birçok uygulama için işe yarıyor. Ancak dağıtık sistemler giderek daha fazla, politika değerlendirme, ilişki yönetimi ve ayrıntılı erişim kontrolünü bir servis olarak sunan özel yetkilendirme altyapılarından fayda görüyor. Bu yazı mevcut platform haritasını çıkarıyor, mimari yaklaşımları karşılaştırıyor ve AWS Verified Permissions, SpiceDB, OpenFGA, Cerbos, OPA ve diğer platformlar arasında seçim yapmak için bir karar çerçevesi sunuyor. Bu yazı, belirli platformlara ve politika dillerine daha derinlemesine dalan bir serinin ilk yazısıdır.

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 Abstract

Yetkilendirme için seçtiğin politika dili, güvenlik mimarinin tamamını şekillendirir. Politikaların nasıl yazılacağını, test edileceğini, dağıtılacağını ve denetleneceğini belirler. Daha sonra dil değiştirmek, tüm politikaları yeniden yazmak demektir. Bu yazı, dört ana yetkilendirme politika dilinin -- Cedar, Rego, OpenFGA DSL ve Cerbos YAML/CEL -- söz dizimi, performans özellikleri, biçimsel doğrulama, araç desteği ve TypeScript entegrasyon kalıpları açısından derinlemesine teknik karşılaştırmasını sunuyor. Amaç, geçiş maliyeti engelleyici hale gelmeden önce bilinçli bir dil seçimi yapmanı sağlamak.

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 Abstract

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 motorudur. Auth0 FGA ise farklı bir tutarlılık modeli ile OpenFGA üzerine kurulu, REST-öncelikli, tamamen yönetilen bir hizmettir. Bu yazı, her iki sistemin şema dillerini, mimarisini, tutarlılık modellerini ve entegrasyon kalıplarını yan yana karşılaştırır. Her iki sistem için de çalışan TypeScript örnekleri sunarak doğru seçimi yapmanıza yardımcı olmayı amaçlar.

Continue reading...

]]> <![CDATA[Müşteri geri bildirimini ürün değerine dönüştürmek]]> 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.

Bu yazı, intake, triage, gerektiğinde keşif, teslimat ve müşteriye dönük kapalı döngüden oluşan operasyonel bir halka anlatıyor. Destek SLA’ları, mühendislik kuyrukları ve kusurlu metrikler gerçeğiyle harmanlanmış bir ürün pratiği.

Geri bildirim neden bunaltıcı hissedilir

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

Continue reading...

]]> <![CDATA[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 Özet

Broken access control, OWASP Top 10'da (2021, 2025 güncellemesinde de doğrulandı) bir numaralı güvenlik açığı. İzin sistemi hataları genellikle tek bir eksik kontrolden kaynaklanmıyor -- kontrolleri unutmayı kolay, tutarlı tutmayı zor kılan bir mimariden kaynaklanıyor. Bu yazıda izin sistemlerinin neden bozulduğunu inceliyor, fail-closed prensibini tanıtıyor ve iyi tasarlanmış bir izin sisteminin karşılaması gereken hedefleri belirliyoruz.

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 Özet

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ü. Bu yazı ilk çözümü sunuyor -- service layer pattern. Tüm yetkilendirme mantığı, uygulama kodunuz ile veritabanı arasında tek bir katmana taşınıyor. Next.js middleware ile route koruması ve birden fazla seviyede guard pattern'leriyle birleştiğinde, izin kontrollerinin bir kez ve doğru şekilde yapıldığı bir derinlemesine savunma mimarisi oluşuyor.

Dağınık Kontroller Sorunu -- Kök Neden

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 Özet

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.

Bu yazı o zincirleri RBAC (Rol Bazlı Erişim Kontrolü) ile değiştiriyor. Ferraiolo ve Kuhn tarafından 1992'de biçimlendirilen ve NIST tarafından INCITS 359-2004 olarak standartlaştırılan bir modeldir. Tek bir type-safe can() fonksiyonu tüm sabit kodlanmış kontrollerin yerini alıyor. Hem sunucu hem istemci tarafında çalışarak Post 102'nin bir sınırlama olarak belirttiği izin mantığı tekrarını ortadan kaldırıyo...

Continue reading...

]]> <![CDATA[ABAC: Policy Engine ile Attribute Bazlı Erişim Kontrolü]]> 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 Özet

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. Sunucu ve istemci tek bir doğruluk kaynağını paylaşıyor.

Ancak bağlamsal kararlar (sahiplik, departman kapsamı, belge durumu) RBAC dışında özel yardımcı fonksiyonlar olarak kalmaya devam ediyor. canModifyDocument, canEditInDepartment, canPublishInReviewStatus gibi fonksiyonlar can() fonksiyonunun yanında çoğalıyor. Her biri tip sisteminin doğrulayamadığı özel 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 Özet

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 dağınık yardımcı fonksiyonlar değil, policy kuralları.

Continue reading...

]]> <![CDATA[Multi-Tenancy, Kütüphaneler ve Mimari Kararlar]]> 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 Abstract

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 Katmanını Atla: AI Agentleri için Kapsamlı API Erişimi]]> 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 Özet

Atlassian'ın Rovo MCP Server'ı yapay zeka agentlerini Jira ve Confluence'a bağlar, ancak geniş erişim modeli production ortamlarında ciddi sorunlar yaratır: zayıf proje kapsamı, yüksek token maliyeti ve ya hep ya hiç araç erişimi. Bu yazıda üç somut alternatifi ele alıyoruz: FastAPI/Express scoped proxy, ACLI CLI wrapper ve n8n workflow. Her biri çalışan kodlarla birlikte. Temel fikir: yapay zeka agentine yalnızca ihtiyacı olan endpoint'leri göster, geri kalanını gizle.

Sorun: Atlassian Ekosisteminde MCP

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. Bu yazı, OU yapısı tasarımı, koruma mekanizması seçimi, Account Factory otomasyonu ve hesaplar arası erişim kalıpları için pratik karar verme süreçlerini ele alır. AWS dokümantasyonunu tekrarlamak yerine, hangi yaklaşımın ne zaman kullanılacağına ve pratik ödünleşimlere odaklanır.

> AWS Control Tower Landing Zone 4.0 ve AFT v1.18.x'e göre son doğrulama: Mart 2026. AWS servisleri hızla gelişir; en son değişiklikler için her zaman resmi dokümantasyonu kontrol et.

Çoklu Hesap Stratejisi Neden Önemli

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 Özet

Continue reading...

]]> <![CDATA[Büyük Ölçekli Mikroservis Mimarisi için Ölçeklenebilir Bir GitHub Actions Platformu Oluşturmak]]> 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 Özet

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 Bu rehber, Sentry'yi bir React Native Expo uygulamasına entegre etme sürecini kurulumdan production-grade source map yüklemesine kadar adım adım anlatıyor. Kritik yapılandırma detaylarını, Expo Go kısıtlamalarını, session replay kurulumunu ve hazırlıksız yakalandığında saatler kaybettirebilecek yaygın tuzakları kapsıyor. EAS Build ve EAS Update entegrasyonları production'da debug süresini önemli ölçüde kısaltır.

Ön Koşullar

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

Continue reading...

]]> <![CDATA[Developer Relations: Ürünler ve Geliştirici Toplulukları Arasında Köprü Kurmak]]> https://sph.sh/tr/posts/devrel-role-analysis/ https://sph.sh/tr/posts/devrel-role-analysis/ Wed, 04 Feb 2026 00:00:00 GMT Özet

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, stratejik değeri gözden kaçırıyor: DevRel, geliştirici gerçekliğini sistematik olarak yakalayan ve ürün geliştirmeye geri aktaran, aynı zamanda geliştirici eğitimini hiçbir dokümantasyon ekibinin tek başına başaramayacağı ölçekte büyüten bir fonksiyondur. Bu analiz, DevRel'in gerçekte ne içerdiğini, bu rollerde kimlerin başarılı olduğunu ve şirketlerin bu fonksiyona ne zaman yatırım yapması gerektiğini inceliyor.

Continue reading...

]]> <![CDATA[DynamoDB Rate Limiting: Single Table Design'da Ölçekte Stratejiler]]> 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şılan bir durum. Bunun nedenini anlamak için DynamoDB'nin iç mekanizmalarına inmek gerekiyor.

Bu rehberde, Single Table Design uygulamalarında throttling'i önleme ve yönetme konusunda kanıtlanmış pattern'leri ele alacağız. Partition key stratejilerinden, sorunları kullanıcıları etkilemeden yakalayan monitoring yapılandırmalarına kadar her şeyi kapsıyoruz.

DynamoDB'nin Throttling Mekanizmasını Anlamak

Continue reading...

]]> <![CDATA[MCP İleri Düzey Kalıplar: Yetenekler, İş Akışları, Entegrasyon ve RBAC]]> 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 Özet

MCP benimsenmesi lansmanından bu yana hızla büyümüş olsa da, içeriklerin çoğu temel sunucu implementasyonunu kapsıyor. Bu yazı bir sonraki seviyeyi hedefliyor: uygun çoklu ajan iş akışları, araç bileşim kalıpları, RBAC ile kurumsal düzeyde güvenlik ve production gözlemlenebilirlik ile sofistike MCP tabanlı sistemlerin nasıl tasarlanacağı. Odak noktası, ölçekte çalışan kalıplar ve neyin başarılı olup neyin ileride sorun yarattığına dair somut örnekler.

Ölçeklendirme Zorluğu

Temel MCP entegrasyonlarını başarıyla deploy eden organizasyonlar, ölçeklendikçe öngörülebilir zorluklarla karşılaşıyor:

Araç Patlaması: 5 araçla başlayıp 10 sunucu üzerinde 50'ye büyümek, ajanlar için keşif ve seçim sorunları yaratıyo...

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. Bu kılavuz, RAG sisteminizin kalite tavanını belirleyen kritik temeli kapsıyor.

Veri Hazırlama Neden En Kritik RAG Adımı

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: Kod ile İş Dünyası Arasında Köprü Kuran Rol]]> 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 Özet

Forward Deployed Engineer (FDE) rolü, teknoloji şirketlerinin kurumsal müşterilere nasıl değer sunduğunu temelden değiştiren bir yaklaşımı temsil ediyor. Bu model, satış sonrası desteğin ötesine geçerek müşteri sahasında gerçek mühendislik katkısı sunar. Tasarım aşamasında veya satış döngüsünde sona eren geleneksel çözüm rollerinin aksine, FDE'ler müşterilerle birlikte çalışarak production kodu yazıyor, gerçek entegrasyon zorluklarını çözüyor ve ürün yetenekleri ile iş gereksinimleri arasındaki boşluğu kapatıyor. Bu analiz, FDE rolünü farklı kılanları, AI implementasyonunun talebi neden hızlandırdığını ve bunun mühendislik kariyerleri için ne anlama geldiğini inceliyor.

Ana Tez: Slide Değil, Kod

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 Özet

TypeScript'te AI agent geliştirmek, Vercel AI SDK'nin provider-agnostic yaklaşımı, OpenAI'nin native handofflu Agents SDK'si veya direkt provider SDK'leri arasında seçim yapmayı gerektiriyor. Bu karşılaştırma, bilinçli kararlar vermenize yardımcı olmak için tool calling patternlerini, streaming yeteneklerini ve production değerlendirmelerini inceliyor. Analiz, her yaklaşım için gerçek kod örnekleri, maliyet etkileri ve pratik karar frameworkleri içeriyor.

TypeScript AI SDK Ekosistemi

Agent geliştirme ekosistemi önemli ölçüde olgunlaştı. Eskiden özel çözümler bir araya getirdiğimiz yerde, şimdi üç ana yaklaşım TypeScript agent geliştirmesine hakim:

Continue reading...

]]> <![CDATA[Kurumsal AI Entegrasyon Seviyeleri: SaaS'tan Fine-Tuning'e 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 Özet

Kurumsal AI benimseme süreci genellikle tahmin edilebilir bir patern izler: ekipler basit alternatifleri doğrulamadan sofistike çözümlerin peşinden koşar. Bu rehber, teknik karar vericilerin AI yeteneklerini gerçek iş ihtiyaçlarıyla eşleştirmesine yardımcı olan 6 seviyeli entegrasyon framework'ü (L1-L6) sunar. Framework, PII'yi sert bir mimari kapısı olarak vurgular ve finans sektörü düzenleyici gereksinimlerini ele alarak hem aşırı mühendislik hem de uyumluluk başarısızlıklarından kaçınmak için somut karar kriterleri sağlar.

Aşırı Mühendislik Tuzağı

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. Bu gerçek bir problem yaratır: vendor materyalleri kavramları karıştırıyor ve bir terimin kavramsal anlamını bilmek, onu pratik olarak nasıl kullanacağını bilmekten önemli ölçüde farklı.

Bu sözlük bu boşluğu kapatıyor. Sadece tanımlar değil - LLM destekli sistemler geliştirmekten gelen implementation bağlamı, yaygın yanlış anlamalar ve pratik rehberlik. Bir PM "knowledge base'imizi embed etmekten" bahsettiğinde veya temperature 0'ın neden hallucination'ları engellemediğini açıklaman gerektiğinde referansın olarak düşün.

Navigasyon

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 önemli ölçüde değişti. Farklı proje boyutlarında hem geleneksel hem de modern araçlarla çalışmak, "en iyi" seçimin büyük ölçüde belirli kısıtlamalara bağlı olduğunu öğretti. Bu karşılaştırma, TypeScript projeleriniz için bilinçli bir karar vermenize yardımcı olmak üzere ESLint, Prettier, Biome ve Oxlint'i inceliyor.

Özet

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 Özet

Bu yazı, işverenlerin işe alım sürecinde vaat ettikleri ile çalışanların işe başladıktan sonra deneyimledikleri arasındaki kopukluğu inceliyor. Greenhouse, Gallup ve McKinsey araştırmalarından yararlanarak, bait-and-switch işe alım kalıplarını, istihdam ilişkilerindeki güç dinamiklerini ve eksik istihdamın psikolojik etkisini analiz ediyorum. Amaç, bu zorluklarla başa çıkan çalışanlar ve şeffaf işe alım uygulamalarıyla güven inşa etmek isteyen işverenler için uygulanabilir framework'ler sunmak.

Problemin Boyutu

Continue reading...

]]> <![CDATA[Sessiz Erozyon: Satın Alma Sonrası Kültürel Asimilasyon Ödediğiniz Değeri Nasıl Yok Ediyor]]> 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. Verilere göre gerçekleşmeyen M&A değerinin en büyük tek kaynağıdır: anlaşmaların %70-90'ı beklenen değeri sağlayamıyor ve bu başarısızlıkların %60-75'i pazar, ürün ya da finansal nedenlerden değil, kültürel uyumsuzluktan kaynaklanıyor. 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 Abstract

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. Bu rehber, bu runtime'ları Lambda üzerinde çalıştırmanın teknik implementasyonunu iki yaklaşımla inceliyor: Lambda Layer'ları ve container image'ları. Gerçek benchmark'lardan gelen performans karakteristiklerini, implementasyon tuzaklarını ve AWS'nin optimize edilmiş Node.js runtime'ı ile alternatif runtime'lar arasındaki trade-off'ları inceleyeceğiz.

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 Özet

İyi promptlar yazmak basit olsa da, production için sağlam prompt engineering sistemleri oluşturmak tamamen farklı bir zorluk. Bu rehber, production-grade LLM uygulamaları için gereken sistematik mühendislik yaklaşımını kapsıyor: yapılandırılmış prompt tasarımı, lifecycle yönetimi, güvenlik savunmaları, kapsamlı observability ve maliyet optimizasyon stratejileri. Deneysel promptlarla enterprise-ready altyapı arasındaki boşluğu nasıl kapatacağını öğreneceksin.

Production Boşluğu

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. Bu prensipler hala önemli mi? Cevap evet, ama önemli adaptasyonlarla.

Bu prensipler JavaScript'te değerli olmaya devam ediyor, ama çeviri gerekiyor. Sorun bunları kullanıp kullanmamak değil, inheritance yerine composition'ı ve katı interface'ler yerine duck typing'i tercih eden bir dilde nasıl uygulayacağımız.

Özet

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 1600+ edge location ile çalışıyor ve iki farklı edge computing çözümü sunuyor: CloudFront Functions ve Lambda@Edge. Her iki servis ile çalışmak bana doğru seçimin maliyet, performans ve implementasyon karmaşıklığı üzerinde önemli etkisi olduğunu öğretti.

AWS ile edge computing çözümleri geliştirirken öğrendiklerim.

CloudFront Edge Computing'i Anlamak

CloudFront ile edge computing, kodu kullanıcılara yakın edge location'larda çalıştırarak yürütmeyi mümkün kılıyor. Her iki servis de request'leri edge'de işleyerek latency sorunlarını çözüyor, ancak farklı kullanım senaryolarına hitap ediyorlar.

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 Özet

Amazon Cognito, uygulamalar için yönetilen authentication ve authorization sağlıyor, ancak production sistemleri temel sign-up ve sign-in akışlarından fazlasını gerektiriyor. Bu kılavuz, mid-to-senior developer'ların ölçeklenebilir, güvenli authentication sistemleri oluşturmak için ihtiyaç duydukları gelişmiş Cognito pattern'lerini inceliyor: multi-factor workflow'lar için özel Lambda trigger'ları, multi-tenant token customization için Pre Token Generation, enterprise identity provider'ları ile SAML/OIDC federation, caching stratejileriyle API Gateway entegrasyonu ve Auth0 veya özel sistemlerden sıfır downtime migration.

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 Özet

Effect, fonksiyonel effect sistemlerini production uygulamalarına getiren kapsamlı bir TypeScript kütüphanesi. Typed error'lar, dependency injection ve structured concurrency sağlıyor; hepsi compile time'da zorunlu tutuluyor. Bu rehber Effect'in ne olduğunu, 12 haftalık bir süreçte nasıl öğrenileceğini ve AWS Lambda ile nasıl entegre edileceğini anlatıyor. Effect ile çalışmak bana açık hata yönetiminin sadece güvenlikle ilgili olmadığını öğretti; API'leri nasıl tasarladığınızı ve hata durumları hakkında nasıl düşündüğünüzü temelden değiştiriyor. Bu yazı pratik kod örnekleri, gerçek kullanımdan yaygın hatalar ve Effect düşünen ekipler için benimseme stratejileri içeriyor.

Bu Rehber Hakkında Bir Not

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. Bu rehber teknik karar kriterleri, complete implementation pattern'leri ve gerçek dünyadan öğrenilmiş dersleri içeriyor. Kısa kural: statik config → Parameter Store; RDS şifreleri ve rotation → Secrets Manager.

Servisleri Anlamak

Implementation'a geçmeden önce, bu servisler arasındaki teknik farkları ortaya koyalım. Cross-account secret paylaşımı gerekiyorsa Secrets Manager resource policy'leri daha esnek; Parameter Store için RAM (Resource Access Manager) kullanırsınız.

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 bir sözdür ve bunun arkasındaki strateji (URL yolu, header, content negotiation ya da sürümlenmiş kaynak grafı) istemci migrasyonlarının ne kadar maliyetli olacağını, kullanımdan kaldırılmış yüzeyin ne kadar süre deploy'da kalacağını ve geçişler sırasında altyapının ne kadar ikiye katlanacağını belirler. Çoğu API versioning yeniden yazımı, /v2/ ile v2. arasında seçim yapmakla değil, ekibin sözleşmeyi örtük olarak iletiyor olduğunu fark edip onu açık hale getirmekle ilgilidir.

Özet

Continue reading...

]]> <![CDATA[Feature Flags at Scale: Implementation Pattern'leri ve Platform 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 Özet

Feature flag'ler, kodu production'a deploy ederken feature görünürlüğünü runtime'da kontrol etmeni sağlar. Bu rehber, scale'de feature flag implementation pattern'lerini inceliyor ve LaunchDarkly, Unleash, AWS AppConfig platformlarını karşılaştırıyor. SDK entegrasyonu, targeting rule'ları, A/B testing entegrasyonu, circuit breaker pattern'leri ve flag technical debt yönetimi gibi kritik konuları ele alacağım. TypeScript örnekleri gradual rollout, kill switch ve lifecycle management stratejilerini gösteriyor.

Deployment Koordinasyon Problemi

Continue reading...

]]> <![CDATA[Modern Web Uygulamaları için E2E Testing Stratejileri - Pratik Bir Mühendislik Rehberi]]> https://sph.sh/tr/posts/e2e-testing-strategies/ https://sph.sh/tr/posts/e2e-testing-strategies/ Sat, 20 Dec 2025 00:00:00 GMT Özet

End-to-end testing, Playwright ve Cypress gibi modern framework'lerle önemli ölçüde gelişti. Bu rehber, gerçek bug'ları yakalarken flakiness'ı minimize eden güvenilir E2E test suite'leri oluşturmak için pratik stratejileri inceliyor. Framework seçimi, mimari pattern'ler, API mocking, visual regression, accessibility testing ve CI/CD optimizasyonunu kapsıyoruz. Bu araçlarla çalışırken öğrendiğim şey, başarının tool seçiminden çok mimari kararlardan geldiği; doğru test isolation, stable selector'ler ve dengeli test pyramid'leri hangi framework'ü seçtiğinden daha önemli.

Framework Seçimi: Playwright vs Cypress

Mimari Farklar

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'dir ve her katmanın farklı geçersiz kılma semantiği, tutarlılık garantisi ve hata biçimi vardır. %15 hit rate'e sahip bir Redis cluster'ı, yanlış katman için yanlış iş yapıyor demektir; Redis'in o iş için yanlış araç olması gerekmez. Popüler bir anahtar expire olduğunda oluşan thundering herd de aslında bir cache problemi değil, tek katmanlı herhangi bir cache'in maruz kalacağı bir sürü-koruma (stampede) problemidir.

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 optimizasyonu, tek bir sihirli araç bulmakla ilgili değil; native AWS servisleri, otomasyon ve organizasyonel pratikleri birleştiren sistematik bir yaklaşım inşa etmekle ilgili. Reaktif fatura analizine odaklanan geleneksel maliyet yönetiminin aksine, modern AWS maliyet optimizasyonu proaktif monitoring, right-sizing, akıllı satın alma stratejileri ve sürekli governance gerektirir.

Continue reading...

]]> <![CDATA[Mozilla SOPS: GitOps için Gerçekten İşe Yarayan Secret Encryption]]> 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 Özet

Mozilla SOPS (Secrets OPerationS), GitOps'ta temel bir sorunu çözüyor: secret'ları version control'e güvenli bir şekilde nasıl commit edebiliriz ama aynı zamanda developer productivity'yi nasıl koruruz. Cloud-native secret store'lardan farklı olarak, SOPS dosyaları doğrudan Git repository'lerinde encrypt ediyor, YAML/JSON yapısını korurken hassas değerleri şifreliyor. Bu rehber age encryption, AWS Lambda entegrasyonu, AWS CDK workflow'ları, AWS SAM pattern'leri ve GitHub Actions, GitLab CI, Jenkins'te serverless deployment'lar için CI/CD otomasyonu gibi pratik implementation pattern'lerini kapsıyor.

GitOps Secret Management Challenge

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 Özet

Dual-write problemi, çalıştığım hemen her event-driven sistemde karşıma çıktı. Database'i güncelleyip aynı anda event yayınlaman gerektiğinde imkansız bir seçimle karşılaşırsın: işler ters gittiğinde hangi operasyon başarısız olacak? Transactional Outbox Pattern, her iki operasyonu da aynı database'e tek bir transaction içinde yazarak kanıtlanmış bir çözüm sunuyor. Ardından ayrı bir process eventleri güvenilir şekilde publish ediyor. Bu yazıda polling publishers, Change Data Capture (CDC) ve AWS serverless pattern'lerini kullanarak pratik implementasyonları inceliyoruz.

Dual-Write Problemi

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 Özet

Tech şirketlerindeki kariyer seviyeleri, özellikle şirket değiştirirken veya terfi planlarken mühendisleri sıklıkla kafasını karıştırıyor. Bu rehber, Amazon, Google, Meta, Microsoft, Spotify ve Zalando'daki kariyer seviyelerini inceliyor, eşdeğer seviyeleri eşleştiriyor ve her seviyenin scope, özerklik ve impact açısından ne anlama geldiğini açıklıyor. Terfilerde gezinme, Staff-level iş bulma ve kariyer yolu hakkında bilinçli kararlar verme konusunda pratik içgörüler paylaşacağım.

Seviye Karmaşası Problemi

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 Özet

Retrieval-Augmented Generation (RAG) sistemleri genellikle temel vector similarity search ile başlar, ancak bu yaklaşım multi-hop reasoning, exact keyword match ve complex query'lerde yetersiz kalır. Bu rehber, hybrid search, multi-stage reranking, intelligent chunking stratejileri, self-corrective retrieval (CRAG) ve knowledge graph'ler (GraphRAG) aracılığıyla bu sınırlamaları aşan gelişmiş RAG mimari desenlerini inceliyor. AWS Bedrock Knowledge Bases ve OpenSearch kullanarak pratik implementasyon pattern'lerini, production'da latency, maliyet ve accuracy arasındaki trade-off'ları ele alıyor ve RAGAS metrikleriyle evaluation framework'leri kuruyoruz. Çalışan kod örnekleri her bir pattern'i gerçekçi performance benchmark'larıyla gösteriyor.

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 Özet

AWS AppSync, yönetilen WebSocket altyapısı, otomatik veri senkronizasyonu ve conflict resolution ile real-time GraphQL API'leri geliştirmeyi kolaylaştırıyor. Bu rehber, AppSync mimarisi, modern JavaScript resolver'lar, enhanced subscription filtering, caching stratejileri ve AWS CDK ile production deployment pattern'lerini inceliyor. AppSync ile çalışmak bana doğru resolver tipini ve data modeling stratejisini seçmenin hem performans hem de maliyet üzerinde önemli etkisi olduğunu öğretti; bu yazıda production ortamlarında işe yarayan pattern'leri paylaşıyorum.

Problem Tanımı

Real-time özellikler içeren modern uygulamalar geliştirmek, basit REST API development'ın ötesinde birkaç teknik zorluk sunuyor:

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 Özet

AI agent'ları deneysel prototiplerden production sistemlere geçerken güvenlik kritik hale geldi. 2025'te organizasyonların %13'ü AI uygulama ihlali yaşadı ve %97'si uygun erişim kontrollerine sahip değil. Bu rehber, AWS Bedrock Guardrails, defense-in-depth stratejileri, prompt injection önleme, tool authorization ve multi-agent güvenlik konularını pratik implementasyon pattern'leriyle inceliyor. Production AI sistemleriyle çalışırken öğrendim ki, geleneksel güvenlik sınırları stokastik modeller için tam olarak geçerli değil. Defense-in-depth opsiyonel değil, zorunlu.

Problem Context'i

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 Platform Engineering, golden paths ve standartlaştırılmış workflow'lar aracılığıyla self-servis altyapı sağlayan Internal Developer Platformları oluşturur. Bu rehber IDP mimarisi, implementasyon desenleri, araç seçenekleri (Backstage, Port, AWS servisleri), başarı metrikleri ve geliştiricilerin gerçekten kullanacağı platformlar oluştururken karşılaşılan yaygın hataları kapsıyor.

Platform Engineering'i Anlamak

Platform ekipleriyle çalışmalardan öğrendiğim, Platform Engineering'in temelde software engineering organizasyonları için self-servis yetenekler sağlayan toolchain'ler ve workflow'lar tasarlamak olduğu. Temel değişim, internal developer'ları kontrol edilecek kullanıcılar yerine müşteri olarak görmek.

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 Özet

Pact ile consumer-driven contract testing, microservislerdeki kritik bir sorunu çözüyor: geniş end-to-end test yükü olmadan distributed team'ler arasında API uyumluluğunu korumak. Bu kılavuz TypeScript'te pratik implementasyonu gösteriyor - consumer test'lerinden CI/CD pipeline entegrasyonuna kadar. Temel bulgular: contract testing integration test süresini %60-70 azalttı, breaking change'leri deployment öncesi yakaladı ve bağımsız servis evrimini mümkün kıldı. Yaklaşım unit test'ler (çok izole) ile E2E test'ler (çok yavaş) arasındaki boşluğu dolduruyor, API uyumluluğunda hızlı feedback sağlıyor - ancak sınırlamalarını da kabul ediyor: servis sınırlarını validate eder, business workflow'ları değil.

API Uyumluluk Problemi

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 Abstract

Model Context Protocol (MCP), büyük AI providerlar arasında hızla standart haline geldi. GitHub ya da Slack gibi yaygın servisler için hazır serverlar işe yarasa da, organizasyonların internal API'leri entegre etmek, güvenlik politikalarını uygulamak ve domain-specific logic'i encode etmek için custom serverlar gerekiyor. Bu rehber, TypeScript ile production-ready custom MCP server geliştirmeyi anlatıyor: başlangıç setup'tan Kubernetes deployment'a kadar. Authentication, circuit breaker'lar, audit logging ve monitoring için çalışan kod örnekleriyle.

Custom Integration Challenge

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 Özet

Cross-account SNS/SQS fan-out, AWS hesap sınırları arasında güvenli event dağıtımı sağlıyor. Bu mimari pattern, bir hesaptaki tek bir SNS topic'in, farklı hesaplardaki birden fazla SQS queue'ya mesaj göndermesini sağlarken, yönetimsel izolasyonu koruyarak event-driven iletişimi mümkün kılıyor. Bu rehber, IAM policy'leri, KMS şifreleme, AWS CDK kurulumu ve production'da ortaya çıkan yaygın sorunların troubleshooting'ini içeriyor.

Cross-Account Fan-Out Neden Önemli

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 Abstract

Production'da Large Language Model çalıştırmak, geleneksel cloud infrastructure'dan temelden farklı bir maliyet modeli sunuyor. Token-based pricing, maliyetlerin kullanım pattern'larına, prompt tasarımına ve model seçimine göre 100 kat değişebileceği anlamına geliyor. Öngörülebilir compute-hour faturalandırmanın aksine, LLM harcamaları kötü optimize edilmiş prompt'lardan veya sınırsız tool kullanımından beklenmedik şekilde artabiliyor.

Bu rehber, prompt caching (%90 tasarruf), intelligent model routing (%30-50 azalma), token budget enforcement ve semantic caching gibi sistematik LLM maliyet optimizasyon yaklaşımlarını inceliyor. Bu pattern'ları uygulayan ekipler tipik olarak kaliteyi koruyarak %60-80 maliyet azalması sağlıyor.

Continue reading...

]]> <![CDATA[Chatbot'lardan Otonom Agent'lara: Mimari Desenler]]> 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 Özet

Kural tabanlı chatbot'lardan otonom AI agent'larına geçiş, sadece bir yetenek yükseltmesi değil; temel bir mimari değişimi temsil ediyor. Chatbot'lar önceden tanımlanmış intent'lere göre scriptli konuşmalar takip ederken, AI agent'ları memory, planlama yetenekleri ve tool erişimine sahipler. Bu, onların karmaşık görevleri otonomca parçalayabilmesini, kararlar alabilmesini ve sistemler arası çok adımlı workflow'ları execute edebilmesini sağlıyor.

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 Özet

Saga pattern, microservices mimarisinin en zorlu problemlerinden birini çözüyor: servisler arasında geleneksel ACID transaction'lar olmadan data consistency sağlamak. Bu yazıda, AWS Step Functions orchestration ve EventBridge choreography kullanarak saga implementasyonu, etkili compensation logic tasarımı, idempotency garantisi ve dağıtık sistemlerdeki isolation sorunlarını ele alıyorum. Orchestration ile choreography arasında ne zaman hangisini seçeceğini, concurrent saga conflict'leri önlemek için semantic locking'i nasıl uygulayacağını ve production ortamları için kritik observability pattern'lerini öğreneceksin.

Dağıtık Transaction Problemi

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 Test Etme Zorluğu

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. Aynı zamanda serverless mimarisi yerel öncelikli testi 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 bir ekip, yanlış servis modelinin doğru servisin doğal olarak sağlayacağı davranışı geri kazanmak için özel bir katman yazmayı zorunlu kıldığını genellikle geç fark eder; AWS mesajlaşma yeniden yazımlarının çoğu buradan çıkar.

Bu yazı, üç servisi iletişim modeli, teslim semantiği, sıralama, maliyet ve operasyonel yüzey açısından karşılaştırır. Seçim karar ağacını, yaygın hibrit desenleri (SNS'den SQS'e fan-out, EventBridge'den SQS'e filtreli abonelik) ve servisler arası migrasyon maliyetlerini ele alır.

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 Özet

AWS Step Functions, serverless uygulamalar için güçlü workflow orchestration sağlıyor ama Standard vs Express workflow seçimi, doğru error handling implementasyonu ve maliyet optimizasyonu pratik deneyim gerektiriyor. Bu rehber, production-ready pattern'leri kapsıyor: büyük ölçekli processing için Distributed Map, Task Token'larla callback pattern'leri, direct service integration'lar ve masrafları %90'ın üzerinde azaltabilen maliyet optimizasyon stratejileri. Çalışan CDK kod örnekleri Amazon States Language (ASL) pattern'lerini, exponential backoff ile error handling'i ve production ortamlar için monitoring kurulumunu gösteriyor.

Orchestration Zorluğu

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 Production Gap'i

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 dakikalarca döngüye giren agent'lar, aydan aya %30-40 büyüyen token harcaması ve yalnızca kullanıcı şikayetleriyle keşfedilen 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[Model Context Protocol: Production-Ready AI Entegrasyonları Geliştirmek]]> 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 Problemini Anlamak

AI entegrasyonları üzerinde çalışırken bir pattern ortaya çıktı: 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. Takımların Slack, GitHub ve database'ler için haftalarca bespoke entegrasyon geliştirdiğini, AI provider değiştiğinde tüm süreci tekrarladığını gördüm.

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 Production Aşamasındaki Zorluklar

Birçok ekip gerçek değer gösteren etkileyici LangChain veya CrewAI prototipleri geliştiriyor - ta ki bunları deploy etme zamanı gelene kadar. "Laptopumda çalışıyor" aşamasından production'a geçiş session isolation, credential management, memory persistence, observability ve security kontrolleri gerektiriyor. Bu altyapıyı sıfırdan inşa etmek aylar alıyor, bu yüzden AI projelerinin %70'i pilot aşamasını geçemiyor.

Continue reading...

]]> <![CDATA[Amazon Aurora: AWS'nin Cloud-Native Veritabanını Anlamak]]> 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 "daha iyi" olmakla ilgili değil - veritabanı mimarisini workload özelliklerine, operasyonel gereksinimlere ve maliyet kısıtlamalarına uydurmakla ilgili. Bilinçli bir seçim yapmak için bilmen gerekenler burada.

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 Özet

AWS CloudFormation'un stack başına 500 kaynak sınırı, production-grade altyapı geliştirirken sıkça karşılaşılan sabit bir kısıtlamadır. Bu sınırla çalışmak bana gösterdi ki, nested stack'ler, cross-stack referanslar, SSM Parameter Store ve microstack mimarisi arasındaki seçim operasyonel tercihlere, deployment patternlerine ve takım yapısına bağlıdır. Bu yazıda beş stratejiyi TypeScript CDK örnekleri, karar çerçeveleri ve bu sınırı aşan altyapıları yeniden yapılandırırken öğrendiğim derslerle paylaşıyorum.

500 Kaynak Sınırını Anlamak

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 Özet

Single-table design, DynamoDB için veri modelleme yaklaşımında temel bir değişimi temsil ediyor. Bu kapsamlı rehber, single-table pattern'leri ne zaman kullanacağını, one-to-one, one-to-many ve many-to-many ilişkileri nasıl modelleyeceğini, Global ve Local Secondary Index'ler arasındaki trade-off'ları, DAX caching entegrasyonunu ve pratik query optimizasyon tekniklerini ele alıyor. Çalışan TypeScript örnekleri, gerçek maliyet analizleri ve hot partition ile throttling sorunlarından kaçınmak için test edilmiş pattern'ler bulacaksın.

Single-Table Design Neden Önemli

Continue reading...

]]> <![CDATA[AWS CDK Kod Organizasyonu: Service-Based ve Domain-Based Mimari Patternleri]]> 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 Özet

AWS CDK projeleri genellikle belirsiz organizasyon stratejileriyle başlar ve ölçeklendikçe tight coupling, circular dependency'ler ve deployment darboğazlarıyla karşılaşır. Bu rehber, beş organizasyon patternini - service-based, domain-based, feature-based, layer-based ve hybrid - çalışan TypeScript örnekleri ve karar çerçeveleriyle inceliyor. Ekiplerin business ihtiyaçlarına, team yapısına ve deployment gereksinimlerine uygun CDK projeleri oluşturmasına yardımcı oluyor.

Problem Bağlamı

Continue reading...

]]> <![CDATA[AWS CDK Functional Patterns: Tekrar Kullanılabilir, Hatasız Infrastructure Konfigürasyonları]]> 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 Özet

AWS CDK, infrastructure'ı gerçek kod olarak ele almamızı sağlar, ancak doğru pattern'ler olmadan takımlar genellikle duplicate konfigürasyonlar, tutarsız ayarlar ve compile time'da önlenebilecek runtime hataları ile karşılaşır. Functional programming pattern'leri - higher-order function'lar, factory pattern'ler ve composition - CDK'yı CloudFormation generator'dan type-safe, tekrar kullanılabilir bir infrastructure toolkit'e dönüştürür. Bu yazıda, ortak konfigürasyonları (NodejsFunction ayarları, RemovalPolicy enforcement, logging standartları gibi) nasıl merkezileştirebileceğini ve manuel tekrar veya runtime sürprizleri olmadan tüm kaynaklarda nasıl tutarlı şekilde uygulayabileceğini göstereceğim.

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 Özet

IoT sistemleriyle çalışırken öğrendiğim en önemli şeylerden biri, protokol seçiminin sistem performansını, güvenilirliğini ve operasyonel maliyetleri önemli ölçüde etkilediğidir. Bu rehberde beş mesajlaşma protokolünü - MQTT, AMQP, ZeroMQ, CoAP ve DDS - filo takibi, soğuk zincir izleme ve gerçek zamanlı cihaz iletişimi senaryolarından örneklerle karşılaştırıyorum. Çalışan kod örnekleri, gerçekçi performans metrikleri ve senin spesifik gereksinimlerine uygun protokolü seçmene yardımcı olacak karar çerçeveleri bulacaksın.

Protokol Seçimi Sorunu

Continue reading...

]]> <![CDATA[Reaktif Programlama Çağında Davranışsal Kalıplar]]> 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 Özet

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 - bu kalıpları uygulamanın önemli miktarda boilerplate gerektirdiği diller. Modern TypeScript ile RxJS, Redux ve React hooks bu kalıpları uygulama şeklimizi temelden değiştirdi. Bazıları framework convention'larına dönüştü, diğerleri reaktif paradigmalara evrildi, bazıları ise klasik formlarında şaşırtıcı derecede güncel kaldı.

Continue reading...

]]> <![CDATA[Modern TypeScript'te Creational Pattern'lerin Evrimi]]> 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 Gang of Four'un design patterns kitabı 1994'te çıktı ve C++ ile Smalltalk geliştiricilerinin nesne yaratma sorunlarını hedef alıyordu. 30 yılı aşkın süre sonra TypeScript bize optional parametreler, default değerler, destructuring, ES modülleri ve gelişmiş bir type sistemi sunuyor. Creational pattern'ler kaybolmadı - evrildi.

Bu yazıda Singleton, Factory, Builder ve Prototype pattern'lerinin modern TypeScript kod tabanlarında nasıl ortaya çıktığını, ne zaman hala değer kattıklarını ve ne zaman dil özelliklerinin onları gereksiz kıldığını inceliyoruz.

Singleton Pattern: Anti-Pattern'den Context-Dependent Tool'a

Continue reading...

]]> <![CDATA[Gang of Four'un Ötesindeki 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 Özet

Gang of Four, 1994'te C++ ve Smalltalk için pattern'leri dokümante etti. Asenkron programlamayı, component composition'ı, functional programming'i ya da reactive data flow'u öngöremezlerdi. JavaScript ve TypeScript ekosistemleri, 1994'te var olmayan problemleri çözmek için kendi pattern'lerini geliştirdi. Bu yazıda, gerçek web development ihtiyaçlarından doğan modern pattern'leri inceliyoruz: Stateful logic paylaşımı için React Hooks, esnek API'ler için Compound Components, data access abstraction için Repository Pattern ve doğal design pattern olarak ES Modules. Bunlar klasik pattern'lerin uyarlamaları değil - yeni problemler için yeni çözümler.

Pattern Düşüncesinin Evrimi

Continue reading...

]]> <![CDATA[Yapısal Patternler ve Component Composition]]> 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 ekosistemlerinde bu patternler kaybolmadı - framework konvansiyonlarına, hook'lara ve type-safe wrapper'lara dönüştü.

Bu yazıda yapısal patternlerin React component composition'da nasıl ortaya çıktığını, higher-order componentlerin ne zaman hala önemli olduğunu ve TypeScript'in type system'ının klasik implementasyonları nasıl geliştirdiğini inceliyoruz.

Decorator Pattern: TypeScript'te Üç Farklı 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 Özet

TypeScript'teki Builder pattern, geleneksel nesne yönelimli dillerdekinden farklı bir amaca hizmet eder. Java ve C# builder'ları çok sayıda opsiyonel parametreyi yönetmek için kullanırken, TypeScript implementasyonu generic'ler ve conditional type'ları kullanarak karmaşık kısıtlamaları compile time'da zorunlu kılar ve potansiyel runtime hatalarını IDE'nin yakalayabileceği tip hatalarına dönüştürür. Bu rehber, serverless altyapı, veritabanı katmanı, API konfigürasyonu ve test alanlarında pratik uygulamaları ele alarak, builder'ların production'a ulaşmadan önce yanlış konfigürasyonları nasıl önlediğini gösteriyor.

TypeScript'te Karmaşık Nesnelerin Sorunu

Continue reading...

]]> <![CDATA[Type-Safe Lambda Middleware: Middy, Zod ve Builder Pattern ile Enterprise Uygulamalar]]> 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 Özet

Enterprise serverless uygulamaları temel middleware pattern'larından daha fazlasına ihtiyaç duyar. Bu yazıda Middy'yi temel alarak type-safe, sürdürülebilir Lambda middleware sistemleri inşa etmeyi keşfedeceğiz: enforced composition için builder pattern, mükemmel hata mesajları ile runtime validation için Zod, dinamik davranış kontrolü için feature flags ve doğru secrets management. Lambda ile ölçekli çalışmak bana compile-time type safety ve tutarlı middleware sıralamasının production'daki sorunları runtime validation'dan çok daha etkili önlediğini öğretti.

Standard Middleware Pattern'larındaki Problem

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 Özet

OpenTelemetry (OTel), dağıtık sistemlerden telemetri verisi toplamak için birleşik, vendor-agnostic bir yaklaşım sunan açık kaynak bir observability framework'üdür. Bu kapsamlı rehber, observability temellerini, OpenTelemetry mimarisini, çalışan kod örnekleriyle pratik implementasyon pattern'lerini ve semantic convention'lar ile sampling stratejileri gibi temel kavramları ele alıyor. Uygulamaları nasıl instrument edeceğinizi, collector'ları nasıl deploy edeceğinizi, yaygın hatalardan nasıl kaçınacağınızı ve sistemlerinize production-ready observability'yi nasıl ekleyeceğinizi öğreneceksiniz.

Giriş: Dağıtık Sistem Challenge'ı

Continue reading...

]]> <![CDATA[TypeScript'in Temel Ama Az Bilinen Özellikleri: Production-Ready Type Safety]]> 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 Abstract

TypeScript 2025'te GitHub'da en çok kullanılan dil haline geldi, Ağustos ayında Python'u geçerek yıl bazında %66 contributor artışıyla. Ancak birçok geliştirici sadece type system'in yüzeyini kazıyor. Bu yazı, production kod kalitesini önemli ölçüde iyileştiren 7 az bilinen özelliği inceliyor: configuration validation için satisfies operator, array güvenliği için noUncheckedIndexedAccess, nominal typing için branded types, exhaustiveness checking ile discriminated unions, type predicates vs assertion functions, string patterns için template literal types ve type extraction için infer keyword. Her özellik, spesifik production problemlerini sıfır runtime overhead ile çözüyor.

Problem Context

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 Abstract

Ağ temellerini anlamak sadece network mühendisleri için değil - her yazılım geliştiricisi için gerekli bir bilgi. Production'da bir sorunu debug ederken, API performansını optimize ederken veya distributed bir sistem tasarlarken, network kavramları sürekli karşına çıkıyor. Bu rehber, backend sistemler geliştirirken ve production sorunlarını çözerken karşılaştığım gerçek dünya senaryoları, yaygın tuzaklar ve debugging durumlarıyla birlikte networking temellerinin pratik bir sözlüğünü sunuyor.

Geliştiriciler Neden Network Bilgisi İhtiyaç Duyar

Öğrendiğim şey şu: Mükemmel uygulama kodu yazabilirsin, ama verinin client ile server arasında nasıl hareket ettiğini anlamazsan, şu konularda zorlanırsın:

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 Özet

Domain-Driven Design (DDD), kod yapısını business domain mantığıyla hizalayarak karmaşık yazılım sistemleri oluşturmanın stratejik bir yaklaşımıdır. Bu rehber, DDD'nin temel kavramlarını, yapı taşlarını ve stratejik desenlerini, bu prensipleri ne zaman ve nasıl etkili bir şekilde uygulayacağınızı gösteren pratik TypeScript örnekleriyle birlikte inceliyor.

Domain-Driven Design Nedir?

Domain-Driven Design, Eric Evans tarafından 2003'te tanıtılan, teknik uzmanlar ve domain uzmanları arasındaki işbirliğini vurgulayan bir yazılım geliştirme yaklaşımıdır. Ana fikir: kodunuz, hizmet ettiği business domain'i yansıtmalı ve domain uzmanlarının kullandığı dil ve kavramları kullanmalıdır.

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 Özet

Event Storming, ekiplerin karmaşık business domain'leri ve workflow'ları hızlıca anlamasına yardımcı olan işbirlikçi bir workshop tekniğidir. Bu rehber, Event Storming oturumlarını yönetmekten edindiğim pratik bilgileri paylaşıyor - ne olduğu, neden işe yaradığı, etkili oturumların nasıl yapılacağı ve ne zaman kullanılacağı konularında. Renk kodlama sistemini, pratikte işe yarayan yönetim tekniklerini ve hem yüz yüze hem de uzaktan oturumların nasıl yapılacağını öğreneceksin.

Event Storming Nedir

Continue reading...

]]> <![CDATA[VPS, Dokploy ve Cloudflared ile Uygun Maliyetli Private Sunucu 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 Neden Bu Stack?

Private sunucu çalıştırmak için pahalı cloud faturalarına ya da karmaşık infrastructure'lara ihtiyacınız yok. Çeşitli deployment setupları ile çalışırken öğrendiğim şey, en iyi çözümün genellikle kurumsal platformlar yerine basit, odaklanmış araçları birleştirmekte yattığı oldu.

Bu rehber, production-ready bir private sunucu kurulumunu anlatıyor: - 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

Toplam maliyet? Birden fazla uygulamayı güvenli şekilde çalıştıran temel bir kurulum için ayda yaklaşık $5-10.

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 Özet

Continue reading...

]]> <![CDATA[Çok Kanallı İçerik Yönetimi: Headless CMS Dünyasında Yol Haritası]]> 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 Özet

Headless CMS seçmek eskiden basit görünüyordu - ta ki içeriğinizi aynı anda web, mobil ve potansiyel olarak IoT cihazlara servis etmeniz gerekene kadar. Farklı projelerde birkaç çok kanallı CMS çözümüyle çalıştıktan sonra öğrendim ki "en iyi" seçim ekip workflow'unuza, teknik kısıtlarınıza ve içerik editörleme deneyimi gereksinimlerinize bağlı. Bu rehber dört büyük oyuncuyu - Strapi, Contentful, Kontent ve Storyblok - karşılaştırıyor, görsel yönetimi, framework entegrasyonu ve önemli mimari kararlar hakkında pratik bilgiler sunuyor.

Çok Kanallı CMS Manzarası

Continue reading...

]]> <![CDATA[Traefik 101: Otomatik Keşifli Modern Reverse Proxy]]> https://sph.sh/tr/posts/traefik-101-introduction/ https://sph.sh/tr/posts/traefik-101-introduction/ Sun, 26 Oct 2025 00:00:00 GMT Özet

Traefik, dinamik altyapılar için geliştirilmiş modern bir reverse proxy ve load balancer. Geleneksel reverse proxy'lerin manuel konfigürasyon güncellemeleri gerektirmesinin aksine, Traefik servisleri otomatik keşfeder ve routing kurallarını kendisi günceller. Bu yazıda temel kavramları, pratik Docker kurulumlarını ve nginx ile dürüst karşılaştırmaları bulacaksın - böylece senin use case'in için doğru aracı seçebilirsin.

Traefik Nedir?

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 Özet

Profesyonel yazılım mühendisleri kritik bir soruyla karşı karşıya: günlük workflow'umuza ne kadar AI yardımı entegre etmeliyiz? Bu ikili bir "AI kullan ya da kullanma" kararı değil - minimal inceleme odaklı yardımdan tam AI-first "vibe coding"e uzanan bir spektrum. Ekiplerin bu geçişi yönetirken edindiğim deneyimlere göre, başarının anahtarı bir seviyeyi seçip ona bağlı kalmak değil - belirli context'lere göre AI yardımını ne zaman artırıp azaltacağını anlamak.

Continue reading...

]]> <![CDATA[AI Geliştirici Araçları Bölüm 1: Yükseliş ve Gerçeklik - Tarih, Evrim ve Güncel Durum]]> 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 Özet

AI geliştirici araçları, deneysel asistanlardan kurumsal kritik altyapıya dönüştü, ancak gerçeklik pazarlama vaatlerinden önemli ölçüde farklı. Bu analiz, mevcut AI geliştirme araçlarının durumunu gerçek kurumsal benimseme verileri üzerinden inceliyor ve verimlilik kazançlarının sistemik darboğazlar, güvenlik açıkları ve deneyimli geliştiriciler arasında büyüyen güven krizi ile dengelendiği karmaşık bir tablo ortaya koyuyor.

Kimsenin Sormadığı Soru

Yakın zamandaki bir mimari incelemede, CTO soru sordu: "AI geliştirici araçlarına önemli yatırım yapıyoruz, ama deployment frequency'miz artmadı. Gerçek değer nerede?"

Continue reading...

]]> <![CDATA[AI Geliştirici Araçları Bölüm 2: Uygulamalı İmplementasyon Rehberi - Kurulumdan Ü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 Özet

AI araç değerlendirmesinden production implementasyona geçmek, güvenlik açıklarında gezinmeyi, yönetişim çerçeveleri kurmayı ve deneyimli geliştiricilerin AI yardımıyla %19 daha yavaş çalıştığı gerçeğini yönetmeyi gerektirir. Bu uygulama rehberi, gerçek kurumsal deployment'lardan savaş testinden geçmiş kalıpları, güvenlik kontrollerini ve kalite metriklerini paylaşıyor.

İmplementasyon Gerçeklik Kontrolü

Geçen çeyrek, platform takımımız bir direktif aldı: "Q1'e kadar 200+ mühendise AI geliştirici araçlarını yay." Takip eden süreç, AI verimliliği hakkındaki varsayımların production gerçeğiyle nasıl çarpıştığına dair bir ders niteliğindeydi.

Continue reading...

]]> <![CDATA[AI Geliştirici Araçları Bölüm 3: Güvenlik, Güven ve Yönetişim - Riskleri Ölçekte Yönetmek]]> 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 Özet

2025 AI geliştirici araçları güvenlik manzarası, GitHub Copilot'ta uzaktan kod yürütmeyi ortaya çıkaran CVE-2025-53773 ve AI destekli repoların %6.4'ünün gizli bilgi sızdırması ile kritik açıkları ortaya koyuyor. Bu analiz, 200+ geliştirici organizasyonunda AI araçlarını yönetme deneyimine dayalı kanıtlanmış yönetişim çerçevelerini, olay müdahale stratejilerini ve güven inşa yaklaşımlarını inceliyor.

Güvenlik Uyandırma Çağrısı

Continue reading...

]]> <![CDATA[AI Geliştirici Araçları Bölüm 4: ROI Analizi ve Gelecek Yol Haritası - Veriye Dayalı Kararlar Almak]]> 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 Özet

200+ mühendise AI geliştirici araçlarını uyguladıktan sonra, finansal gerçeklik satıcı projeksiyonlarından keskin bir şekilde ayrılıyor: gerçek maliyetler ilk tahminlerin 3-5 katı, verimlilik kazançları sistemik darboğazlar tarafından emiliyor, ancak dokümantasyon ve test gibi spesifik kullanım durumları %60-70 verimlilik iyileştirmeleri gösteriyor. Bu analiz, gerçek ROI hesaplama çerçeveleri, stratejik planlama modelleri ve ortaya çıkan AI yeteneklerine hazırlık stratejileri sunuyor. Ölçülebilir iş değeri ile aktivite metrikleri arasındaki fark kritik: satır sayısı ve commit sayısı yanıltıcı olabilir.

ROI Sorusu

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 Özet

Lambda Layer versiyonlarını birden fazla ortamda yönetmek, AWS'in doğrudan çözmediği bir karmaşıklık getiriyor. Bu yazıda production ortamlarında test edilmiş dört versiyon stratejisini inceliyoruz. Özellikle Git-tracked versiyonlar, explicit promotion path'ler ve sıfır runtime overhead sağlayan version manifest yaklaşımına odaklanıyoruz. Çalışan CDK implementasyonları, otomatik deployment pipeline'ları ve rollback prosedürleri dahil.

Durum: Layer Versiyonları Farklılaştığında

Lambda Layer'ları bir versiyon stratejisi olmadan kullanmaya başlayan takımlarda genellikle şu durum ortaya çıkıyor:

Continue reading...

]]> <![CDATA[Rol Belirsizliğinin Gizli Maliyeti: Net Beklentiler Takım Performansını Nasıl Dönüştürür]]> 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 İki takım, bir API'yi kimin tasarlayacağı konusunda üç gün tartıştı. Frontend backend'in halledeceğini varsaydı. Backend önce product requirement'ları bekledi. DevOps "performans endişeleri" için çekildi.

Gerçek API tasarımı? Kimin ne yaptığını netleştirdikten sonra 4 saat sürdü.

Bu teknik bir problem değildi. Rol netliği problemi. Ve organizasyonunuza düşündüğünüzden daha pahalıya mal oluyor.

Kurumsal Ölçekteki Sorun

McKinsey araştırması Fortune 500 şirketlerinin etkisiz karar verme ve rol belirsizliği nedeniyle yıllık yaklaşık 250 milyon dolar boşa harcanan işgücü maliyetine maruz kaldığını gösteriyor.

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 Hiç bir side project'in faturasına bakıp Netflix aboneliğinden daha pahalıya geldiğini görüp şaşırdınız mı? Ya da Next.js uygulamanız için deployment seçeneklerini değerlendirirken Vercel'in platformunun ötesinde bir hayat olup olmadığını merak ettiniz mi? Production migration'ları ve deployment optimizasyonlarıyla çalışmak bana alternatiflerin uygulanabilir olduğunu ve belirli use case'ler için sıklıkla daha üstün olduğunu öğretti.

Next.js uygulamalarını Vercel olmadan deploy etme konusunda keşfettiklerimi, dokümantasyonda kimsenin bahsetmediği gotcha'ları ve production'da karşılaşacağınız maliyetleri paylaşayım.

Bağlam - Ekipler Neden Vercel'in Ötesini Araştırıyor

Continue reading...

]]> <![CDATA[GitHub SpecKit: AI Kod Üretimini Kaostan Üretime Hazır Sistemlere Dönüştürme]]> 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ı. "İzole çalışır" ile "production'a çıkar" arasındaki boşluk bir model yeteneği problemi değil, bir spesifikasyon problemidir. 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 Storage Temelleri - Doğru Çözümü Anlama ve 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 Hiç bir takımın session storage için database index'lerini "optimize etmeye" üç hafta harcadığını, sonra tamamen farklı bir yaklaşıma ihtiyaç duyduklarını fark ettiğini gördünüz mü? Bu pattern sık sık görülür: developerlar relational, document ve key-value database'ler arasında seçim yapıyorlar ama temel farklılıkları ve uygun kullanım alanlarını anlamıyorlar.

Çeşitli teknoloji ekosistemlerinde bu kararlarla çalışmak şunu gösterir: başarının anahtarı sadece hangi teknolojiyi seçeceğini bilmek değil - kararı yönlendiren dört temel soruyu anlamak.

KV Storage Kararlarını Yönlendiren Dört Soru

Data storage sorunlarını değerlendirirken, bu dört soru sağlam bir temel oluşturur:

Continue reading...

]]> <![CDATA[Claude Code ve MCP Ekosisteminde Uzmanlaşma: Kurulumdan Production'a]]> 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 Hiç merak ettiniz mi, bazı geliştirici arkadaşlar Claude Code ile kayda değer ölçüde daha verimli çalışırken siz hala yanıtları kopyala-yapıştır yapmakla uğraşıyorsunuz? Claude Code'u çeşitli MCP (Model Context Protocol) sunucuları ile kullanmak gösteriyor ki, fark daha zeki olmakla ilgili değil - çoğu geliştiricinin varlığından bile haberdar olmadığı araç ekosistemini anlamakla ilgili.

Bu rehber Claude Code ve MCP sunucularını kapsamakta, yaygın kurulum sorunları ve etkili konfigürasyonlar dahil. Uyarıyorum: bu konu teknik detaylara giriyor, ama yolculuğu dürüstçe paylaşacağım - neyin test edilmiş, neyin konsept ve neyin sizin özel ortamınızda doğrulama gerektirdiği dahil.

Gerçeklik Kontrolü: Claude Code Aslında Nedir

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 Launch'tan üç hafta önce proje dashboard'umuzda her şey mükemmel görünüyordu. Tüm yeşil tick'ler, tüm takımlar "hazır" rapor ediyor. Sonra deployment günü geldi ve $2 milyonluk development work'ün neredeyse collapse olduğunu izledim - teknik failure'lar yüzünden değil, ABD takımımızın Hindistanlı developerların feature'ın hazır olduğunu onayladığını sanması, Alman takımın hala proper dokümantasyon beklemesi ve Japon takım üyelerinin kritik endişelerini hiçbir zaman toplantılarda dile getirmemesi yüzünden.

Continue reading...

]]> <![CDATA[Rol Belirsizliğinin Gizli Maliyeti: Net Beklentiler Yazılım Ekibi Performansını Nasıl Dönüştürür]]> 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 Yaygın bir senaryoyu düşünelim: iki engineer API design ownership konusunda üç gün boyunca Slack'te hararetli tartışmalar yapıyor. Frontend ekibi backend'in tasarlayacağını varsayıyor, backend product gereksinimlerini bekliyor, DevOps da "performans endişeleri" için sürükleniyor. Üç gün döngüsel tartışma, kaçırılan deadline'lar ve artan hayal kırıklığı - hepsi kimin neyin sorumlusu olduğunu kimsenin net bir şekilde tanımlamadığı için.

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 Işbirlikçi bir feature üzerinde çalışırken, 10 satırlık kod review thread'inin 47 mesajlık naming convention tartışmasına dönüştüğünü izledim. Tartışma üç gün sürdü ve altı ekip üyesini içerdi. Orijinal bug fix? Hâlâ merge edilmemişti. Ekip morali? Yok edilmişti. İşte o zaman anladım ki Harvard Business Review'ın zor meslektaşlar hakkındaki tavsiyesi temel bir başlangıç sağlasa da, engineering ekiplerinin gerçekte karşılaştığı durumların yüzeyini zar zor kazıyordu. Engineering'e özel arketipler—mükemmeliyetçi engelleyici, teknik pürist, hayalet meslektaş—farklı strateji gerektirir.

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 terminoloji karışıklığının ekibine haftalarca iş kaybettirdiği anlar yaşadın mı? Ben yaşadım. Authentication sistemleri ile çalışmak gösterdi ki en büyük güvenlik hataları genellikle basit yanlış iletişimle başlıyor. OAuth2 uzmanın "authentication yapıyoruz" diye ısrar edip güvenlik audit'in OAuth2'nin authentication'ı handle etmediği için fail olduğu zaman... bu pahalı bir öğrenme deneyimi oldu.

Bu sözlük sadece tanımlar değil. Implementation bağlamı, yaygın yanlış anlamalar ve prodüksiyon sistemlerinden öğrenilen dersler içeren bir saha rehberi. Stakeholder'ların buzzword'leri yanlış kullandığı ya da SMS OTP'nin neden güvenli olmadığını açıklaman gereken anlar için referansın olarak düşün.

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 En verimli takımın temel mimari kararlarda anlaşamadığında ya da code review'lar tüm öğleden sonrayı tüketen felsefi savaşlara dönüştüğünde, daha derin bir disfonksiyonun belirtilerini görüyorsun. Fark anlaşmazlığın kendisinde değil - takımların nasıl yanıt verdiğinde.

Engineering takımlarını gözlemlemek, bu kalıbın farklı bağlamlar ve durumlar genelinde tutarlı şekilde ortaya çıktığını gösteriyor.

Continue reading...

]]> <![CDATA[pnpm Catalog ile Dependency Drift Sorununu Çözmek: Production'da Kanıtlanmış Monorepo Stratejisi]]> 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 Özet

JavaScript monorepo'larındaki dependency drift versiyon çakışmaları, phantom bug'lar ve ciddi developer overhead yaratıyor. Bu analiz pnpm'in catalog özelliğinin nasıl enforcement yetenekleriyle merkezi dependency governance sağladığını, önemli disk alanı tasarrufu, daha hızlı kurulum ve production ortamlarında merge conflict'lerin azalmasını nasıl sağladığını inceliyor.

Durum: Dependency Drift Sorunu

API gateway'ler kritik demo'lar sırasında kriptik TypeScript hataları vermeye başladığında, ve authentication microservice'ler payment processor'lardan farklı @types/node versiyonları çalıştırdığında, dependency drift ciddi bir architectural problem haline gelmiş demektir.

Continue reading...

]]> <![CDATA[İyi Bir Teknik RFC'nin Anatomisi: Bölüm Bölüm İnceleme]]> 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 RFC yazarken boş bir dokümana bakıp, acaba ilk paragraftan sonrasını okuyacak biri olacak mı diye düşündüğünüz o anı bilir misiniz? Bu his tanıdık geliyorsa, yalnız değilsiniz. Çoğu mühendis RFC yazarken aynı belirsizlikle mücadele ediyor. Farklı şirketlerde yüzlerce RFC inceleyerek, bu dokümanları gerçekten faydalı yapan ve sadece bürokratik egzersiz olmaktan çıkaran kalıpları fark ettim.

Continue reading...

]]> <![CDATA[İş Alanlarına Göre Kimlik Doğrulama ve Yetkilendirme Stratejileri: Bankacılık Güvenliği Sosyal Medya Kaosuyla Buluştuğunda]]> 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 tek bir teknik karar değildir; iş alanına göre keskin biçimde farklılaşan düzenleyici kısıtlamaların, kullanıcı beklentilerinin, hata biçimlerinin ve denetim gereksinimlerinin bir bileşimidir. 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. Bir kimlik doğrulama yığınının alanlar arasında yeniden kullanılması genellikle kripto primitifleri üzerinde değil, o alanların farklı ele aldığı uç durumlarda başarısız olur: bankacılıkta step-up kimlik doğrulama, IoT'de delege kimlik, sosyalde nazik bozulma.

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 Code review kültürünün aslında en yetenekli junior developer'larını uzaklaştırdığını fark ettiğin o an var ya? Bu anı çeyreklik ekip retrospektifinde yaşadım. En umut verici developer'larımızdan Sarah, iki hafta boyunca bir feature üzerinde tek başına çalışmayı, kodu review için göndermekten daha çok tercih ettiğini söylediğinde.

Bu gerçekten ağır geldi. Sıkı review'lar sayesinde kaliteyi koruduğumuzu sanıyorduk. Gerçekte, kodunun review edilmesinin, seni başarılı olmanda desteklemekten çok hata bulmakla ilgilenen eleştirmenler kuruluna tez savunuyormuş gibi hissettiren bir ortam yaratmıştık.

Continue reading...

]]> <![CDATA[Copilot'tan Üretim Ortamına: 2 Yıl Sonrası Gerçek Maliyet Analizi]]> 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ı tarafından raporlanan verimlilik sayıları genellikle birinci kümedir; yatırımın kendini amorti edip etmediğini belirleyen ikinci kümedir. Özellikle GitHub Copilot için, ekip büyüklükleri arasında gözlemlenen örüntü şudur: verimlilik-vekil kazanımları gerçektir ama Copilot yazımı kod üzerindeki bakım maliyeti bunlarla birlikte yükselir ve net ROI, ekibin inceleme ve refactor süreçlerinin bu ikinci boşluğu kapatıp kapatmadığına bağlıdır.

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 Hiç üç aylık maliyet değerlendirmelerinden birinde AWS faturası odadaki herkesi sessizliğe gömecek cinsten mi? Ben yaşadım. Üç yıl önce, veritabanı altyapımız Series A fonlaması alan bir startup'tan bile daha hızlı para yakıyordu. Aylık maliyetler 5.400 dolara kadar çıkmıştı, query'ler yoğun trafik sırasında timeout alıyor, en hızlı "çözümümüz" her zaman "daha fazla sunucu ekle" oluyordu.

Bu durum, veritabanı problemlerine donanım fırlatmanın kahve fincanını yangın hortumu ile doldurmaya benzer bir şey olduğunu - pahalı, dağınık ve şaşırtıcı derecede etkisiz - anlamadan önceydi.

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 Özet

Takımlar oybirliği gibi görünen ama gerçek konsensüse sahip olmayan teknik kararlarla mücadele ettiğinde, temel neden genellikle güç dinamikleri ve yetersiz psikolojik güvenliktedir. Bu inceleme, Arnold Mindell'in Deep Democracy ilkelerinin mühendislik karar verme süreçlerini nasıl dönüştürebileceğini ve özellikle kritik içgörüler taşıyan muhalif seslerin dahil olmak üzere her sesin mimari seçimleri nasıl güçlendirebileceğini araştırıyor.

Durum: Sahte Konsensüsün Gizli Maliyetleri

Continue reading...

]]> <![CDATA[LLM Kod İncelemesi: AI'ın İnsanların Kaçırdığını Yakaladığı Anlar]]> 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 En deneyimli güvenlik mühendisinin bir PR'ı onayladığı, üç gün sonra da bunun SQL injection açığı yaratacağını keşfettiğin anı biliyor musun? Bizim başımıza geldi. Açık çok ince bir şekilde gizlenmişti, karmaşık bir query builder pattern'ının içinde, tek başına bakıldığında gayet mantıklı görünüyordu. Pilot test olarak çalıştırdığımız AI inceleyici bunu fark etti.

Bu olay kod incelemesi hakkındaki düşüncelerimi değiştirdi. AI'ın yanılmaz olduğu için değil (inan bana, değil), ama rahatsız edici bir gerçeği ortaya koyduğu için: insanlar da yanılmaz değil ve her birinin masaya ne getirdiği konusundaki varsayımlarımız ciddi bir kalibrasyona ihtiyaç duyuyordu.

Continue reading...

]]> <![CDATA[Monolit'in İntikamı: Microservisler Teknik Borç Haline Geldiğinde]]> 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 mimarinizin, kaçınmaya çalıştığınız dağıtık monolit haline geldiğini fark ettiğiniz o batma hissini biliyor musun? Bu pattern'i birçok şirkette tekrar tekrar gördüm. Microservislerin ne zaman teknik borca dönüştüğünü tanıma ve stratejik olarak nasıl normale dönüleceği konusunda öğrendiklerimi paylaşayım. Dağıtık monolit sendromu genellikle deployment coupling, veri tutarlılığı zorlukları ve koordinasyon yüküyle kendini gösterir. İyi haber: konsolidasyon geçerli bir mimari pattern, başarısızlık itirafı değil.

47 Servisle Alışveriş Sepeti Kâbusu

Continue reading...

]]> <![CDATA[Node.js Geliştiricileri için Go: Serverless Migration Deneyimleri]]> 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 CFO sana gelip geçen ay serverless faturasının 50K dolar olduğunu söyleyip "bunu optimize etmenin bir yolu var mı?" diye sorduğunda, gelecek konuşmayı biliyorsun. Sonrasında yaşananlar Node.js konfor alanımdan Go dünyasına doğru bir yolculuk oldu ve bana performans, takım dinamikleri ve pragmatik mimari kararları hakkında çok şey öğretti.

Farklı şirketlerde Node.js'den Go'ya geçiş süreçlerini yönettim, 8 ile 60 geliştirici arasında değişen takımlarla. Bazı migrationlar müthiş başarılıydı - maliyetleri %70 azaltırken performansı artırdık. Diğerleri "erken optimizasyon"un ne demek olduğunu mükemmel çalışan bir ödeme işleme servisini sadece "Go daha hızlı" diye yeniden yazmaya çalışırken öğretti.

Continue reading...

]]> <![CDATA[Node.js ile Zaman Yönetimi: Moment.js Olmadan Zamana Hükmetmek]]> 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 Özet

Geleneksel monitoring dashboard'ları sağlıklı metrikler gösterirken kritik kullanıcı yolculukları sessizce başarısız olabilir. Bu yazı, distributed tracing ve AI destekli pattern tanımanın ham telemetriyi sistem davranışı hakkında tutarlı hikayelere nasıl dönüştürdüğünü, ekiplerin karmaşık hata modlarını anlamasını ve kullanıcıları etkilemeden önce sorunları tahmin etmesini nasıl sağladığını araştırıyor.

Durum: Yeşil Dashboard'lar Yalan Söylediğinde

Continue reading...

]]> <![CDATA[Ürün ve Teknoloji Ekipleri Arasında Derinlemesine Demokrasi: Deadline Diktatörlüğünden İşbirlikçi Teslimat'a]]> 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 Sprint planning toplantısında oturup Ürün ve Mühendislik ekiplerinin karşı karşıya duran ordular gibi çatıştığını izlediğinde, gelecek pattern'ı biliyorsun. Ürün ekibi board demo'su için altı haftaya üç aylık feature'ları sıkıştırmakta ısrar ediyor. Mühendisliğin kapasite hesaplamaları minimum on iki hafta gösteriyor. "Uzlaşma"? Herkes dört haftanın gerçekçi olduğunu numara yapıyor, mühendislik 70 saatlik haftalarda çalışıp buggy kod gönderiyor, bir sonraki çeyrek production yangınlarını söndürmekle geçiyor.

Bu filmi çok fazla gördüm. Senaryo hiç değişmiyor, ama kayıplar artmaya devam ediyor.

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 Özet

RFC'ler production'la karşılaştığında nadiren değişmeden kalır ve bu mutlaka bir problem değil. Bildirim sistemi implementasyonlarını inceleyerek, zarif tasarımların organizasyonel kısıtlar, timeline baskıları ve beklenmeyen gereksinimlerle karşılaştığında nasıl evrimleştiğini öğrenebiliriz. Bu inceleme, teorik tasarım ile pratik implementasyon arasındaki boşluğu kapatmaya yardımcı olan kalıpları ortaya çıkarır.

Durum: Güzel RFC vs Production Gerçekliği

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 Bir bildirim özelliği "X olduğunda email gönder" olarak başlar ve bir çeyrek içinde çok kanallı bir teslim problemine dönüşür: email, SMS, push ve uygulama içi; her birinin kendi teslim garantileri, retry semantiği ve kullanıcı tercihi yüzeyi vardır. Mimari hata, bunu bir şablon-ve-gönder problemi olarak ele almaktır; asıl problem, kullanıcı-kanal-olay başına fan-out, birleştirme, bastırma ya da erteleme kararını veren ve bu kararı uyumluluk ve destek için denetlenebilir tutmak zorunda olan bir yönlendiricidir.

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 Gerçek zamanlı bildirimler, platforma özgü push bildirim farklılıkları, ölçekte WebSocket bağlantı yönetimi ve trafikle birlikte çoğalan vendor maliyetleriyle uğraşana kadar basit görünür.

Çok kanallı bildirim sistemleri, asıl zorluğun bildirim göndermek olmadığını ortaya çıkarır—güvenilir şekilde, ölçekte, her birinin kendi tuhaflıkları, sınırları ve hata modları olan farklı teslimat mekanizmaları üzerinden yapmak zorluğu. WebSocket'te connection drain, push'ta device token invalidation, email'de bounce handling—her kanal farklı operasyonel zorluklar getirir. iOS ve Android push gereksinimleri farklıdır; WebSocket bağlantı yönetimi Redis veya benzeri bir store gerektirir.

Continue reading...

]]> <![CDATA[Üretim İçgörüleri: Ölçekte Bildirim Teslimatı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 Şu sahneyi hayal et: Yılın en büyük ürün lansmanının tam ortasında. Pazarlama bu özelliği aylardır iter, CEO metrik dashboard'unu izliyor ve aniden bildirim sistemin sessizliğe gömülüyor. Hoşgeldin emailleri yok, push bildirimler yok, uygulama içi alertler yok. Sadece... hiçlik.

Bu hipotetik bir senaryo değil. Bu kâbusun versiyonlarını üç farklı şirkette yaşadım, her seferinde bildirim altyapın ateş altındayken gerçekten neyin önemli olduğu hakkında yeni dersler öğrenerek. Blog yazılarında zarif görünen debugging teknikleri, telefonun giderek daha çılgın Slack mesajlarıyla vızıldadığı sırada 500'ler denizine bakarken çoğu zaman çöküyor.

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 Özet

Bu rehber, bildirim sistemlerini temel teslimat mekanizmalarından sofistike büyüme motorlarına nasıl dönüştürüleceğini kapsamlı analitikler, sistematik A/B testleri ve performans optimizasyonu ile açıklıyor. Sunulan teknikler çok katmanlı analitik pipeline'lar, kullanıcı yolculuğu takibi, güvenlik öncelikli deney framework'leri ve maliyet-bilinçli optimizasyon stratejilerine odaklanıyor.

Durum

Continue reading...

]]> <![CDATA[Etkili RFC Yazma: Teknik Karar Verme Rehberi]]> 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 Basit gibi görünen bir özelliği geliştirmeye başladıktan üç ay sonra, herkesin database schema seçimleri hakkında güçlü fikirleri olduğu o anı biliyor musun? İşte genellikle o zaman bir RFC yazmış olmayı diliyorum.

Continue reading...

]]> <![CDATA[AWS CDK Link Shortener 3. Bölüm: Gelişmiş Özellikler ve Güvenlik]]> 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 AWS CDK Link Shortener 3. Bölüm: Gelişmiş Özellikler ve Güvenlik

Production bir link shortener oluşturmak sadece kısa URL'ler yaratmaktan daha fazlasını gerektirir - meşru ölçeği kaldırabilirken kötüye kullanımı engelleyen kapsamlı güvenlik önlemleri gerektirir. Link shortener'lar, onları zarlı içerik dağıtmak, güvenlik filtrelerini atlatmak ve phishing kampanyaları yürütmek için kullanan 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.

Continue reading...

]]> <![CDATA[AWS CDK Link Shortener Bölüm 4: Production Deployment ve Optimizasyon]]> 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 Deployment ve Optimizasyon

Production optimizasyonu işleri hızlandırmanın ötesinde - herhangi bir yük koşulu altında tahmin edilebilir performans gerektirir. Trafik beklenmedik şekilde arttığında, staging'de mükemmel çalışan infrastructure production'da ölçeklendirme darboğazlarını ortaya çıkarabilir.

En yaygın gözden kaçırılan şey? Database'in peak yükler yerine steady-state trafik için provisionlanması. Normal operasyonlar için optimize edilmiş bir DynamoDB table, kampanyalar veya ürün lansmanları sırasında trafik 10x arttığında darboğaz haline gelebilir.

Bölüm 1-3'te temel, core fonksiyon ve güvenlik inşa ettik. Şimdi onu production deployment ve optimizasyon için kurşun geçirmez yapalım.

Continue reading...

]]> <![CDATA[AWS CDK Link 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 AWS CDK Link Shortener Part 5: Ölçeklendirme ve Uzun Vadeli Bakım

Link shortener'ımızı başlattıktan iki yıl sonra, üçlük business review sırasında telefon geldi. "APAC pazarlarına genişlenmemiz gerekiyor ve Avrupa kullanıcılarımız yavaş redirectler hakkında şikayet ediyor." Basit bir istek olarak başlayan şey, altı aylık global ölçeklendirme projesine dönüştü ve bana herhangi bir mimari kursundan daha fazla distributed sistem öğretti.

Continue reading...

]]> <![CDATA[AWS CDK ile API Versiyonlama: Bir Üretim Vaka Çalışması]]> 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 Öz

Bu vaka çalışması, AWS CDK kullanarak üretim API versiyonlama sisteminin implementasyonunu inceler. Üç başarısız yaklaşım ve bir çalışan çözümün analizi ile, müşteri uyumluluğunu korurken API evolüsyonunu yönetmek için pratik pattern'leri keşfediyoruz. Nihayetinde geliştirdiğimiz yaklaşım minimal operasyonel overhead ile birden fazla API versiyonunu yönetmek için sağlam pattern'ler sunar.

Problem Tanımı

API evolüsyonu kaçınılmaz bir çelişki yaratır: mevcut müşteriler için geriye dönük uyumluluğu korurken API'yi geliştirme ve değiştirme ihtiyacı. Bu zorluk, müşterilerin değişen güncelleme yetenekleri ve deployment pencerelerine sahip olduğu kurumsal ortamlarda yoğunlaşır.

Continue reading...

]]> <![CDATA[Mobil, Web ve API için Kimlik Doğrulama Sağlayıcıları: Doğru Çözümü Seçmek için Eksiksiz Kılavuz]]> 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 Özet

Kimlik doğrulama sağlayıcısı seçimi, geliştirme hızını, güvenlik duruşunu ve operasyonel maliyetleri önemli ölçüde etkiler. Bu analiz, beş kimlik doğrulama yaklaşımını sistematik bir çerçeve aracılığıyla inceleyerek, çeşitli organizasyonel bağlamlarda üretim dağıtımlarına dayalı nicel maliyet karşılaştırmaları, teknik tavizler ve uygulama rehberliği sağlar.

Bağlam ve Problem Alanı

Bir projede parçalanmış bir kimlik doğrulama manzarası devraldım: web uygulamaları için Auth0, mobil istemciler için Firebase Auth, API'ler için özel JWT ve üç ayrı kullanıcı veritabanı. Kullanıcılar web üzerinden kayıt olduğunda ancak mobil üzerinden hesaplarına erişemediğinde ("kullanıcı bulunamadı" hataları), konsolidasyon zorunluluğu netleşti.

...

Continue reading...

]]> <![CDATA[Micro Frontend'lerde Multi-Audience Auth0: Token Yönetimi Kalıpları ve Implementasyon]]> 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 Özet

Auth0 multi-audience authentication'ı dağıtık micro frontend'ler arasında uygulamak, özellikle hem web hem de React Native WebView ortamlarını desteklerken benzersiz zorluklar sunar. Bu vaka çalışması, tek login akışında birden fazla API audience'ını destekleyen birleşik token yönetim sistemi için etkili kalıpları belgeler.

Ele Alınan Temel Zorluklar: - Micro frontend'ler arasında cross-domain token paylaşımı - Auth0 ile multi-audience JWT token yönetimi - React Native WebView'larda silent authentication - Dağıtık uygulamalar arasında token refresh koordinasyonu

Continue reading...

]]> <![CDATA[React Native'de Auth0 ve Biyometrik Kimlik Doğrulama ile Gerçek Dünya Session Yönetimi]]> 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 Özet

Mobil uygulamalarda oturum yönetimi, web geliştiricilerinin nadiren karşılaştığı benzersiz zorluklar sunar. Mobil uygulamalar, kusursuz bir kullanıcı deneyimi sağlarken arka plan durumlarını, ağ kesintilerini, biyometrik kimlik doğrulamayı ve platforma özgü güvenlik kısıtlamalarını yönetmelidir. Bu kılavuz, Auth0 ve biyometrik kimlik doğrulama kullanarak React Native uygulamalarında güçlü oturum yönetimi uygulamak için etkili bir yaklaşım sunar.

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 Seri Navigasyonu

Bu, production-grade link kısaltıcı oluşturma üzerine 5 bölümlük bir serinin 1. Bölümü:

1. Bölüm 1: Proje Kurulumu & Temel Altyapı (Buradasınız) 2. Bölüm 2: Temel İşlevsellik & API Geliştirme 3. Bölüm 3: Gelişmiş Özellikler & Güvenlik 4. Bölüm 4: Production Deployment & Optimizasyon 5. Bölüm 5: Ölçeklendirme & Bakım

---

Giriş: Gerçek Dünya Ölçeği için İnşa Etmek

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 AWS CDK Link Kısaltıcı Bölüm 2: Temel Fonksiyonlar & API Geliştirme

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 yoldur ve 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 özellik, edge'de doğrudan gecikme olarak ücretlendirilir.

Continue reading...

]]> <![CDATA[AWS Fargate 101: Container'larınızın Bakıcıya İhtiyacı Olmadığında]]> 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 İlk kez EC2 instance'larını yönetmekle feature geliştirmekten daha fazla zaman harcadığınızı fark ettiğiniz anı hatırlıyor musunuz? Evet, ben de. Sabah 3'tü, production sunucusuna SSH ile bağlanmış disk alanının neden %98 olduğunu anlamaya çalışıyordum ve aniden çok pahalı bir Linux kutusu bakıcısı olduğumu fark ettim. Bu yazıda Fargate'in ne zaman mantıklı olduğunu, ilk deployment'ı nasıl yapacağınızı ve EC2 Launch Type ile farkları ele alıyorum.

İşte AWS Fargate'in gerçekten çekici görünmeye başladığı an buydu. Aşağıda ilk task definition'ınızı nasıl oluşturacağınızı, network modunu ve EC2 vs Fargate karar kriterlerini adım adım gösteriyorum.

Fargate Aslında Nedir (Pazarlama Lafları Olmadan)

Continue reading...

]]> <![CDATA[AWS Fargate 102: Kimsenin Bahsetmediği Pattern'ler]]> 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. Bu yazıda, production workload'ları çalıştırırken ortaya çıkan gelişmiş pattern'lerden bahsedelim. Bilirsiniz, troubleshooting sırasında sistemin gerçek mekaniklerini anladığınız o anlar var. Maliyet optimizasyonu, stateful container'lar, monitoring ve güvenli deployment'larla devam ediyoruz.

Maliyet Optimizasyonu: İflas Etmeme Sanatı

Fargate'in EC2'den daha pahalı olduğunu söylemiştik. İşte maliyetleri azaltmanın etkili yolları var: Spot, right-sizing, ARM ve Savings Plans. AWS faturaları beklenmedik şekilde artmaya başladığında, sistematik optimizasyon kritik hale gelir.

Fargate Spot: Kimsenin Kullanmadığı %70 İndirim

Continue reading...

]]> <![CDATA[AWS Fargate 103: Size Saatler Kazandıracak Production Dersleri]]> 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 kurulumunuz konusunda kendinize güvendiğiniz, monitoring dashboard'larında her şeyin yeşil göründüğü, sonra da hiç düşünmediğiniz kör noktalar keşfettiğiniz anları bilir misiniz? Production gerçeğine hoş geldiniz.

Continue reading...

]]> <![CDATA[AWS Fargate 104: CDK, Terraform ve SAM ile Deploy]]> 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 hakkında üç yazıdan sonra (101, 102, 103), "güzel de, bunları AWS Console'da tıklayarak değil de nasıl deploy edeceğim, 2015'te değiliz" diye düşünüyor olabilirsiniz.

Fargate servislerini deploy etmek, ekibiniz ve gereksinimleriniz için doğru Infrastructure as Code (IaC) aracını seçmeyi gerektirir. Her yaklaşım karmaşıklık, bakım yapılabilirlik ve geliştirici deneyiminde farklı trade-off'lar sunar.

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

CloudFormation - Temel [code block]

Terraform - Endüstri Standardı [code block]

CDK - Programlama Yaklaşımı [code block]

Her yaklaşımda neyin iyi çalıştığını keşfedelim.

CDK ile Fargate Deploy Etmek

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'lar sadece teorik bir problem değil - kullanıcı deneyimi ile hayal kırıklığı arasındaki fark. Özellikle yoğun trafik anlarında bu gecikmeler kabul edilemez hale gelebilir. Production ortamlarında Lambda function'ları optimize etmekten öğrenilen dersleri paylaşalım.

Cold Start Etkisinin Gerçekliği

Üç aylık business review toplantımız sırasında, ödeme işleme Lambda'mız timeout vermeye başladı. Sorun? 100'den 10.000 eş zamanlı kullanıcıya çıkmıştık ve cold start'lar ödeme işlemlerine 2-3 saniye ekliyordu. Kritik bir business anında veremeyeceğiniz türden bir izlenim.

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, hem performansı hem de maliyeti hemen fark edilmeyen şekillerde etkileyen en önemli konfigürasyon kararıdır.

Potansiyel yatırımcılara kritik bir ürün demosu sırasında ana API'mız timeout hataları vermeye başladı. Suçlu? Kullanıcı analitiği işleyen masum görünen bir function, ayrılan memory'nin %90'ını tüketiyor ve tüm sistem boyunca timeout'lara yol açan garbage collection duraksamalarına neden oluyordu.

Bu olay bana Lambda performansının sadece doğru memory boyutunu seçmekle ilgili olmadığını - memory, CPU ve maliyet optimizasyonu arasındaki karmaşık ilişkiyi anlamayla ilgili olduğunu öğretti.

Continue reading...

]]> <![CDATA[AWS Lambda Production Monitoring ve Debugging: Savaşta Test Edilmiş 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ını ölçekte çalıştırmak bana en önemli dersi öğretti: gerçek test, function'larınızın development'da çalışıp çalışmaması değil - production'da fail olduklarında debug edebilmek. En büyük ürün lansmanımız sırasında, tüm engineering ekibinin izlediği bir anda, bir Lambda sessizce fail olmaya başladı. CloudWatch alert'i yok, açık hata yok, sadece kafası karışmış müşteriler ve hızla düşen conversion rate.

Bu olay bana Lambda monitoring'in sadece temel CloudWatch metrikleri kurmakla olmadığını öğretti - iş problemleri haline gelmeden önce sorunları debug etmenizi sağlayan kapsamlı bir observability stratejisi inşa etmekle ilgili.

Lambda Observability'nin Üç Direği

1. Metrikler: Erken Uyarı Sistemi

Continue reading...

]]> <![CDATA[AWS Lambda Advanced Patterns ve Maliyet Optimizasyonu: Kapsamlı Production Rehberi]]> 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 Startup MVP'lerinden milyonlarca request işleyen enterprise ölçekli sistemlere kadar Lambda function'ları production'da çalıştırmak şunu öğretti: Lambda'nın gerçek değeri herkesin konuştuğu basit kullanım durumlarında değil. Karmaşık mimari zorlukları çözüyorken, büyük ölçekte maliyetleri optimize ederken ve mevcut sistemleri migrate ederken ortaya çıkan advanced pattern'lerde.

Continue reading...

]]> <![CDATA[Middy Yeterli Olmadığında - Özel Lambda Middleware Framework'leri 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 Yeterli Olmadığında - Özel Lambda Middleware Framework'leri Geliştirme

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 AWS Lambda Middleware ile Middy - Temiz Kod ve En İyi Uygulamalar

Bir team'deki Lambda fonksiyonlarını incelediğinizde ortak bir pattern ortaya çıkar: her fonksiyon aynı 40 satır validation, error handling ve CORS setup'ı ile başlar. Bu tekrarlayalı boilerplate bir maintenance challenge haline gelir.

Çoklu Lambda fonksiyonlarını yönetmek genellikle bu challenge'i içerir. Her endpoint authentication, input validation, proper error responses ve security headers gerektirir. Bu boilerplate'i tekrar tekrar yazmak sadece sıkıcı değil - aynı zamanda bir maintenance challenge'i ve potansiyel bug'ların kaynağı haline gelir.

İşte o zaman Middy'yi keşfettik ve açıkçası, Lambda fonksiyonlarını yazma şeklimizi tamamen değiştirdi.

Continue reading...

]]> <![CDATA[AWS Lambda Sub-10ms Optimizasyonu: Kapsamlı Rehber]]> 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 Geçen çeyrek, trading platformumuzun Lambda fonksiyonları ortalama 45ms response süresi veriyordu - yüksek frekanslı trading için her milisaniyen para demek olan bir ortamda tamamen kabul edilemez bir durum. İş gereksinimi açıktı: sub-10ms response, istisna yok.

Runtime migration'ları, veritabanı yeniden yazımları ve gece debugging session'ları içeren üç aylık sistematik optimizasyon sürecinden sonra, tutarlı 3-5ms response sürelerine ulaşıldı. Bu deneyim AWS Lambda'yı performans sınırlarına iterken neler ortaya çıkardığını gösterdi. Her katmanda - runtime, veritabanı, bundle, caching - küçük iyileştirmeler toplamda büyük kazanımlar sağladı.

Problem: Milisaniyeler Para Demek Olduğunda

Continue reading...

]]> <![CDATA[AWS Lambda + S3 Signed URLs: Büyük Dosya Yükleme için Pratik Çözüm]]> 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 Video hosting platformumuz Lambda'nın 15 dakikalık limit'i yüzünden 2GB+ upload'larda timeout yaşıyordu. S3 signed URL'lere geçince 10GB+ dosyaları saniyeler içinde işliyoruz; maliyette %70 tasarruf, %99.9 başarı oranı. Presigned URL Lambda'yı URL üretimiyle sınırlar; upload client'tan doğrudan S3'e gider.

Lambda Maliyet Kabusu

Eski flow'umuz: Her upload için Lambda 15 dakikaya kadar çalışıyor, 2-3GB memory kullanıyordu:

[code block]

Rakamlar: Upload başına 8-12 dk, 2-3GB memory, 10K upload için 30K$+ aylık maliyet, %15 başarısızlık.

Oyun Değiştiren Mimari

Çözüm: Lambda'yı upload pipeline'ından çıkarmak.

[code block]

Continue reading...

]]> <![CDATA[AWS Serverless TypeScript Projelerini Yapılandırma: Eksiksiz Rehber]]> 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 instance'ları üzerinde geleneksel bir Express.js API çalıştırıyordum. Sabit maliyetler, öngörülebilir ölçeklendirme, 99.9% uptime. Hayat güzeldi. Sonra en büyük müşterimiz ayda bir kez, 10 dakika içinde 50.000 webhook işlemesi gerektiren bir özellik istedi.

Continue reading...

]]> <![CDATA[Yıldız Geliştiriciniz İstifa Ettiğinde: Mühendislik Ekiplerinde Bus Factor Yönetimi]]> 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 Şöyle bir senaryo düşünün: Büyük bir ürün lansmanının tam ortasındasınız, her şey yolunda gidiyor ve sonra tüm ödeme sistemini tasarlayan baş mühendisisiniz iki haftalık istifasını veriyor. Rekabet yasağı nedeniyle hemen işten ayrılıyor ve bir rakibe geçiyor.

Aniden fark ediyorsunuz ki paranın uygulamanızda nasıl aktığı, dolandırıcılık tespitinin nasıl çalıştığı ve o bir veritabanı sorgusunun neden tam olarak 47 saniyede tamamlanması gerektiği bilgisi tamamen bir kişinin kafasında yaşıyor. Bus factor problemiyle tanışın.

Bus Factor Gerçeği

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 Bir payment servisi yavaş fail ettiğinde tüm platformu etkileyebilir. Her request timeout olmak için 30 saniye beklediğinde, 12 farklı serviste trafik sıkışması yaratır. Bu klasik zincirleme hata pattern'idir. Circuit Breaker pattern ile bu problemi nasıl çözdüğümüzü ve bu tür incident'ları çözerken resilience hakkında öğrendiklerimizi paylaşacağım.

Problem: Yavaş Olmak Ölü Olmaktan Kötü

Şunu hayal edin: Payment provider'ınızın API'si yavaş cevap vermeye başlıyor. Down değil, sadece normal 200ms yerine request başına 20-30 saniye alıyor. Servisiniz sadakatle bekliyor. Bu arada gelen request'ler birikiyor. Thread pool'lar tükeniyor. Memory consumption patlıyor. Sonunda sağlıklı servisiniz sağlıksız hale geliyor ve enfeksiyon upstream'e yayılıyor.

Continue reading...

]]> <![CDATA[CQRS ve Serverless: DynamoDB Maliyetlerini 70% Azaltıp Performansı Nasıl Artırdım]]> 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 Nedir ve Neden Önemsemelisin?

CQRS (Command Query Responsibility Segregation), yazma işlemlerini (commands) okuma işlemlerinden (queries) ayıran mimari bir pattern'dir. Hem okuma hem yazma için aynı modeli kullanmak yerine, her bir tarafı kendi amacı için optimize edersin. Bu yazıda AWS Lambda, EventBridge ve DynamoDB ile gerçek production uygulamasından öğrendiklerimizi paylaşıyorum.

Temel Prensip

Geleneksel mimarilerde, genellikle hem okuma hem yazma için aynı data modelini kullanırsın:

[code block]

CQRS ile bunu iki optimize edilmiş modele bölersin:

[code block]

CQRS Neden Gerçek Problemleri Çözüyor

CQRS sadece teorik değil – spesifik, ölçülebilir problemleri ele alıyor:

Continue reading...

]]> <![CDATA[Veritabanı Seçim Rehberi: Klasikten Edge'e - Kapsamlı Mühendislik Perspektifi]]> 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 Veritabanı seçim hataları maliyetli olabilir. 1.000 ürünle mükemmel çalışan basit bir ürün kataloğu, 100.000 üründe aniden durma noktasına gelebilir. MongoDB koleksiyonları düzgün indekslenmediğinde ve sorgular tüm koleksiyonları taradığında, "web-scale" çözümü veritabanı temellerinde pahalı bir derse dönüşür.

Bu durum nadir değil. Kötü veritabanı seçimleri, çoğu mühendislerin fark ettiğinden daha fazla projeyi raydan çıkarıyor. Veritabanı uygulamanızın temeli - yanlış seçerseniz, üzerine inşa edilen her şey çatlamaya başlar.

Veritabanı Seçimi Neden Düşündüğünüzden Daha Önemli

Yanlış Seçimlerin Gerçek Maliyeti

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 Eksik Dokümantasyon Beklenenden Pahalıya Malolduğunda

Kritik bir sistemi anlayan kişinin az önce istifa ettiğini fark ettiğindeki o batma hissini biliyor musun? Orada bulundum ve açıkçası bu, başkasının tecrübesinden öğrenmeyi umduğun derslerden biri.

Birkaç yıl önce, takımımız pahalıya mal olan bir öğrenme anıyla karşılaştı. Üç senior mühendis altı ay içinde ayrıldı - normal kariyer gelişimi, dramatik bir şey değil. Tüm "doğru" şeyleri yaptık: devir-teslim, bilgi transfer oturumları, dokümantasyon sprintleri. Ama ödeme sistemimiz en büyük satış hafta sonumuzda sorun yaşadığında, dokümante edilmiş prosedürlerle derin sistem anlayışı arasındaki boşluğu keşfettik.

Continue reading...

]]> <![CDATA[Olay Güdümlü Mimari Araçları: Kafka, SQS, EventBridge ve Cloud Alternatifleri Üzerine Kapsamlı Rehber]]> 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ü sistemlerde doğru aracı seçmek hype'tan çok trade-off'ları anlamakla ilgili. Bu yazıda mesaj kalıplarından başlayıp AWS, Azure ve GCP eşleniklerine, DLQ stratejilerine ve edge deployment'a geçiyoruz.

Mesaj Kalıpları: Temel

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

1'e 1 (Kuyruk Kalıbı) - Mesaj tek consumer tarafından tüketilir (FIFO ile tam olarak bir kez) - Kullanım: Task işleme, iş dağıtımı, async job'lar - Araçlar: SQS, Azure Service Bus Queues, Cloud Tasks

Continue reading...

]]> <![CDATA[Erken Web Dönemi: Script'lerin Basit Olduğu Zamanlar]]> 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.

Bu yazı, frontend tooling'in evrimini inceleyen dört parçalık serinin ilkidir. Elle yazılmış script'lerin ve tarayıcıya özel hack'lerin build öncesi dönemini (1995-2006), bir uyumluluk katmanı olarak jQuery'nin ortaya çıkışını ve deterministik bir build boru hattı fikrini getiren task-runner kuşağını (Grunt, Gulp) ele alır.

Continue reading...

]]> <![CDATA[Task Runner'lar ve Modern Bundling'in Doğuşu]]> 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 2012'ye kadar, manuel build processlerinin problemleri dayanılmaz hale gelmişti. Takımlar, bireysel developer'ların yazdığı ve başka kimsenin anlamadığı 200 satırlık Bash dosyalarından oluşan "deployment script'leri" ile uğraşıyorlardı. Kilit developer'lar şirketlerden ayrıldığında, takımlar herhangi bir şeyi değiştirmekten korkuyorlardı. Build'ler belirli günlerde gizemli bir şekilde fail oluyordu, bu da "salı günleri deploy etmeyin" gibi resmi olmayan kurallara yol açıyordu.

Grunt'ın ortaya çıktığı ortam buydu ve devrimci hissettirdi. İlk kez, karmaşık projeleri handle edecek kadar configure edilebilirken sıkıcı, hata eğilimli işleri otomatize edebilen bir tool'umuz vardı. Ama bu serideki her tool gibi, Grunt bir dizi problemi çözerken tamamen yeni olanları ortaya çıkardı.

Continue reading...

]]> <![CDATA[Performans Devrimi: Rust, Go ve Hız]]> 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 2017'ye kadar, webpack'in hakimiyeti tamamdı, ama developer'ların build zamanlarından duydukları hayal kırıklığı da öyleydi. İlk build'in 45 saniye sürdüğü ve hot reload'ların 3-5 saniye aldığı bir React uygulamasında yaygın olarak yaşanıyordu. webpack'in yavaşlığı yüzünden "flow state"lerini kaybettiklerinden şikayet eden ekip toplantılarında sıkça dile getiriliyordu.

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.

Bu, frontend tooling'de performans devrimini ateşleyen ortamdı - JavaScript-based tool'lardan her şeyi değiştirecek native compiled çözümlere doğru temel bir geçiş.

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 Git dallanma stratejisi, devam eden işin bir sürüme nasıl dönüşeceğini tanımlar: kimin nereye commit edebileceği, dalların ne zaman birleşeceği ve main dalının her an deploy edilebilir olup olmadığını neyin belirlediği. Stratejiler arasındaki dengeler (trunk-based development, GitHub Flow, Git Flow, release branch'leri) gerçek ve alana özeldir; üç kişilik bir mobil ekip için mükemmel çalışan bir strateji 25 geliştiricide kırılır, 25'e ölçeklenen strateji ise üç kişilik ekibe gereksiz koordinasyon yükü getirir. Çoğu dallanma stratejisi başarısızlığı aslında stratejinin kendisiyle ilgili değildir; ekip büyüklüğünü ya da ürün temposunu aşan bir stratejinin hâlâ uygulanıyor olmasıyla ilgilidir.

Continue reading...

]]> <![CDATA[Google Closure Compiler: Modern JavaScript Tooling'in Unutulan Öncüsü]]> 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 2009 yılında JavaScript'in hala birçok enterprise developer tarafından "oyuncak dili" olarak görüldüğü dönemde, Google sessizce iki teknolojiyi açık kaynak olarak yayınladı: Closure Compiler ve Closure Library. Bu araçlar, JavaScript optimizasyonu ve büyük ölçekli web uygulamaları hakkındaki düşüncelerimizi temelden şekillendirecekti.

Continue reading...

]]> <![CDATA[Mermaid Diyagram Vitrin: Tüm Grafik Tipleri]]> https://sph.sh/tr/posts/mermaid-diagram-showcase/ https://sph.sh/tr/posts/mermaid-diagram-showcase/ Thu, 04 Sep 2025 00:00:00 GMT Tüm Mermaid diyagram tiplerini interaktif örneklerle keşfedin. Her diyagram, optimal deneyim için yakınlaştırma, kaydırma ve tam ekran görüntülemeyi destekler - ancak interaktif özellikler tarayıcınıza ve platformunuza bağlı olarak değişebilir.

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.

Border-first (site standardı): Stilli düğümlerde tek nötr dolgu (#1e293b) ve anlam stroke renkleri kullanılır; parlak düğüm dolguları yok. Palet ve şablonlar için docs/BLOG_WRITING.md dosyasına bak.

[code block]

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

Continue reading...

]]> <![CDATA[Micro Frontend'ler: İleri Düzey Pattern'ler, Performance 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 Navigasyon

- 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: Bu yazı Kısım 1 temellerine ve Kısım 2 uygulama kalıplarına aşinalık varsayar.

---

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 geri kazanır.

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: Bu yazı Bölüm 1'deki kavramlar üzerine kuruludur. Micro frontend'lere yeniyseniz, önce oradan başlayın.

---

Continue reading...

]]> <![CDATA[Factory Pattern'inin Ölümü: Saf Fonksiyonlarla Node.js Kodumuzun 40%'ını Nasıl Sildik]]> 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 Hiçbir İşe Yaramayan 847 Satırlık Service

20 dakika sürmesi gereken bir ödeme işleme bug'ını debug ediyordum. Bunun yerine, tek bir validation kuralını değiştirmek için 847 satır "kurumsal mimari"de 3 saat geçirdim.

Suçlu? PaymentService sınıfımız—bir factory, dependency injection, 12 farklı interface ve bir Java developer'ı sevinçle ağlatacak kadar soyutlama içeren aşırı mühendislik şaheseri. Event-driven Lambda mimarisinde pure function'lar bu tür class yapılarını geçer: daha az boilerplate, daha kolay test, daha hızlı iterasyon.

[code block]

Düzeltmeye çalıştığım bug? Basit bir validation: "Kredi kartı numaraları boşluk içermemeli."

Saf fonksiyonlar ve event-driven mimariye geçişimizden sonra, aynı fonksiyonalite şöyle oldu...

Continue reading...

]]> <![CDATA[Mobil Micro Frontend'ler: Production'da Çok Kanallı Deneyimler]]> 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 Bir projede takımımız giderek yaygınlaşan bir meydan okumayla karşılaştı: farklı takımlardan gelen, her birinin kendi deployment döngüleri ve teknoloji stack'leri olan birden fazla web tabanlı servisi entegre edebilecek bir mobil uygulama oluşturmamız gerekiyordu. Yakalayıcı nokta? Teslim etmek için 8 haftamız vardı ve web takımları bize yardım etmek için özellik geliştirmelerini durduramazdı.

İşte o zaman WebView'ları kullanarak React Native uygulamamıza micro frontend mimarisi getirmeye karar verdik. Ardından gelen 6 ay hata ayıklama, performans optimizasyonu ve hiç uygulayacağımı düşünmediğim yaratıcı çözümlerle doluydu. İşte öğrendiklerimiz.

Mobil Micro Frontend Serisi

Continue reading...

]]> <![CDATA[Mobil Micro Frontend'lerde WebView İletişim 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 mimarimizi devreye aldıktan üç ay sonra bir duvara çarptık. WebView-native iletişimimiz debugging kâbusu haline geliyordu. Mesajlar kayboluyordu, platformlar arası tipler eşleşmiyordu, ve production'da WebView'ların içinde neler olduğunu takip edemiyorduk. Bu yazıda PostMessage tabanlı bridge pattern'imizi, type-safe iletişim katmanını ve production'dan öğrendiklerimizi paylaşıyorum.

Continue reading...

]]> <![CDATA[Monolitten Event-Driven Fonksiyonlara: Node.js Mimari Evrim 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 Monolitler Sürdürülemez Hale Geldiğinde

Yoğun trafik sırasında production incident'ları bir kalıp haline gelmişti. Node.js monolitimiz - yüz binlerce satır "kurumsal kalitede" MVC kodu - sürekli olarak yük altında zorlanıyordu. 45+ dakikalık deploy süreleri, kritik düzeltmelerin bile production'a ulaşmasının çok uzun sürdüğü anlamına geliyordu.

Bu deneyim bize asıl problemin sadece teknik borç değil, mimari olduğunu öğretti. Monolit, tek bir takımın etkili bir şekilde sürdürebileceği, debug edebileceği ve geliştirebileceği noktanın ötesine geçmişti.

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. Bu pattern'i ne zaman ve nasıl implement edeceğinizi anlamak, sürdürülebilir büyüme ile operasyonel kaos arasındaki farkı belirleyebilir.

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 organizasyonlar için işe yarayabilen, ölçek arttıkça çeşitli kritik zorluklar yaratır.

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:

[code block]

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ük sorunları yaşar. Yerel ortamda çoğaltılamayan çökmeler, rastgele performans sorunları ve destekleyici veri olmadan kullanıcı şikayetleri yaygın zorluklardır. Bu rehber, production sorun giderme ve optimizasyon için gereken içgörüleri sağlayan kapsamlı gözlemlenebilirlik implementasyonunu kapsar.

Zorluk: Mobile Gözlemlenebilirlik Gereksinimleri

Production mobile uygulamaları, web uygulamalarından farklı benzersiz monitoring zorluklarına sahiptir. Sessiz hatalar, cihaza özel sorunlar ve network değişkenliği, geleneksel loglama yaklaşımlarının ele alamayacağı kör noktalar yaratır.

Mobile gözlemlenebilirlik için temel gereksinimler:

Continue reading...

]]> <![CDATA[Server-Side HTTP Client'lar: Native Fetch'ten Effect'e, Production Deneyimleri]]> 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 HTTP Client Zorluğu

Microservice mimarileri genellikle basit başlar - servisler edge case'ler üzerinde fazla düşünmeden HTTP üzerinden haberleşir. Sonra yüksek trafik olayları sınırlamaları ortaya çıkarır. Payment servisleri yük altında timeout'a düşmeye başlayabilir, request başına 30 saniye takılabilir.

Yaygın bir sorun: proper timeout handling olmadan native fetch kullanmak. Bu takılan connection'lar Lambda concurrent execution'ları tüketebilir ve infrastructure maliyetlerini etkiler.

Continue reading...

]]> <![CDATA[Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 1 - Neden Geçiş Yapalım?]]> 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, CloudFormation üzerinde typed, AWS-native, programatik bir sentez katmanıdır. Serverless Framework ücretli lisans modeline geçtiğinde, migrasyon kararı varsayılan olmaktan çıkıp aktif bir dengeye dönüştü ve iki araç arasındaki seçim aslında lisans maliyetinden çok, ekibin buyurucu ve bildirimsel altyapıyla ne kadar rahat ettiğine, type safety gereksinimine ve daha derin native kapsama karşılığında AWS'e kilitlenmeyi kabul edip etmediğine bağlıdır.

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 CDK migration'ımızın 1. haftası. Karar verilmişti, bütçe onaylanmıştı ve 12 kişilik ekibim beklenti içinde bana bakıyordu. "Peki, nereden başlıyoruz?"

CDK'yı kişisel projelerde kullanmıştım, ama onu 4 environment'ta 12 developer ile 47 Lambda fonksiyonunu handle edecek şekilde scale etmek? Bu farklıydı. Sadece benim için değil, tüm ekip için çalışacak yapı, kurallar ve pattern'lere ihtiyacımız vardı.

Bu, 12 mühendisinin birbirlerinin ayağına basmadan paralel çalışmasını sağlayan, Serverless Framework'teki tanıdık pattern'leri koruyan ve 2.8M$ ARR platformumuzun temeli haline gelen bir CDK proje yapısını nasıl tasarladığımızın hikayesi.

Continue reading...

]]> <![CDATA[Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 3 - DynamoDB ve S3]]> 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ı, gerçek migration karmaşıklığının ortaya çıktığı yerdir. Basit bir YAML-to-TypeScript dönüşümü gibi görünen şey, hızlıca bundling optimizasyonu, memory ayarlama ve hata yönetimi pattern'lerini içeren çok katmanlı bir challenge olarak kendini gösterir.

Bu migration boyunca fonksiyon pattern'lerini standartlaştırma, cold start'ları optimize etme ve sürdürülebilir API konfigürasyonları oluşturma konularında değerli dersler öğrendim. Farklı memory ayarları, timeout konfigürasyonları ve deployment pattern'leri olan Lambda fonksiyonlarını migrate ederken öğrendiklerimi paylaşıyorum.

Continue reading...

]]> <![CDATA[Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 4 - EventBridge ve SQS]]> 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 CDK migration'ımızın 5. haftası. 23 Lambda fonksiyonunu başarıyla taşımıştık, ama gerçek zorluk Lead DevOps Mühendisimiz ayrıldığını duyurduğunda başladı. "Database migration ile iyi şanslar," dedi ve 2.8M$ ARR SaaS platformumuzu destekleyen üç DynamoDB tablo adının yazdığı yapışkan notu verdi.

O yapışkan not 4 yıllık customer verisini, 180K kullanıcıyı ve sıfır dokümantasyonlu backup prosedürünü temsil ediyordu. Bu, tek bir kayıt kaybetmeden stateful infrastructure migrate etme hikayesi - ve production sistemlerdeki data dependency'leri hakkında öğrenilen acı dersler.

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, hem güvenlik duruşunu hem de uygulama performansını etkileyebilecek benzersiz zorluklar sunar. Organizasyonlar genellikle Serverless Framework implementasyonlarının organik büyüme ve hızlı iterasyon döngüleri yoluyla güvenlik borcu biriktirdiğini keşfederler.

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 - Production İpuçları]]> 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ı üretilen altyapının doğruluğu değil, kesme anındaki operasyonel hazırlıktır: trafiği almak için bir plan, migrasyon üretimi bozarsa geri dönmek için bir plan ve canlı yük altında çıkan herhangi bir drift'i uzlaştırmak için bir plan. Onlarca Lambda fonksiyonu ve birden fazla DynamoDB tablosunu kapsayan bir migrasyon için kesme planı, migrasyon kodunun kendisinden büyüktür; geri dönüş hızlı, granüler ve production'a yük taşınmadan önce test edilmiş olmalıdır.

Continue reading...

]]> <![CDATA[DynamoDB Toolbox ile Serverless TypeScript Projelerini Kolaylaştırma]]> 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.

DynamoDB Toolbox bu zorlukları, DynamoDB operasyonlarını bakım yükünden geliştirici-dostu ve ölçeklenen bir deneyime dönüştürerek çözer. İşte gücünü etkili bir şekilde nasıl kullanacağın.

Tool Adaptasyonunu Yönlendiren Zorluklar

AttributeValue Karmaşıklığı

Raw DynamoDB SDK ile çalışmak her gün böyle kod yazmak demekti:

[code block]

Continue reading...

]]> <![CDATA[React Native'de SWR Tarzı Feature Flag'ler]]> 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 Memorial Day hafta sonu 2023. Sabah 2:47. 50.000 dolar değerindeki işlemleri işlerken ödeme sistemimiz çöktü. Suçlu? Yüklenmesi 8 saniye süren bir feature flag'i, checkout akışımızın timeout olmasına neden oldu. Yarı uykulu kullanıcılar alışverişlerini tamamlayamadı, sepetlerini terk ettiler ve bir hafta sonunun gelirini kaybettik.

Bu olay bana feature flag'lerin sadece konfigürasyon olmadığını—kritik altyapı olduklarını öğretti. Stale-while-revalidate pattern'i hem cache hit sağlar hem de arka planda güncel değer çeker; timeout'ları önler. Sistemimizi stale-while-revalidate pattern'i ile yeniden kurduktan sonra, tek bir timeout olmadan günde 2M+ flag isteği işliyoruz. İşte nasıl yaptığımız.

Memorial Day Felaketi: Neyin Yanlış Gittiği

Continue reading...

]]> <![CDATA[Holakrasi'den Team Topologies'e: Gerçek Otonomi için Teknik Takımların Tasarımı]]> https://sph.sh/tr/posts/team-autonomy-structures/ https://sph.sh/tr/posts/team-autonomy-structures/ Thu, 04 Sep 2025 00:00:00 GMT Liderlik „takımlara daha çok otonomi veriyoruz" dediğinde ilk aklınıza gelen „bu işler karışabilir" değil mi? Yeterince org yeniden yapılandırması gördükten sonra, sınırları olmayan otonominin genelde çözdüğünden çok problem yarattığını öğrendim. Bu yazıda Holakrasi, Spotify modeli ve Team Topologies'den seçerek aldığımız yapıları paylaşıyorum.

Birkaç yıl önce matriks proje takımlarından ürün moduna, akışa-hizalanmış takımlara geçtik. Hız gerçekten arttı ama istenmeyen sonuçlar da geldi - daha fazla defekt, tekrarlanan çaba ve takımların birbirinin ayağına basması. Öğrendiğim şey (bazen zor yoldan) etkili otonominin kısıtlamaları kaldırmak değil, doğru olanları tasarlamak olduğu.

Continue reading...

]]> <![CDATA[MDX Blog Tipografi ve Stil Rehberi]]> https://sph.sh/tr/posts/typography/ https://sph.sh/tr/posts/typography/ Thu, 04 Sep 2025 00:00:00 GMT Bu rehber, modern markdown işlemcilerinde mevcut olan tüm markdown tipografi özelliklerini ve formatlama seçeneklerini gösterir.

Başlıklar

Başlık 1 (H1) 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

Kalın metin önemli bilgileri öne çıkarır. İtalik metin belirli kelimelere vurgu ekler. Kalın ve italik her iki stili maksimum etki için birleştirir. ~~Üstü çizili metin~~ silinmiş veya kullanımdan kaldırılmış içeriği gösterir.

Satır İçi Kod

Continue reading...

]]> <![CDATA[Zod ve OpenAPI ile Type-Safe AWS Lambda API'leri]]> 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 API dokümantasyon drift'i hakkında acı bir ders: Kullanıcı API'sine opsiyonel bir alan eklemek ama OpenAPI spec'ini güncellememek, bir kurumsal müşterinin entegrasyonunu bir gecede bozdu. Onların code generation pipeline'ı eski şemayı bekleyen TypeScript arayüzleri üretti. Onların kod generation pipeline'ı eski şemayı bekleyen TypeScript arayüzleri üretti, yüzlerce başarısız kullanıcı kaydı ve önemli gelir kaybına neden oldu.

Bu olay API dokümantasyonunun sadece nice-to-have olmadığını gösterdi – kritik iş altyapısıdır. Bu yaklaşım Zod şemalarından otomatik olarak OpenAPI spec'leri üreten sistemlerin yeniden oluşturulmasını içerir; tek doğruluk kaynağı daha güvenli API evrimi sağlar. CDK ile production stack örneği aşağıda.

Continue reading...

]]>