Arda Çetinkaya Yazılım ve arada kendim ile ilgili karaladıklarım…

.NET Core 3.0‘un RTM olarak yayınlanmasına yaklaşıyoruz. Büyük bir ihtimal Mayıs’taki Build etkinliğinde ya da ondan hemen sonra Haziran gibi yayınlanır diye düşünüyorum. Artık göreceğiz… Ciddi anlamda birçok yenilik ve performans iyileştirmeleri ile olgunlaşmaya devam ediyor. Bunlar dışında birçok değişiklik de v3.0’da karşımıza çıkıyor. Açıkçası yeni özelliklerden şu an çok bahsetmek istemiyorum hem kendi dokümantasyonları olsun hem internetteki birçok güzel kaynak olsun bunları takip etmek mümkün, -ki zaten üşenmiyor da değilim… 🙂 Şaka bir yana bir ara derleyip, toplamam lazım ki ben de günceliyim kendimi. Baya güzel özellikler geliyor çünkü. Neyse…

Malum .NET Core 3.0 ile beraber ASP.NET Core 3.0‘da yayınlanıyor. Orada da var güzellikler, ama dediğim gibi bu yeniliklerden de bahsetmeyeceğim(şimdi) daha çok değişikliklerden bahsetmeye çalışacağım. Çünkü ciddi anlamda önceki versiyonlarda(2.x) olan bazı temel özellikler değişiyor. Bu değişiklikler “breaking-changes” olarak adlandırabileceğimiz derecede, yani derlenebilen uygulamamızı .NET Core/ASP.NET Core 3.0’a yükselttiğimizde derlenemez hale gelebilmektedir, -duruma göre. Bunu hazırlık olsun diye, mevcut v2.2 projelerimizi preview versiyonlarını deneyimlerken yaşadığım için de ekstra paylaşmak istedim.

Shared Framework kullanımı değişiyor…


Şimdi biraz başa gidelim… .NET Core’un versiyon bazında tek başına çalışmasını sağlayan uygulama tipleri hayatımıza girmişti hatırlarsanız. Bunu sağlamak ve bazı geliştirmeler için kullandığımız tüm referansları tek bir çatı altında, aynı versiyonlar ile birleştirmek için ASP.NET tarafında Microsoft.AspNetCore.App şeklinde bir “package reference” proje dosyamızın içinde vardı, daha doğrusu olabiliyordu. Bu sayede aynı versiyon bileşenlerin kullanılması, versiyon karmaşıklığının olmaması sağlanıyordu.

Benzer şekilde bir de Microsoft.AspNetCore.All var. Bu da biraz daha kapsamlı olarak ek birkaç *.dll ile web uygulamalarında ihtiyacımız olabilecek referansları barındırıyordu. Bu sayede projemize ek bir referans eklemeden web projesinde olabilecek ihtiyaçları karşılayabiliyorduk. Microsoft.EntityFrameworkCore.Sqlite ya da Microsoft.Extensions.Configuration.AzureKeyVault gibi…

Devam…

Geleneksel(standart), iş hayatında olan herkesin bildiği yönetici(!!!) diye bir unvan var. Organizasyon ve kuruma göre içinin doluluk şekli doğal olarak çeşitlilik gösterir ama bir şekilde çoğunluğun ulaşmak istediği unvandır. Özellikle ülkemizde maddi bir karşılık olarak da konumlandırıldığı ya da algılandığı için, günümüz şartlarında iş hayatında yönetici(?) olmak bir hedef olarak düşünülebiliyor.

Uzun süredir yazılım sektörü insanıyım, daha çooook uzun sürelerde umarım böyle devam edecek. Diğer sektörleri profesyonel anlamda bilmiyorum ama yazılım hatta IT sektörünün birçok sektöre göre daha yeni ve çok hızlı değiştiğini, geliştiğini düşünüyorum. Diğer sektörlerdeki dijitalleşme ihtiyacı da bundan olsa gerek…

