Proxylity, sunucusuz UDP ağ geçitleri için AWS CDK construct kütüphanesi yayınladı

Proxylity, sunucusuz UDP ağ geçidi servisini tipli ve yeniden kullanılabilir yapı taşlarına saran açık kaynak bir AWS CDK construct kütüphanesi olan @proxylity/cdk-udp-gateway'ı yayınladı. 19 Ekim 2026 tarihinde dev.to'da yayımlanan bir yazı, kütüphanenin nasıl tasarlandığını adım adım anlatıyor; ve anlattığı süreç — bilinçli bir katmanlama ile dağıtımdan önce IAM hatalarını yakalayan bir doğrulama altyapısı — büyük olasılıkla sürümün kendisi kadar ilginç.

Yerini aldığı tekrarlayan kod

AWS Cloud Development Kit, geliştiricilerin CloudFormation JSON ya da YAML'ı elle yazmak yerine TypeScript, Python, Java, C# ve Go gibi dillerde altyapı tanımlamasına olanak tanıyor. Yazıda belirtildiği gibi, ergonomik değerin büyük kısmı L2 seviyesinde bulunuyor: mekanik bir L1 yansımasının üzerine makul varsayılanlar, tipli referanslar ve otomatik olarak türetilen IAM ekleyen, görüş belirten sarmalayıcılar.

Proxylity UDP Gateway, yönetilen bir dinleyici uç noktası sunuyor — UDP, WireGuard veya DTLS — ve gelen datagramları Lambda, SQS, Kinesis, Firehose, S3 ve Step Functions gibi AWS hedeflerine, çalıştırılacak, yamalanacak veya ölçeklenecek sunucu olmadan toplu olaylar olarak iletiyor. Şimdiye kadar bir dinleyici sağlamak, CloudFormation custom resource'larını elle yazmak anlamına geliyordu: hesap ve bölge yapılandırma eşlemelerini çözmek, service token ve API anahtarlarını her kaynağa bağlamak ve her hedef için ayrı bir en az ayrıcalıklı IAM rolünü elle oluşturmak. Yazıya göre her hedef, bir teslimatın gerçekte hangi API eylemlerini gerçekleştirdiğine ve bunların nasıl kapsamlandırıldığına dair bir araştırma çalışmasına denk geliyordu; bunu ince bir şekilde yanlış yaparsanız stack sorunsuz dağıtılıyor, sonra runtime'da başarısız oluyordu.

Önce L1, ve kalıcı olarak korunuyor

Ekip, herhangi bir kolaylık API'sinden önce sadık bir L1 katmanını kasıtlı olarak inşa etti ve bunu L2'nin altında kalıcı olarak tuttu. L1, temeldeki custom resource'ların kabul ettiği her şeyi açığa çıkarıyor ve hiçbir şey uydurmuyor; bu da onu hem bir temel hâline getiriyor — L2 tamamen L1 construct'larından oluşturuluyor ve asla ham CloudFormation üretmiyor — hem de L2'nin görüşleri belirli bir kullanım senaryosuna uymadığında kalıcı bir kaçış kapısı sağlıyor. Yazı, bunun bazı kod tekrarına mal olduğunu kabul ediyor; karşılığında hem kullanımı kolay hem de şeffaf bir kütüphane elde ediliyor.

Omurga olarak doğrulama

Yazarın diğer ekiplerin de benimsemesini en çok istediği disiplin, dağıtılan servisin gerçek davranışını; dokümantasyonun, örnek şablonların ya da herhangi birinin zihinsel modelinin önünde tek yetke kaynağı olarak ele almak. Bunu somutlaştıran iki uygulama var. Birincisi, altın synth-diff: servisin yayımladığı bilinen iyi örnek şablonların her biri için, construct'larla eşdeğer bir stack yazılıyor, synth ediliyor ve kanıtlanmış şablonla özellik özellik eşleştiği doğrulanıyor; böylece herhangi bir sapma bir testi kırmızıya çeviriyor. İkincisi, doğrulanmış davranışa dayanmayan bir IAM izninin ya da davranışsal iddianın kusur sayıldığı bir inceleme kuralı; yazı, bunun aksi hâlde dağıtım sırasında kabul edilecek ve daha sonra sessizce başarısız olacak, makul görünen izinleri defalarca yakaladığını söylüyor ve AWS GovCloud ve Çin gibi partition'lar arasındaki servise özel en az ayrıcalıklı IAM'ın gerçekten ince ayrıntılı olduğunu belirtiyor. Varsayımlar, dokümantasyon ve gerçeklik arasındaki uyuşmazlıklar, sessizce çözülmek yerine gözlemlenen davranışla ve alınan kararla birlikte kayıt altına alınıyordu. Yazarın sonucu: kalite zekâdan değil, doğrulamadan geldi.

Tek dinleyici, dört protokol

Ana API tasarım sorusu, protokole özgü ayarların nasıl modelleneceğiydi — WireGuard'ın peer'ları, DTLS'nin pre-shared key ve early-data pencereleri, WebRTC'nin bir sinyalleşme modulu var — bir dinleyici tam olarak tek bir protokol konuşurken temelde tek bir uç noktası ve paylaşılan tek bir hedef kümesi olan tek bir kaynaktır. Kütüphane, dört ayrı sınıf ya da bir kalıtım hiyerarşisi yerine, mühürlü bir protokol fabrikasıyla tek bir Listener construct'ı sunuyor: ListenerProtocol.udp(), .wireGuard(), .dtls() ve .webRtc(); her biri yalnızca kendi ilgili seçeneklerini ortaya koyuyor. Yazı, ikinci bir tasarım sorusunun da API'yi şekillendirdiğini söylüyor; ancak akışta mevcut olan metin, bunu tarif etmeden önce kesiliyor.

Neden önemli

Daha önce kopyala-yapıştır custom resource tekrarları olarak var olan altyapı desenleri, paketlenmiş, tipli ve test edilebilir soyutlamalara dönüşüyor — ve burada en çok önem taşıyan başarısızlık modu olan, dağıtımı geçen ama runtime'da başarısız olan yanlış kapsamlı IAM, üretim olaylarından tasarım incelemesine taşınıyor. Metodoloji ayrıca aktarılabilir: L1'in L2 altında katmanlanması ve altın şablon synth-diff'i, mevcut bir servisi CDK ile saran herhangi bir ekibe uygulanabilir; yazının bu yüzden bir sürüm notu kadar mühendislik playbook'u gibi okunması da bu yüzden.