EuroTech Portal

Eğitim operasyonu, birbirine bağlı ama ayrı araçlarda yürüyen işlerden oluşuyordu: ders programı bir yerde, ödev başka yerde, video kaydı üçüncü bir serviste, faturalama dördüncüde. Her araç kendi başına çalışıyordu; kopan şey aralarındaki bağdı. Bir öğrencinin hangi derse kayıtlı olduğu, o dersin kaydına erişip erişemeyeceği ve ödemesinin durumu üç ayrı yerde tutulduğunda, üçünü birleştiren tek şey insan hafızası oluyor. Portalın işi yeni bir özellik eklemek değil, bu bağları tek yerde kurmaktı.

Dört rol, dört farklı görünürlük. Öğrenci: kendi programını, ödevini ve ders kaydını görüyor; başkasının verisine erişemiyor. Eğitmen: kendi derslerini, sınavlarını ve öğrenci listesini yönetiyor. Yönetici: kayıt, program, duyuru ve destek taleplerini yürütüyor. Süper yönetici: yapılandırma ve kullanıcı yönetimi dahil her şeye erişiyor. Rol farkı yalnız menüde değil, veri erişiminde.

Geliştirici olarak portalın büyük bölümü: veri modeli, rol ve yetki yapısı, modüllerin çoğu, dış servis entegrasyonları ve zamanlanmış işler.

Laravel 10 üzerinde sunucu tarafında şablon üreten bir monolit. İstek rota → controller → Blade görünümü hattından geçiyor; veri erişimi Eloquent üzerinden. Yapı modül bazlı controller'lara bölünmüş: kurs ve ders, öğrenci ve eğitmen, sınav, duyuru, yardım masası, dosya yönetimi, kariyer, finans ve yapılandırma. Dış servisler kendi controller'larında toplanmış — video konferans, video barındırma, dosya depolama, görev takibi, ön muhasebe, ölçüm ve e-posta. Oturum tarafında Sanctum; API rotaları web rotalarından ayrı bir dosyada. Tekrarlayan işler tek bir zamanlanmış iş sınıfında toplanmış. Raporlama tarafında PDF ve elektronik tablo çıktısı doğrudan portaldan alınıyor.

1. 01

   Her dış servis kendi controller'ında

   Portal yedi ayrı dış servisle konuşuyor ve her birinin kimlik doğrulaması, hata biçimi ve oran sınırı farklı. Servis çağrılarını iş mantığının içine dağıtmak yerine her servis kendi giriş noktasında toplandı; bir servisin davranışını anlamak için tek dosyaya bakmak yetiyor.

   ÖdünleşimAyrım dosya seviyesinde kaldı, katman seviyesinde değil: çağrılar controller'ın içinde duruyor, arkalarında bir servis katmanı yok. Bu yüzden aynı servisi ikinci bir yerden çağırmak gerektiğinde kod kopyalanmaya, sağlayıcı değiştiğinde ise birden fazla yer düzenlenmeye açık.

2. 02

   Rol farkı menüde değil veri erişiminde

   Dört rolün gördüğü ekran farklı, ama asıl mesele ekran değil: öğrencinin başkasının kaydına, eğitmenin kendi dersi dışındaki listeye erişememesi gerekiyordu. Yetki kontrolü rota ve controller seviyesinde uygulandı, yalnız arayüzde gizlemekle yetinilmedi.

   ÖdünleşimKontrol uygulama katmanında dağıldığı için her yeni uç kendi kontrolünü yeniden kurmak zorunda; kural veritabanı seviyesinde zorlanmıyor. Yeni bir modül ekleyen biri kontrolü unutursa bunu yakalayan bir mekanizma yok.