Yeni ve hızlı gelişen bir sektör olduğundan her iş hayatının temel parçası olan “insan” özelliklerinin, geleneksel iş hayatından biraz daha farklı olması gerekiyor. Yazılım sektöründe, iş hayatındaki temel yapıların; organizasyon kültürü, iletişim, yetkinlikler, unvan …vs. diğer iş sektörlerinden farklılaştığını görüyorum(z). Bunların her biri için ayrı ayrı, uzun uzun yazıp, konuşulabilir ama yazıya “yönetici” diye girdiğimden, unvanlar ile ilgili bir şeyler karalamak istiyorum. Hem profesyonel hayatımın bununla alakalı kısmı ile ilgili çok soru geliyor, hem de bulunduğum “geek” ortamlarda, bazen bu konular konuşulduğu için yazasım, düşüncelerimi paylaşım geldi.

Devam…

Çeviklik çağımızın gerektirdiği en önemli özelliklerden biri. Hızlı bir şekilde değişimlerin olduğu bir çağda, bu değişimlere aynı hızda uyum sağlayabilmek oldukça değerli. Ülkedeki IT sektöründe de son 6-7 senedir etkilerini ve çevikleşme ihtiyaçını yaşıyoruz. Bir çok küçük, orta, büyük ölçekli kurum “Agile” yaklaşımlar ile çeviklik kazanma içerisinde.

Ama açıkcası “Agile” yaklaşımları uygulama, çeviklik(Agility) kazanma son bir kaç yıldır düşündüğümden daha farklı bir yola giriyor. Kurumsal dünyanın da radarına daha sık girmesi bunun bir etkisi olabilir. Belli bir metodoloji ile sürdürebilirliği sağlayan kurumlar çevik metotlar ile tanışınca biraz bocalıyor gibi. Çevik metotlar birer kurallar kitabı olarak algılanıp, metotların uygulanma şekilleri de çok katı kurallar olarak yorumlanabiliyor. Bu kurallara uymak, uymaya çalışmak ihtiyaçlara çözüm sağlamaktan daha önemli bir hal alabiliyor. Bu kurallara(!) uyma derecesi ya da kural çıktıları başarı ölçümleri için birer kriter olabiliyor. Çözüm sağlanmıyor ama kuralların(!) çıktısı doğru(?) oluyorsa, çevik metot bir başarı olarak yorumlanabiliyor.

Bütün bunları çeviklik ve çevik metotlar ile ilgili düşündüğüm ve anladığım konular ile komple çelişen yanlışlar olarak görüyorum. Bunları, meslektaştalarım ile konuşmalarım, belli ortamlardaki gelen sorular ve tecrübelerim ile görüyorum, duyuyorum. Belki gerçekten de çeviklik böyle bir şeydir de, ben komple yanlış anlamışımdır. Ama gerçekten böyle yaklaşımlarsa sanırım bazı şeyleri yanlış yapıyoruz…

IT sektöründe çevik olmak, bir “spor yapmak” eylemi gibi. Düzenli bir şekilde spor yaptığımız zaman, kaslarımız daha esnek ve daha güçlü olur. Sadece kaslarımız değil, tüm vücut yapımız, hatta genel sağlımız belli gelişmeler içinde olur. Spor yapma alışkanlığımızı ne kadar sürdürürsek de kazandığımız bu özellikler o kadar gelişir, çevikliğimiz artar. Yaşam kalitemiz belli çerçevede artar. Ama spor yapmazsak da yaşarız, yine belli bir çerçevede yaşam kalitemiz olur. Sadece belli ihtiyaçlarımızda zaman zaman zorlanırız. Hayatın dinamikliğinde daha çok yorulabiliriz falan…

Bu durumun, IT dünyasında da, çevik metotlar için geçerli bir durum diye düşünüyorum. Eğer çevik metotları tercih edersek, sektörün bazı dinamikliklerine ve bu dinamikliklerin getirdiği değişimlere daha kaliteli çözümler sağlayabiliriz. Çevik metotları uygulamazsak da yine belli çerçevede çözümler sağlayabiliriz. Belki daha zor, belki daha kolay; bu iş modelinin dayandığı temel taşlara göre olan değişen bir durum. Bazı iş modelleri için çevik metotların katkısı daha çok olabilir, bazı iş modellerinde ise gerek olmayabilir, hatta yıkıcı etkisi olabilir.

