Tek Bir CLI'dan Beş Dilde Backend Üretmek

Re-Shell hakkında aldığım en yaygın itiraz, aynı zamanda en makul olanı. Tek bir CLI, beş farklı dil ekosistemi genelinde neden backend servisleri üretsin? Bu, kimsenin istemediği bir özellik uğruna, bakımı yapılacak beş kat yüzey alanı değil mi? Adil bir soru ve dürüst cevap, beş dili kendi başına desteklemeye niyetlenmediğim. Bir ekibi tek bir backend yığınına evlendirmeyi durdurmaya niyetlendim ve o hedef, beğensem de beğenmesem de beni buraya getirdi.

Beş Ekosistem

CLI, beş ailede servis üretiyor. .NET için hem ASP.NET Core Web API hem de Minimal API tarzını iskeleliyor çünkü ekipler gerçekten hangisini tercih ettikleri konusunda bölünüyor. JVM için Spring Boot, Quarkus, Micronaut ve Vert.x'i kapsıyor; bunlar arasında geleneksel kurumsal varsayılandan reaktif, düşük ek yüklü uca kadar her şeyi içeriyor. Rust için Actix-Web, Warp, Rocket ve Axum üzerinde servisler üretiyor. Python için FastAPI ve Django'yu yapıyor; bunlar yapı-hız ekseninde çok farklı noktalarda oturuyor. Ve birçok ekibin varsayılan olarak başladığı yer olan Node.js'i yapıyor.

Bu çok sayıda çerçeve ve onları listelemek kolay kısım. İlginç soru, bunu bir bakım kâbusu yerine bakımı yapılabilir kılan şeyin ne olduğu.

Neden Sadece Tek Bir Yığın Seçmeyelim

Alanımızdaki içgüdü standartlaştırmaktır. Tek bir backend yığını seç, onda iyi ol ve asla geriye bakma. Cazibesini anlıyorum ve tek bir ekip için genellikle doğru karar. Ama Re-Shell bir platform ve bir yığını sabit kodlayan platformlar, onları benimseyen herkes adına sessizce bir karar verir. Derin .NET uzmanlığı olan bir ekip, araçlarımı kullanmak için içgüdülerini yeniden yazmak zorunda kalmamalı. Bir Rust servisinin çıktı (throughput) özelliklerine ihtiyaç duyan bir ekip, platformdan ayrılmadan birine uzanabilmeli.

Değer, herhangi bir tek projenin beş dilin hepsini kullanması değil. Neredeyse hiçbiri kullanmayacak. Değer, projenin ilk gün verdiği seçime evli olmamasıdır. Re-Shell'in sahiplendiği dikişler — bir servisin nasıl kaydedildiği, sağlık ve gözlemlenebilirliği nasıl açığa çıkardığı, hangi sözleşmeyi konuştuğu — servisin neyle yazıldığına bakılmaksızın aynı kalır. Dili, temel bir taahhüt yerine değiştirilebilir bir ayrıntı yapan şey budur.

Neyin Paylaşılan, Neyin Spesifik Kaldığı

Tüm bu, yalnızca neyin paylaşıldığı ile neyin dile özgü olduğu arasındaki temiz bir çizgi sayesinde işliyor. Paylaşılan katman, konvansiyonlardır. Üretilen her servis, dili ne olursa olsun, sağlığı ve hazır olma durumunu (readiness) aynı şekilde açığa çıkarır, kendini aynı şekilde kaydeder, aynı sözleşmeleri konuşur ve aynı gözlemlenebilirlik iskelesini izler. Bir Re-Shell servisi gördüyseniz, yazmadığınız bir dilde bile herhangi birinde nereye bakacağınızı bilirsiniz.

Zorunlu olarak spesifik olan, o çizginin altındaki her şeydir. İdiyomatik Rust hata yönetimi, idiyomatik Python'a hiç benzemez. Spring Boot'un bağımlılık enjeksiyonunun bir Minimal API kurulumunda karşılığı yoktur. Bu farkları, her dilde garip ve hiçbirinde idiyomatik olmayan kod üreten en düşük ortak payda bir soyutlamayla örtmeye çalışmıyorum. Üreteçler, o ekosistemdeki kıdemli bir mühendisin normal olarak tanıyacağı kod üretir. Tutarlılık, uygulamaları birbirine benzetmeye zorlamakta değil, arayüzlerde ve konvansiyonlarda yaşar.

Üreteçleri Tutarlı Tutmak

Pratik zorluk, bu üreteçlerin geliştikçe birbirinden ayrılmasını önlemektir. Bunu yönetme şeklim, konvansiyonları gerçeğin kaynağı ve dil şablonlarını o konvansiyonların uygulamaları olarak ele almaktır. Sağlık kontrollerinin nasıl yapılandırıldığını değiştirdiğimde, bu konvansiyona bir değişikliktir ve her üretecin yeni konvansiyonu karşılaması gerekir. Şablonlama yaklaşımı kasıtlı olarak zekice değil. Her ekosistemin, bir kerede beş dili soyutlamaya çalışan tek bir mega şablon yerine, kendi başlarına okunabilir olacak şekilde yazılmış kendi şablonları var.

Bu, tam olarak bir yapay zekâ kodlama ajanının gerçekten faydalı olduğu ve tam olarak sınırlarının göründüğü türden bir iş. Bir konvansiyonu güncellediğimde, o değişikliği bazılarında daha güçlü olduğum idiyomlarda beş dil şablonu genelinde yaymanın işi devasa ve tekrarlayıcı. Claude o yaymada iyidir ve bir dildeki bir idiyomun başka birinde temiz bir karşılığının olmadığı yeri işaretlemekte iyidir; bu da genellikle ilginç tasarım sorularının saklandığı yerdir. Rust'ım sağlam ve Vert.x'im daha paslı; daha az dokunduğum bir çerçevede idiyomatik versiyonu taslayabilen bir ajana sahip olmak — ki sonra onu konvansiyona karşı incelerim — beş ekosistemi bir kişi için sürdürmeyi mümkün kılan şey budur. Yapamayacağı şey, konvansiyonun ne olması gerektiğine karar vermektir. O muhakeme bende kalır çünkü bu servislerin üretimde gerçekte nasıl başarısız olduğunu bilmeye bağlıdır.

Tüm Bunların Anlamı

Beş dilde backend üretmek bir hava atma değil. Bir yığın seçimini platforma gömmeyi reddetmenin doğrudan bir sonucu. Konvansiyonlar gerçek ürün. Diller, tutarlı bir dikiş seti üzerindeki birbirinin yerine geçebilir yüzeyler ve onu bu şekilde gördüğünüz an, beşini desteklemek, beş kat iş gibi görünmeyi bırakır ve beş ön yüzü olan tek bir platform gibi görünmeye başlar. Re-Shell'in yaptığı bahis bu ve şimdiye kadar tuttu.