3. 03

   Raporlar portalın içinde üretiliyor

   Yönetim tarafı düzenli olarak PDF ve elektronik tablo çıktısı istiyordu. Bunu dışarıdan bir araca bırakmak, verinin dışarı aktarılıp elde işlenmesi demekti — yani her raporun elle üretilmesi. Çıktı üretimi portalın içine alındı.

   ÖdünleşimRapor üretimi istek-yanıt döngüsünün içinde çalışıyor; büyük bir çıktı isteği yanıt süresini doğrudan uzatıyor. Kuyruğa alınmış bir üretim yolu yok.

Laravel, bu kapsamdaki bir portal için hazır gelenlerin toplamı yüzünden seçildi: kimlik doğrulama, yetkilendirme, göç yönetimi, zamanlanmış işler, e-posta ve şablon motoru aynı çatının içinde. Sunucu tarafında şablon üretmek, ayrı bir ön yüz uygulaması ve API sözleşmesi taşımadan iş görmeyi mümkün kıldı — tek geliştiricinin yürüttüğü bir işte bu, taşınan parça sayısını yarıya indiriyor. Sanctum, API rotaları için ağır bir yetkilendirme sunucusu kurmadan token tabanlı erişim verdi. Bugün aynı işi yapacak olsam Next.js tarafını seçerdim; o zamanki karar, ekibin ve devralınan kod tabanının bağlamıyla verildi.

Kimlik doğrulama Laravel'in kendi katmanı üzerinde; oturum ve API erişimi ayrı. Yetki kontrolü rota ve controller seviyesinde uygulanıyor ve dört rol arasındaki fark veri erişiminde görünüyor. Dış servis anahtarları ortam değişkenlerinde tutuluyor. Portal kapalı bir sistem: kamuya açık bir yüzü yok, kayıt akışı yönetim tarafından yürütülüyor. Bu vakada gerçek ekran görüntüsü yayınlanmıyor — ekranların tamamı öğrenci ve personel verisi taşıyor.

Kapalı bir sistem olduğu için saklanmış, tarih damgalı bir ölçüm çıktısı yok ve buraya bir skor yazılmadı. Yapısal olarak sayfalar sunucuda üretilip tam sayfa olarak gönderiliyor; istemci tarafında ağır bir uygulama katmanı taşınmıyor. Bunun bedeli her etkileşimin tam sayfa yenilemesi olması. Rapor üretimi de istek döngüsünün içinde çalıştığı için büyük çıktılarda yanıt süresi doğrudan uzuyor.

Aktif geliştirme

2024-09 → 2025-12 · 980 commit

Kaynak dosyası

398 PHP ve Blade dosyası — app, resources, routes ve database dizinleri

Modül

40 controller · 243 Blade görünümü · 105 web rotası · 24 API rotası

Rol

Dört rol — süper yönetici, yönetici, eğitmen, öğrenci

Ölçüm notu

Bu repoda üçüncü taraf kütüphane klasörü sürüm kontrolüne dahil; sayım yalnız kendi yazdığım dizinlerden alındı

Bu portalın en pahalı eksiği otomatik test yokluğuydu ve bunu yedi entegrasyonlu bir sistemde ödüyorsun: bir sağlayıcı yanıt biçimini değiştirdiğinde hatayı ancak kullanıcı fark ediyor. Bugün en azından dış servis çağrılarını bir servis katmanının arkasına alır, o katmanı da sahte yanıtlarla test ederdim — çağrılar controller'ın içinde kaldığı sürece test edilebilir bir sınır oluşmuyor. İkinci nokta yetki: kontrol uygulama katmanında dağınık durdu ve her yeni uç kendi kontrolünü yeniden kurmak zorunda kaldı. Taxilos'ta aynı desenin daha sert bir sürümünü gördüm — kural 45 ayrı yerde tekrarlandığı için tek bir predicate hatası kapıların tamamını açtı. Üçüncüsü raporlama: çıktı üretimini istek döngüsünün dışına, bir kuyruğa taşırdım; bugün büyük bir rapor isteyen kullanıcı, o isteğin bitmesini bekliyor.