Devam…

“Monolith” uygulamaların günümüzün hızlı değişim ihtiyaçlarına çok sağlıklı cevap verememesi ile “microservices” mimari stili, geliştirme yöntemi olarak hayatımıza girdi. Son 3-4 yıldır da “tüketim” ve “pazarlama” dünyası gerçekleri ile de reklamı yapılınca belli kalıplar içinde herkesin tercih etmeye çalıştığı bir stil oldu. Gerçekten ne kadar bu mimari yöntem ihtiyaç olarak tercih ediliyor ya da getirilerinden ne kadar değer üretiliyor bilemeyeceğim. Sonuçta “microservices” kusursuz bir çözüm yöntemi ya da ideal bir çözüm değil. Ayrıca tüm çözümler “microservices” tasarımı ile en doğru, en ideal olacak diye de bir şey yok.

Her fırsatta paylaşmaya çalışıyorum, konuya girmeden tekrar altınız çizmek isterim; “microservices”, servis odaklı mimarinin günümüz ihtiyaçlarına uygun bir şekilde evrilerek kullanılmasını sağlıklı hale getiren bir tasarım stili.

Bu kısa girişten sonra konumuza gelelim. “Microservices”(Mikroservis)’lerin bir birleri arasındaki veri ihtiyacı nasıl olmalı? Servisin bir fonksiyonunu başka bir servisten aldığımız verileri kullanarak nasıl sağlarız? Bu sorular karşıma çok çıkıyor, direkt mikroservis tasarımları ile geliştirmeye başlayan herkesin problem olarak da en çok takıldığı nokta olarak görüyorum, duyuyorum.

Açıkcası bu sorular karşınıza çıkıyor ya da kendi kendinize bunları soruyorsanız, mikroservis tasarımın stili kavram olarak tam netleşmemiştir. Öncelikle servislerin bir birleri arasındaki veri ihtiyaçları için bir birlerini çağırması, bir servisin belli işlemleri için başka servisten verileri alması falan normal ve zaten “Remote Procedure Call”(RPC) ile hayatımızda olan bir kavram. “Service Oriented Architecture(SOA)”‘nın ve dağıtık sistemlerdeki servis çağırımları yöntemleri ile servisler bir birlerinin her türlü verisini paylaşabilir. Ama bu yaklaşım günümüz ihtiyaçları ile bazen uyuşmadığı için, mikroservis tasarım stilinde de bu şekilde bir yol çok gösterilmiyor.

Mikroservislerin, en önemli karakteristik özelliği; servislerin kendi başlarına çalışan, tek bir sorumluluğu olan, bağımsız servis olmalarıdır. Dolayısıyla bir mikroservis bir veri için başka bir mikroservise ihtiyaç duymamalıdır. Aksi takdirde tek başına çalışan, bağımsız bir servis olma karakteristik özelliğini kaybedecektir.

Mikroservislerin ikinci önemli karakteristik özelliği de “business capability” yani iş alanlarının belli yetkinliklere göre sadece belli bir işi yapacak şekilde geliştirilen servisler olmaları. Yani eğer iş alanı bir veriye ihtiyaç duyuyorsa, o veri aslında o iş alanının(domain) bir parçasıdır. Eğer ihtiyaç duyduğu veriyi başka bir iş alanından alma durumu varsa yine bağımsız olma özelliği kaybolmuş oluyor. Mikroservisin çalışması için başka bir mikroservise bağımlı olması mikroservis mimari tasarım stiline ters bir durum.

