Sahada okuma terminalleri var. Her biri açılırken “ben çalışabilir miyim?” diye soruyor — lisans geçerli mi, hangi izinlere sahip, ne zamana kadar.
Bu soruyu cevaplayan bir sunucu gerekiyordu. Bir de kimin hangi terminali kullandığını, hangi cihazın ne zaman ne yaptığını gösteren bir panel.
Neden hazır çatı kullanmadım
İlk refleks bir framework kurmak oldu. Sonra ihtiyaç listesine baktım:
- Beş sayfa: giriş, gösterge, terminaller, loglar, kullanıcılar
- İki tablo (ikisi de zaten var)
- Bir API ucu
- Tek bir rol: yönetici
Bunun için 40 MB bağımlılık indirmek, bir yapılandırma ekosistemi öğrenmek ve her yıl sürüm yükseltmesiyle uğraşmak anlamsız geldi.
Kendim yazdım. Altı sınıf:
App uygulama kabuğu, konteyner
Router yol → denetleyici eşlemesi
Request girdi, başlıklar, gövde
Response çıktı, başlık, yönlendirme
Db PDO sarmalayıcı (hazırlanmış sorgu)
View şablon dahil etme, kaçış
Auth oturum, parola doğrulama
Toplamı 900 satırın altında. Ve tam olarak ihtiyacım olan kadar — fazlası da eksiği de yok.
Framework’ün asıl değeri kod tasarrufu değil, ortak dil. Ekipte beş kişi varsa herkesin aynı desene bakması, altı sınıflık özel bir çatıdan kat kat iyidir. Ama burada ekip bir kişi ve kapsam sabit. O durumda framework bir kolaylık değil, bir bağımlılık.
Gizli olan her şey web kökü dışında
Klasör düzeninde tek bir kural var ve her şey ondan çıkıyor:
service.bzt/
private/ ← web sunucusu buraya ERİŞEMEZ
config/ yapılandırma, veritabanı bilgileri
core/ altı sınıf
controllers/
views/
storage/ kullanıcılar, loglar
www/ ← web kökü burası
index.php tek giriş noktası
.htaccess her şeyi index.php'ye yönlendir
assets/
Bu ayrımın değeri şurada: bir gün .htaccess çalışmazsa ya da bir yapılandırma hatası olursa, saldırgan yapılandırma dosyasına ulaşamaz — çünkü o dosya web sunucusunun görebildiği ağacın içinde bile değil.
Paylaşımlı hostinglerde en sık gördüğüm sızıntı türü tam olarak bu: yanlış yapılandırma yüzünden servis edilen bir config.php.
Eski sözleşme birebir korundu
Bu servis, var olan bir API’nin yerine geçiyor. Sahadaki terminaller o API’yi bekliyor ve güncellenemiyorlar — kimi araçta, kimi bodrumda.
Bu yüzden kural netti: yanıtın tek bir alanı bile değişmeyecek.
GET /terminal/api/?op=get&p=license&key={donanım}&ver={sürüm}
{
"status": …,
"v2": { "securekey": … }, ← aya göre üretilen anahtar
"time": { "license_expire": … },
"perm": { "read": …, "edit": … },
"admin": { … },
"security": { "manuplationlock": … }
}
İç tarafı tamamen yeniden yazıldı. Dış tarafı — alan adları, yazım hataları dahil — aynen duruyor.
Bedel: bazı alan adları mantıksız ve öyle kalıyor. Yeni bir geliştirici bunlara bakıp “neden böyle?” diyecek.
Getiri: geçiş sırasında sahada tek bir cihaz bile durmadı. Yeni sunucu açıldı, eski adres yönlendirildi, kimse fark etmedi.
Sahada çalışan bir sistemi yenilerken, görünmez bir geçiş temiz bir API’den daha değerli.
Ve konsol teması
Panelin görünümü bilinçli bir seçim: siyah zemin, tek aralıklı yazı tipi, terminal hissi.
Sebep estetik değil. Bu paneli kullanan kişi teknik biri — sahadaki bir sorunu teşhis ediyor. Kutular ve renkli kartlar yerine yoğun ve okunabilir bir liste istiyor. Terminal estetiği bunu doğal biçimde veriyor: bir ekranda çok satır, hiyerarşi tipografiyle.
Ne öğrendim
“Hangi framework?” sorusu genelde erken sorulan bir soru. Önce şunu sormak gerekiyor: bu sistem beş yıl sonra kaç ekran olacak?
Cevap “beş” ise, çatının kendisi projeden büyük olur. Cevap “elli” ise, çatısız başlamak bir yıl sonra pişmanlık olur.
Burada cevap beşti. Ve üç ay sonra hâlâ beş.