Backend geliştiricisi olarak NAC mimarisine ilk baktığımda aklımdaki soru şuydu:
"FastAPI burada neden var?"
Sonuçta elimizde zaten Switch, FreeRADIUS ve Policy Engine vardı.
Peki backend neden gerekliydi?
FastAPI Sistemin Beyni Değildir
İlk bakışta öyle görünse de FastAPI tek başına karar veren yapı değildir.
Daha doğru bir ifadeyle FastAPI sistemin orkestra şefidir.
İstekleri alır.
Gerekli servislerle iletişim kurar.
Sonucu ilgili bileşene iletir.
Bir İstek Geldiğinde Ne Yapar?
Örneğin bir kullanıcı şirkete bağlanmak istedi.
FastAPI şu adımları yönetebilir:
- Kullanıcı bilgilerini alır.
- Redis'te kayıt var mı kontrol eder.
- Gerekirse PostgreSQL'den veriyi çeker.
- Policy Engine'e gerekli bilgileri gönderir.
- Gelen sonucu FreeRADIUS'a iletir.
Yani tüm servisleri birbirine bağlayan merkez noktadır.
Neden Tüm Kurallar FastAPI İçinde Yazılmaz?
Bu oldukça önemli bir tasarım kararıdır.
Diyelim ki bütün kuralları FastAPI içine yazdık.
Bir süre sonra kod şöyle görünmeye başlayacaktır:
if department == "IT":
...
if department == "HR":
...
if device == "Printer":
...
if location == "HQ":
...
Kod büyüdükçe yönetmek zorlaşacaktır.
Bu nedenle karar mekanizması çoğu zaman ayrı bir Policy Engine'e bırakılır.
FastAPI ise sadece koordinasyonu sağlar.
Mikroservis Yaklaşımı
Modern sistemlerde FastAPI genellikle;
- Authentication
- Authorization
- Policy Engine
- Audit
- Notification
- Device Management
gibi farklı servislerle haberleşir.
Bu yaklaşım sayesinde sistem daha kolay geliştirilebilir ve ölçeklenebilir hale gelir.
Sonuç
FastAPI yalnızca API yazmak için kullanılan bir framework değildir.
Doğru tasarlandığında tüm servislerin koordinasyonunu sağlayan merkez bileşenlerden biri haline gelir.
Bu nedenle NAC ürünlerinde backend yalnızca veri döndürmez, aynı zamanda tüm iş akışını yönetir.
Top comments (0)