Backend — MySQL Üstünde Tek REST Sözleşmesi
Baştan ORM kullanmamaya karar verdim.
Rol
Şema, para kuralları ve sözleşme benim; kuralları koddan önce yazdım ve her uç noktayı onlara karşı denetledim. Uygulamayı yapay zekâ kodlama ajanlarıyla yürüttüm. Senkron idempotency'si, push aktarımı, Caddy ile Docker ve JWT ayrıntıları, giderken öğrendiğim kısımlar.
Stack
Overview
Baştan ORM kullanmamaya karar verdim. Oracle SQL eğitimim vardı, bir sorguyu bir model katmanından daha hızlı okuyordum ve şemanın çok değişeceği belliydi. Değişti de: boş veritabanından sırayla uygulanan 28 numaralı migration dosyası ve on üç revizyon geçiren bir API sözleşmesi. Node ve Express, MySQL üstünde; hazır ifadelerle ham SQL, üç rol için tek JWT düzeni. Para bir DECIMAL sütunu, kodda tamsayı kuruş; yuvarlama hiçbir bakiyeye dokunmuyor. Aylık aidatı üreten cron bugünün tarihini sormuyor. Bu ayın aidatı üretildi mi diye soruyor; sunucu ayın birinde kapalıysa, açıldığında üretiyor.
Neler yapıyor
- ISırayla uygulanan 28 SQL migration'ı. Şema o dosyaların kendisi; model katmanı yok
- IIHer istekte geçerli aidat eksi geçerli ödeme olarak hesaplanan bakiye. Hiç saklanmıyor.
- IIIÖdemelerin tipi var. Bakım parası aidatı, tamirat parası tamirat borcunu kapatıyor; ikisi karışmıyor
- IVBu ayın aidatı var mı diye soran cron; bir haftalık kesinti sonradan tamamlanıyor
- VOn dört test paketi; veritabanına dokunanlar tek kullanımlık bir veritabanı gösterilmeden başlamıyor
Ekranlar
Teknik notlar
- Iİlk dağıtım modeli tek havuzdu. Her ödeme en eski açık kalemi kapatıyordu; bu bir bakım ayı da olabiliyordu, bir tamirat borcu da. Testleri geçti ve bir gün dayandı. Pratikte babamın kafasını karıştırdı, çünkü tamirat için verilen para eski bir bakım ayına gidebiliyordu; v2.11 ödemelere tip verdi, her borca da en eskiden başlayan kendi yürüyüşünü. Tamirat ödemesi tamirat borcunu aşamıyor; bakım ödemesi aşabiliyor, fazlası alacak oluyor.
- IIBir ödemenin hangi ayları kapattığı okuma anında hesaplanıyor, hiç yazılmıyor. Bu, dökümü dürüst tutuyor; ama öngörmediğim bir bedeli çıktı: eski bir makbuz yeniden üretilemiyor, çünkü sonraki ödemeler ve iptaller cevabı değiştiriyor. Saklama işi makbuz PDF'lerini altı ay sonra silecekti. Artık muaflar, kalıcı olarak duruyorlar.
- IIITest düzeneği zirve_test adında bir veritabanı yaratıyor, orada çalışıyor ve siliyor. Her paketin başındaki bir bekçi, hedef bu değilse başlamayı reddediyor. Bunu, bir paket dosyasını doğrudan çalıştırmanın .env'deki veritabanına düşüp içine çöp bina yazacağını fark ettikten sonra ekledim.
Neler öğrendim
Cron'un bariz hâli yanlış. Bugün ayın biri mi diye sormak, ayın birinde uyuyan sunucunun o ayın aidatını hiç üretmemesi demek; bir bakiye eksik çıkana kadar da kimse fark etmiyor. Bu ayın aidatı var mı diye sormak fazladan hiçbir şeye mal olmuyor ve işi istediğiniz kadar tekrar çalıştırılabilir yapıyor.