Rate limiting is an approach to limit resources that can be accessed over a time. Limiting might not sound a good word in the beginning, but we are living in a world with huge consumption rates within limited resources. And this is not so different for software solutions. So, limiting some resources may be required for reliable and secure software solutions in this era.
And also, within some business requirements, limiting resources may help organizations to get some revenue for their owned resources.
In either way, limiting resources provides some benefits. In fact, this concept is not a new thing in software solutions and Microsoft’s development stack. It could be already done with some libraries or custom implementations. But within new version of .NET 7, “RateLimiting” has been introduced as built-in for .NET developers to have easier development to protect owned resources.
Within this post; because of, we live in a big world-wide connected web, I will try to give a brief introduction for “RateLimiting”middleware in ASP.NET Core. But to make a deep dive into RateLimiting concept in .NET 7, I suggest you to check also new APIs in System.Threading.RateLimiting package. This is also the core component of RateLimiting middleware for ASP.NET Core.
We can add this package to our web application to have some rate limiting approaches in our applications. After then to add RateLimiting middleware, we use UseRateLimiter() extension method for IApplicationBuilder (WebApplication)
Within this method it is possible to have some option to have control over RateLimiting, such as; setting HTTP status code and implementing some custom actions when rate limit is occurred and also some other limiters(a.k.a Rate limiting algorithms)
For example, the above example demonstrates setting HTTP429 as response code and a delegate to do some logging with some metadata when rate limiting is occurred.
HTTP 429 is default status code for too many requests. So, it is crucial to use this status code for the sake of pandas’ health and planet. Let’s expand our awareness within HTTP codes.🐼
And then we need to add some limiters to our rate limiting option so that we can define rate limiting algorithms. There are some built-in rate limiting algorithms provided by .NET 7. And these are provided as extension methods for RateLimiterOptions.
Öncelikle “telemetry” ne demek bununla başlayalım. Genel kullanım olarak telemetre şeklinde dilimizde yer edinen bu kavram, dilimizde de aslında “uzaktan ölçüm” anlamı ile tanımlanmakta. Sürdürülebilir yazılım çözümleri için önemli olan “ölçüm” ya da “ölçmek” konuları; günümüzün hızla “değişen” ve “büyüyen” ihtiyaçlarına sağlanan çözümler için daha da farkında olunması gereken ve önemi artan konuları oldu. Sunulan çözümlerin ölçülebilir olması ve bu ölçüm değerlerinin monitör edilebilir olması çözümlerin kalite gereksinimlerini karşılamak ve çözümlere değer katabilmek için oldukça kritik bir nokta oynuyor. Malum ölçemediğimiz bir çözümü geliştirmek ve ileri götürmek biraz zor.
Bir yazılım çözümünün gereksinim duyduğu hafıza, işlem gücü, çalışma süreleri, çalışma anındaki kayıtlar(log’lar) ya da iletişim süreleri gibi gibi başlıklar, çözümlerin davranışlarına ve gelişmelerine büyük katkı sağlıyor.
Özellikle artık dağıtık mimarilerin bir norm olduğu zamanda yaşıyoruz ve bu dağıttığımız bileşenlerin hayat döngülerini monitör edebilmemiz oldukça önemli. Yazılım teknolojileri için bu alanda da tahmin edebileceğimiz gibi birçok araç var. Sürekli gelişen ve büyüyen yazılım dünyası için yine tahmin edebileceğiniz gibi bu araçların sayısı ve olgunlukları her geçen gün değişiyor. Bu araçların uygulama yöntemleri de değişiklik gösterdiği için yazılım çözümleri içerisinde genel bir yaklaşım ile kullanmak biraz zor, -ki zaten standart yaklaşımların yazılım dünyasında oluşması(?) biraz zor.
OpenTelemetry nedir?
İşte bu noktada OpenTelemetry projesi hayatımıza giriyor. Farklı firmaların ya da organizasyonların, farklı yöntemler ile geliştirdiği ve sunduğu araçlara direkt bağlı kalmadan, firma/organizasyon bağımsız API’ların, araçların, SDK’ların sunulduğu, kısmen yeni bir proje, OpenTelemetry. Açık kaynak olarak geliştirilen ve birçok popüler benzer araçlar tarafından da desteklenen bir proje olması ile de bir noktada hepimizin karşılaşacağı bir proje olacak.
Bulut platformlarındaki teknolojilerin olgunluk ve tercih edilme kriterleri için kılavuz olabilecek “Cloud Native Computing Foundation” içerisinde şu an kuluçka döneminde gelişimini sürdüren bir proje statüsünde. 1-2 yıl içinde de mezuniyeti bekliyorum şahsen.🎓 😀
Başlıktan direkt sadece .NET platformu ile ilgili bir proje olduğu algısı oluşmuş olabilir. Ama şimdiden onu da belirtim ki, direkt bir alakası yok. Python, Go, Java, JavaScript gibi gibi birçok yazılım dili teknolojileri için de geçerli bir proje ama tabi ki olgunlukları ne yazık ki aynı değil. Açık kaynak geliştirme dünyasının bir ürünü olduğu için gelişme ve olgunlaşma durumları aynı değil. Bu yüzden dikkatli olmak ve “neden-sonuç” ilişkisini iyi tartarak bu projeye yaklaşmak önemli.
“Madem direkt alakalı değil, niye .NET de yazdın?” diyecek olanlar için biraz daha sabırlı olmalarını isteyeceğim. OpenTelemetry‘nin yazılım çözümlerini ölçerken baz aldığı kavramlar ve bu kavramların.NET platformundaki karşılıklarından bahsederek yazının başlığındaki .NET kısmına geleceğim.
OpenTelemetry, yazılım çözümlerinin ölçümünü için 3 ana başlık altında topluyor. Bu arada OpenTelemetry‘nin bu başlıkların hepsi için de ayrı ayrı spesifikasyon da sunuyor ki, bu şartlara göre bu ölçüm değerlerinin ve ölçüm işlerinin yapılmasını hedefliyor.
En basit anlatım olarak, OpenTelemetry‘nin sağladığı API’lar ve SDK’ler ile bu başlıklar altındaki verileri toplayıp gereken araçlara aktarmak mümkün, -ki birazdan bunlarla ilgili bir örnek ile daha iyi anlayacağız. Ama bir başlıktan daha bahsetmek istiyorum;
OpenTelemetry Collector
OpenTelemetry projesinden ilk bahsederken, “…API’ların, araçların, SDK’ların sunulduğu…” demiştim hatırlarsınız. OpenTelemetry Collector, buradaki “araçlar” kısmı. OpenTelemetry Collector, yukarıdaki başlıklar altındaki ölçüm verileri toplayıp, konfigürasyonla başka istenen araçlara aktarabiliyor. Mesela Trace verilerini ya ister Jaeger‘e ya da ister Zipkin‘e uygulama tarafında bir değişiklik yapmadan görüntülemek mümkün.
OpenTelemetry Collector‘ın önemli olduğu ve fayda sağladığı nokta bu uçtan uca akışı sadece konfigürasyon yönetimi ile sağlıyor olması. Aşağıdaki görsel üzerinden yapıyı biraz daha anlamaya çalışalım. Görsel OpenTelemetry‘nin ölçüm değerlerini nasıl toplandığı biraz olsun anlamak için oldukça iyi.
OpenTelemetry Collector
Sol tarafta dikkat edersiniz ki; receiver(alıcı) bileşenleri var. Bu Kafka, PostgreSql, OTLP, RabbitMQ, Redis, MySql… gibi gibi birçok aracı destekleyen OpenTelemetry bileşenleri olabilir. Hepsi açık kaynak bir şekilde geliştirilmekte. Buradan ulaşabilirsiniz ve hatta isterseniz daha derinlere dalıp kendi alıcınızı da yazabilirsiniz. Bu alıcılar ilgili araçların çeşitli API’larını ya da parçalarını dinleyip ya da sorgulayıp ilgili verileri alıyorlar. Mesela, RabbitMQ alıcısı; RabbitMQ’nun Management API’larını dinleyip ondan gelen verileri iletiyor.
Görselde dikkatinizi OTLP diye bir kutucuk dikkatinizi çekecektir. Bu OpenTelemetry Protocol (OTLP)’üne denk gelen bir gösterim. Yani; ölçüm verilerinin kaynak ve alıcılar arasında standart bir şekilde olmasını sağlayacak bir protokol. Bu protokol ile verilerin sıkıştırılması, iletişimdeki re-try mekanizmaları, şifreleme gibi aktarım yöntemleri sağlanmakta. Log, Metric ve Trace kavramları için aynı olgunlukta değil ama standartlaşma(?) açısından ışık veren bir protokol.
OpenTelemetry ne değildir?
Açıkcası burada OpenTelemetry’nin uygulamalardaki ölçüm verilerinin oluşturulması ve dağıtılması ile ilgili ara bir bileşen olduğunun altınızı çizmek isterim. Bu verilerin saklanması, sorgulanması ya da gösterilmesi gibi görevleri yok. Çok fazla veri üretilmesine yol gösteren bir proje olduğundan ister istemez böyle bir beklenti içinde de olabiliyor insan. Özellikle belirtmek istedim…
Çok konuştun biraz da kod göster…
Daha değil ama az kaldı. Önce hızlıca yazının başlığında .NET tarafına yaklaşalım. OpenTelemetry’nin yukarda bahsettiğim 3 ana başlığı, .NET platformundaki OpenTelemetry API’ları için nasıl işletiliyor önce bunu anlamaya çalışalım.
Takip etme (a.k.a Tracing)
OpenTelemetry, Tracing verileri için .NET platformunda System.Diagnostics.* namespace’ine bel bağlamış durumda, -ki aslında zaten System.Diagnostics.* .NET Framework zamanından beri belli “trace” verilerinin oluşmasını zaten built-in olarak sağlıyordu. Yeni .NET platformu ile de biraz daha güncel ihtiyaçlara uygun hale geldiğini söyleyebilirim
Uygulama kayıtları(a.k.a Logging)
OpenTelemetry, loglama ölçüm verileri için de .NET’in Microsoft.Extensions.Logging.Abstractionsnamespace‘ine bel bağlamış durumda. Yani standart olarak .NET platformunun sağladığı Logging ara yüzleri ve metotları ile geliştirdiğimiz uygulama loglama alt yapılarında üretilen veriler OpenTelemetry ile diğer ölçüm değerleri ile ilişkilendirilebilmekte. Ama eğer uygulama loglama alt yapımızı .NET’in standart sağladığı yapıların üzerine kurmadıysak uygulama logları ile ölçüm değerleri ilişkilendirmek pek mümkün değil. Bu arada ne demek istiyorum biraz daha açsam iyi olacak sanırım; uygulama içinde yazdığımız log’ların hangi talep ile ilişkili olduğunun tutulması gibi diyebilirim. Sorguların CorelationID ya da TraceID‘leri ile o sorgu sırasında yazılan uygulama loglarının ilişkilendirilmesi gibi.
Ölçü sistemi (a.k.a Metrics)
Metric ölçüm verileri için yine System.Diagnostics.*namespace‘i kullanılmakta. Meter, Counter gibi sınıflar ile uygulamamızda ölçmek isteğimiz metrik değerlerini oluşturabiliyor ve ölçebiliyoruz. Mesela bir metotun, hangi parametre ile kaç kere çağrıldığı ya da bir metot kaç kere hata fırlatmış bunları ölçmek için metrikleri yine System.Diagnostics.* ile yapabiliyoruz. OpenTelemetry‘nin bileşenleri de bunlar üstünden bu metrik verilerini dışa aktarabiliyor. Bu arada eğer zaten dotnet counters aracına aşinaysanız ne demek istediğimi anlamışınızdır.
Birazdan göstermeye çalışacağım örnekte uygulama metrikleri ile ilgili bir gösterim olmayacak. Yazı fazla uzadığından onunla alakalı ayrı bir yazı yakında paylaşacağım.
Dikkat edersiniz ki, herhangi bir OpenTelemetry ya da başka bir bileşene sahip olmadan zaten var olan .NET platform bileşenleri ile ölçüm değerleri oluşturulabiliyor. Bu noktada OpenTelemetry bunları bir araya getirip anlamlı bir hale sokuyor diyebiliriz.
Günümüz çözümlerinin çoğunlukla servis odaklı çözümler olması, bu çözümlerin barındığı ağ(network) alt yapılarının da özenle tasarlanması ve belli sınırlarının çizilmesi konularını gündeme getiriyor. Özellikle güvenlik öncelikli olarak beklenen bir kalite ölçütüyse… “Cloud” platformlar üzerinde çözümler geliştiriyorsak, platformun bu konular için sunduğu hizmetleri de kullanmak tahmin edersiniz ki oldukça önemli ve gerekli. Daha çok Azure platformunda çözümler geliştiren/sunan biri olarak bu açıdan iki hizmetten bahsetmeye çalışacağım bu yazıda; Azure’daki Private Endpoint ve Service Endpoint…
Azure üzerinde Paas(Platform as a service) şeklinde sunulan hizmetleri kullanan çözümler geliştirdiğimizde, bu servisler ile olan iletişimin belli kısıtlamalar ve sınırlar içinde olması çözümün güvenilirliği adına önemli. Belli servis erişimleri için kullanılan anahtarlar ya da kimlik bilgilerinin sızması durumunda ağ alt yapılarındaki tasarımlar ve kısıtlamalar oluşabilecek riskleri de minimuma indirgemek için oldukça değerli.
Service Endpoint
Bir Azure Virtual Network yarattığımız zaman, bu sanal ağ içerisinde olan kaynaklar; mesela bir tane sanal makine(VM) diğer Azure servisleri ile bir “Public IP” üzerinden, internete çıkarak iletişim kurar. Ama peki bunu istemezsek?
Oluşturulan sanal ağlarda(virtual network) tanımlanabilen “Service Endpoint”ler ile sanal ağ içerisinde oluşturulan kaynakların servislere erişiminin, sanal ağ tanımına göre sahip olduğu “Private Ip” ile olması mümkün olabiliyor. Bu sayede internete çıkmadan diğer Azure hizmetine erişimi sağlanabilmekte. İnternete çıkmadan Azure içindeki temel sanal ağ içinde kalarak erişimin sağlanması hem güvenlik hem de performans açısından önemli bir getiri.
“Service Endpoint”leri, ağdaki gizli kaynakların bir Azure hizmetine tanıtılması gibi düşünebiliriz. “Service Endpoint”ler sayesinde, Azure hizmeti bir ağdaki bileşeni tanımış ve ona özel bir kapı açmış gibi canlandırmak belki daha basit olacak. Azure portal üzerinden bu tanımlamaları oldukça kolay bir şekilde yapabiliyoruz.
Aşağıdaki Azure hizmetlerini bir “Service Endpoint” olarak eklemek mümkün.
Microsoft.AzureActiveDirectory
Microsoft.AzureCosmosDB
Microsoft.CognitiveServices
Microsoft.ContainerRegistry
Microsoft.EventHub
Microsoft.KeyVault
Microsoft.ServiceBus
Microsoft.Sql
SQL Database
MySQL
PostgreSQL
Synapse Analytics
Microsoft.Storage
Microsoft.Web (App Services)
Hem küçük bir ek olması, hem de daha iyi anlaşılması için; sanal ağa “Service Endpoint” tanımı yapmadan, direkt erişeceğimiz Azure hizmeti üzerinden de “Service Endpoint” aktifleştirmesini yapabiliyoruz. Zaten direkt bir hizmeti sanal ağımıza eklemek istediğimizde portal üzerinden önce sanal ağda “Service Endpoint”in aktifleştirilmesinin yapılması gerekliliğini görüyoruz.
Dan diye birden SQL Server’dan da örnek verdim ama biraz daha canlandırabilmek için örneği daha net ele alalım; bir sanal ağ içinde bir “subnet”e bağlı da bir VM olduğunu düşünelim. Bu VM’i internete açmadığımızı yani “Public IP”sinin de olmadığını düşünelim. VM içindeki uygulamamız Azure SQL veri tabanına erişmek durumunda olsun. Eğer sanal ağdaki bu ilgili “subnet”‘de Microsoft.Sql için bir “Service Endpoint” tanımı yoksa, VM içindeki uygulamamız SQL veri tabanına erişemeyecektir. Ancak “Service Endpoint” tanımladığımız zaman VM, iletişimi tamamen Azure ağ alt yapısı içinde kalacak şekilde SQL veri tabanına erişebilecektir. İnternette dolaşmadan da erişimin sağlanıyor olması veri güvenliği açısından da oldukça önemli.
Ancak burada önemli bir nokta var ki; o da Azure SQL veri tabanı hizmetine erişirken, Azure “Public DNS”si üzerinden erişim sağlanıyor. Yani küresel anlamda Azure tarafında bir DNS sorunu olursa uygulamamız veri tabanına erişemeyecektir.
Peki, Private Endpoint ne?
“Private Endpoint”, “Service Endpoint”e benzeyen bir kavram; onun bir üst versiyonu gibi ele alabiliriz. “Private Endpoint”ler Azure Private Link hizmetninin temel bir parçası. Azure Private Link‘de, sanal ağ kaynaklarının diğer servislere erişiminin yine aynı sanal ağ içinde olması sağlanıyor ama ek olarak diğer servislerin de sanal ağ içinden verilen özel bir IP ile erişilmesi sağlanıyor. Bu özel IP alabilmesi hizmeti de “Private Endpoint” olarak adlandırılıyor.
C#’daki “[Attribute]” yani nitelik yaklaşımı dilin yorumlanması açısından güzel getirilere sahip bir özellik. Geliştiricinin, derleyiciye belli üst bilgileri(a.k.a metadata) aktararak, kodun derlenme ya da çalışma şeklini değiştirebiliyor olması yazılım çözümlerine ve yazılım geliştirme yöntemlerine çok büyük artılar sağlayabiliyor.
Genellikle .NET platformunun sunduğu hazır “[Attribute]”’ları kullanarak çözümlerimizi geliştiriyoruz; gerektiği yerlerde kendi özel [Attribute]’larımız ile de çözümlerimizi genişletebiliyoruz. Açıkçası çok derinlere girmeyeceğim, -ki zaten ihtiyaçlara göre sık sık tercih edebiliyoruz. Ama [Attribute]’ların öneminin ve değerli bir özellik olduğunun altını koyu bir kalemle altını çizmek isterim. Bu önemi ve farkındalığı biraz daha arttırabilmek için, faydalığı olduğunu düşündüğüm birkaç [Attribute]’dan hızlıca bahsetmeye çalışacağım. Hem [Attribute]’lar ile neler yapılabilir yeni fikirlerler vermesi, hem de farkında olunmayan birkaç niteliğin farkındalığı ile yazılım çözümleri için faydalı olur umarım bu yazı. Tabi ki bilenler, kodunda kullananlar illa ki vardır; onlar için biraz tekrar olacak belki ama en azından yorumlarını paylaşabilirlerse ekstra sevinirim, seviniriz. Değil mi?
Nitelikler(a.k.a [Attribute]), .NET ve Rosyln‘nın da gelişmesi ile statik kod analizi açısından da önemli bir yere geldi. Bahsetmeye çalışacağım bir tanesine bu açıdan da bakmakta fayda var.
[CallMemberName]
Bir metodu hangi metot çağırmış bunu bilebilmek kod içerisinde bazen ihtiyaç olabiliyor. En basitinden Log ve Trace ihtiyaçları için önemli. Kodun içerisine statik olarak belirtmek yerine(-ki hepimizin yapmışlığı vardır) [CallMemberName] niteliğiyle bir parametre ekleyerek bunu yapmak mümkün.
public class SomeGreatAPI
{
public void Foo()
{
this.Log("Invoked in some method,which one?");
}
private void Log(string message, [CallerMemberName] string memberName="")
{
Console.WriteLine($"{message}");
Console.WriteLine($"This message is from {memberName}");
}
}
[ModuleInitializer]
Belki de çok gerekli gelmeyecek ama belli senaryolar için önemli olabilecek [ModuleInitializer] niteliğinden de bahsetmek isterim. Bu nitelikle işaretlediğimiz bir metot, ilgili olan “assembly” ilk yüklenirken çalışacak metot oluyor. Belli iş kurallarının kontrol edilmesi ya da ilk önce bazı değerlerin oluşturulup ayarlanması gibi senaryolar için güzel bir özellik. Tabi ki başka yaklaşımlarla da bu tarz bir ihtiyacı kısmen de olsa gerçekleştirebiliriz ama hem kodun derli toplu olması için hem de framework’ün kendi içindeki ideal bir yapı olduğu için tercih edilebilecek güzel bir ifade şekli diye düşünüyorum.
namespace Csharp10.Features
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello, World!");
}
}
}
public class SomeGreatAPI
{
[ModuleInitializer]
public static void Init()
{
Console.WriteLine("Initialize...");
}
}
Yukarıdaki basit örneği çalıştırdığımız zaman aşağıdaki gibi bir çıktı kodun daha iyi anlaşılmasını sağlayacaktır.
Initialize...
Hello, World!
Kod içerisinde [ModuleInitializer] ile belirttiğimiz metot ilk çalışacak metot. Dolayısıyla uygulama ilk çalıştığında belli kontroller ya da doğrulamalar yapmak için güzel bir fırsat. [ModuleInitializer] niteliği ile işaretleyebilmemiz için metodun birkaç gereksinimi var; parametre almayan, dönüş değeri olmayan “static” bir metot olması gibi…
[return:NotNullWhen(bool returnValue)]
Bu nitelik biraz değişik; API/SDK tarzı bir çözüm sunuyorsanız ya da bir Framework geliştiriyor ve bunu yazılımcılara sunuyorsanız, kullanan kişilere yol göstermesi için güzel bir nitelik diye düşünüyorum.
public class SomeGreatAPI
{
[return: NotNullIfNotNull("email")]
public static string? GetEMailProvider(string? email)
{
//return SomeOperationResult
}
}
Yukarıdakine benzer bir metodu sunduğumuzu düşünelim. “Nullable” bir metot olup, aldığı parametre değerlerine göre null dönmesi gereken bir ihtiyaç olduğunu hayal edelim. E-Posta adresinin hangi servis sağlayıcıdan olduğunu bulmamız gereksin mesela… @gmail.com, @live.com gibi. Eğer e-posta parametresi verildiyse mutlaka bir değer dönsün, eğer parametre verilmediyse null dönsün. Bu metodu kullanacak geliştiriciler için bu mantığı [return:NotNullIfNotNull(parameterName)] niteliği ile anlatmak mümkün. Metodu aşağıdaki gibi normal bir şekilde çağırdığımızı düşünelim.
Her şey normal gözükecektir. Derleme adımında her hangi bir uyarı bile gözükmeyecektir. “nullable” olan email parametresini metodu çağırdığımız yerdeki iş kuralından dolayı doldurmadığımızı düşünelim.
Visual Studio direkt olarak “provider” değişkeninin altını çizecektir ve uyarı gösterecektir. Ya da zaten derlendiğimizde de kodu uyarı olarak bunu göreceğiz.
“Eeeee şimdi zaten null kontrolü yapılmalı” diye düşünebilirsiniz; -ki evet, belli kontrollerin daha güvenli kod yazmak için yapılıyor olması gerekli. Tecrübenin yanında, bu tarz bilgilendirmeler ile API’yı kullanmaya başlayan kişileri doğru bir şekilde bilgilendirmek mümkün. Ayrıca daha düzenli kod yazmak için de tercih edilebilecek bir özellik.
.NET Framework ile uzun süre çalışmış kişiler için bu yaklaşım biraz tanıdık gelecektir belki ve “Code Contracts”‘ı anımsatacaktır. .NET Framework’de kodların çalışma mekanizması içinde ön koşul ya da son çalışma adımı gibi ara tanımlar koyabiliyorduk. Ne yazık ki yeni .NET platformunda(>=5.0) şu an için pek mümkün değil. Ama az önce bahsettiğim nitelik(ler) ile benzer koşulları oluşturmak mümkün. Bu arada bu niteliğin sağlıklı çalışabilmesi için projede nullable özelliğinin aktif olması gerekmekte. Benzer başka nitelikler de .NET’in içinde mevcut. Merak uyandırdıysa eğer, onlara da göz atmanızı tavsiye ederim.
Bu yazı biraz kısa ve hızlı oldu ama “[Attribute]”ler konusunda farklı yaklaşımlar geliştirmek için biraz olsun motivasyon sağlar. Yakın zamanda bazılarının faydalarını gördüğüm için kendi adıma daha kalıcı olması için hızlıca paylaşmak istedim. Bir sonraki yazıda görüşmek üzere, mutlu kodlamalar… 😀😀
ASP.NET Core tarafında farkında olunduğu zaman değişik ihtiyaçlar için çözüm olabilecek ama çok fazla gündeme gelmeyen çeşitli API’lar mevcut. Bunlardan biri de IHostingStartup ara yüzü. Geliştiriciler için SDK/Framework/eklenti tarzı araçlar geliştiriyorsanız ya da uygulama başlarken bazı kontroller yapmanız gerekiyorsa faydalanabileceğiniz bir ara yüz. Hızlıca ve kısaca ne olduğunu, neden tercih edilebilir bahsetmeye çalışacağım.
Ama önce bir hatırlatma…
Bildiğiniz gibi ASP.NET Core uygulamaları “host” kavramı ile çalışır. Bu “host” yaklaşımı uygulamanın başlamasını ve yaşam döngüsünün yönetilebilmesini sağlar. ASP.NET Core uygulamalarındaki standart proje şablonlarındaki Program.cs içeriğinden hatırlayabiliriz. Bir host(IWebHostBuilder) yaratıyoruz, bunu konfigürasyon ile ayarlıyor, gerekli servisleri ekliyor ve uygulamanın yaşam döngüsünü oluşturuyoruz.
public class Program
{
public static void Main(string[] args)
{
CreateHostBuilder(args).Build().Run();
}
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((hostingContext, config) =>
{
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.ConfigureServices(services =>
{
services.AddRazorPages();
})
.Configure(app=>
{
var env = app.ApplicationServices.GetRequiredService<IWebHostEnvironment>();
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapRazorPages();
});
});
});
}
Ama tabi biraz da düzenli olması adına, ek bir Startup.cs içeriği ile bu yapıyı farklı bir sınıf içerisinde, UseStartup() metodu ile kullanabiliyoruz, -ki zaten standart proje şablonlarından hep bu şekilde geldiği için bu yönteme daha aşinayız. Ama genel ASP.NET Core’daki yapıyı bilmek önemli diye düşünüyorum.
public class Program
{
public static void Main(string[] args)
{
CreateHostBuilder(args).Build().Run();
}
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
}
Bu küçük hatırlatma ile aslında paylaşmak istediğim konuya giriş için kapıyı açmış oldum. Bütün bu işlemlerden önce uygulamadan ayrı bir şekilde bazı işlemleri ASP.NET Core’da nasıl yapabiliyoruz bir bakalım.
IHostingStartup
IHostingStartup arayüzü, ASP.NET Core’da IWebHostBuilder ile “host” oluşturulurken, öncesinde bazı işlemleri yapabilmek için tercih edebileceğimiz bir yöntem. Bu özelliğin bir güzel yanı, mevcut bir ASP.NET Core uygulamasından bağımsız ayrı bir *.dll üzerinden bazı işlemleri yapabilmek; belli konfigürasyonları uygulamaya eklemek ya da belli işlemleri gerçekleştirmek gibi.
Biraz daha net anlaşılması için şöyle örnekler verebilirim; lisans kontrolü, uygulamanın aktivasyonu, uygulama çalışmadan önce bazı ayarların sistem seviyesinde yapılması ve kontrolü(belli dizinlerin yaratılması, belli dosyaların yedeklenmesi…gibi) ya da uygulamanın sağlıklı çalışması için bazı taşıma-dönüşüm işlemlerinin önceden yapılması… “Eee zaten yapabiliriz, yapılabilir böyle şeyler” diyenler olacaktır. Tabi ki bir şekilde bu tarz gereksinimleri gerçekleştirebiliriz ama neden bunları SDK’nın sağladığı yaklaşımlar ile daha kolay ve .NET için en uygun şekilde yapmayalım.
Yavaştan kod tarafına geçelim ki biraz daha netleşmeye başlasın. Visual Studio’nun standart proje şablonlarından ASP.NET Core Web App(StartupDemos) ve bir tane de Class Library(HostingStartupExternalLibrary) kullanacağım. Class Library, bizim dışardan uygulamaya dahil edeceğimiz, IHostingStartup ara yüzünden türeteceğimiz yapıyı barındıracak; yazının asıl olay yani. ASP.NET Core Web App ise, sadece örnek amaçlı, dışardan ekleyeceğimiz IHostingStartup‘ı kullanacak uygulama.
HostingStartupExternalLibrary projesine bakalım önce. IHostingStartUp arayüzünden yarattığımız tek bir sınıfımız var. Bu arayüzün sağlamış olduğu Configure(IWebHostBuilder) metodu ile WebHost’umuzu ayarlayabiliyoruz. Ben burada örnek olsun diye; bir Web API*‘sine çağrı yapıp dönen değerleri WebHost’un konfigürasyonunda kullanılması için ayarlıyorum. Çok saçma biliyorum ama başka bileşenler/sistemler ile iletişim de kurup, farklı iş ihtiyaçlarını gerçekleştirebilmek adına örnek olabilir. Mesela yazının başında bahsetmiş olduğum senaryolardan; uygulama çalıştığında bir aktivasyon, bu tarz bir Web API çağrımı ile gerçekleşebilir.
*Burada örnek olması adına bu tarz örnekler ve denemeler için kullanılabilecek ücretsiz basit bir Web API kullandım.
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using System.Collections.Generic;
using System.Net.Http;
[assembly: HostingStartup(typeof(HostingStartupExternalLibrary.SomeExternalHostingStartup))]
namespace HostingStartupExternalLibrary
{
public class SomeExternalHostingStartup : IHostingStartup
{
public void Configure(IWebHostBuilder builder)
{
HttpClient client = new();
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Add("User-Agent", "SomeSpecificCustomer");
string boredAPIResult = client.GetStringAsync("https://www.boredapi.com/api/activity").Result;
var activity = System.Text.Json.JsonDocument.Parse(boredAPIResult);
builder.ConfigureAppConfiguration((host, config) =>
{
var externalSettings = new Dictionary<string, string>
{
{"EXTERNAL_STARTUP_ACTIVITY", activity.RootElement.GetProperty("activity").GetString()},
{"EXTERNAL_STARTUP_TYPE", activity.RootElement.GetProperty("type").GetString()},
{"EXTERNAL_STARTUP_KEY", activity.RootElement.GetProperty("key").GetString()}
};
config.AddInMemoryCollection(externalSettings);
});
}
}
}
Burada dikkat ederseniz, IWebHostBuilder üzerinden konfigürasyonlara belli değerleri ekliyoruz. Bu IHostingStartup arayüzünü uygulamadığımız Web uygulamasında, uygulamadan bağımsız olarak bu konfigürasyon değerlerine ulaşabileceğiz. Birazdan oraya da geleceğiz.