Biraz gerçek hayattan bir örnek ile biraz daha anlaşılır hale getirmeye çalışacağım. Adres bilgimiz bankaların bizimle iletişim kurabilmesi için gerekli olan bir veri. Bu veri hesabımızın olduğu tüm bankalarda ayrı ayrı banka özelinde tutulmakta. Bankalar, bu adres verisi ile bizimle iletişim kurabilmekte ve fonksiyonel özelliğini gerçekleştirebilmekte. Bize her ekstre gönderecekleri zaman telefon edip, “Ekstre göndereceğiz, adresinizi söyler misiniz?” diye sormuyorlar. Böyle olsaydı eğer, telefon ettiklerinde ilgili veriyi alamadıkları zaman ekstre göndermeleri sıkıntılı olup, ekstre gönderme özelliği için istenmeyen bir bağımlılık olacaktı. Bunun yerine ilk hesap açılırken adres bilgimizi alıyorlar, kendi sistemlerine kaydediyorlar ve onu kullanıyorlar. Adresimiz değiştiği zaman bizim bilgilendirmemiz ile kendi sistemlerini güncelliyorlar.

Devam…

Yine çok hızlı bir yazı ile karşınızdayım. 🙂 Çok derinlere girmeden daha çok kod üzerinden örnekler ve bazı anahtar kelimeler ile JSON Web Token(JWT) konseptini ASP.NET Core projelerinde nasıl uygularız bundan bahsetmeye çalışacağım.

Açıkcası JWT oldukça derin bir konu. Şeması olsun, şeması ile ilişkili özellikler olsun bunların ayrıntılarına çok girmeyeceğim. Çok derinlere girmeden, JWT nedir bununla başlayalım. Client-Server iletişim mimarisinde, sunucu tarafından kimlik doğrulama, yetki tanımlama/doğrulama ve bilgi akışı güvenliği sağlamak için oluşturulmuş bir işaretleme standartı diye basitçe açıklayabilirim. İşaretleme diyerek, sunucu tarafından oluşturulan ve iletilen bir “token” ile işaretlenmiş client‘lar, bu işaret ile kendilerini sunucuya tanıtarak ve doğrulayarak, belli metotları çalıştırabiliyorlar demek istedim. Açıkcası bu şekilde bir ifade ile daha net anlaşılabileceğini düşünüyorum.

HTTP’nin “Stateless” bir protokol olması, “Session” yönetiminin transfer protokollerinde sağlıklı olmaması, dağıtık mimarilerde “Session” ve “State” yönetimin zor olması JWT’nin önünü açan bir durum. Bu bahsetmiş olduğum konular ile ilgili sorunlar ya da ihtiyaçlar ortaya çıkıyorsa JWT’ye göz atmanızda fayda var.

Neyse çok konuştuk… Daha çok kod üzerinden gidecektik, hani nerde? Öncelikle burada bahsedeceğim tüm kodlar, projeler GitHub profilimde mevcut. Direkt oradan da devam edebilirsiniz.

Şimdi gelelim senaryomuza… Bir tane WebAPI uygulamamız olsun. Bu uygulama üzerinden kullanıcı kimliği doğrulaması yapıp, web api uygulamasındaki başka kaynakları çalıştırabilelim. Eğer kimlik doğrulaması yapamıyorsak tabi ki çalıştıramayalım. Bu Web API uygulamasına kimlik doğrulaması için istersek mobilden, istersek de başka bir Web uygulamasından bağlanabileceğimizi de düşünün.

ASP.NET Core ile bu bahsetmiş olduğum senaryoyu nasıl yapacağız buna bakalım bizde. Açıkcası ASP.NET Core’da, kendi içerisindeki API’lar ve middleware yaklaşımı sayesinde JWT oluşturmasını ve doğrulamasını yapmak oldukça kolay.

Bunun için “JSON Web Token” yaratmak ve doğrulamak istediğimiz ASP.NET projemizde ConfigureServices() metoduna öncelikle JWT yapısını kullanacağımızı belirtiyoruz.

Burada önemli olan yerlere kısaca bakalım. AddAuthentication() içinde şema formatının nasıl olacağını söylüyoruz. Burada aslında çok fazla alternatifimiz yok, ama JWT şemasını kullanacığımızı tanımlıyoruz. Bu metottan hemen sonra çağırdığımız AddJWTBearer() metotu asıl önemli olan kısım. Burada artık uygulamamızda Authentication için JWT şemasının taşınacağını ve bununla ilgili çeşitli ayarların olacağını belirtiyoruz.

Devam…