v2 nedir?
v2, haljet-api-new kod tabanında geliştirilen ikinci Haljet API servisidir. haljet-api üretimde çalışan v1 olarak kalır; v2 onun yerini tek seferde almak yerine ihtiyaç duyulan panel ve mobil yüzeylerini kademeli olarak devralır.
İki servis geçiş boyunca aynı MySQL, MongoDB ve Redis altyapısını kullanır. Aynı erişim ve yenileme jetonu sırlarıyla çalıştıkları için kullanıcı tek oturumla ikisine de istek gönderebilir.
v1 ve v2 bugün
v1 — haljet-api | v2 — haljet-api-new | |
|---|---|---|
| Durum | Üretimdeki geniş kapsamlı servis | Kademeli olarak devreye alınan ikinci servis |
| Kod yapısı | src/modules/* merkezli | src/core, src/domains/*, src/ops |
| Kapsam | Mevcut mobil, panel, cron ve entegrasyon akışları | Taşınmış panel uçları, yeni panel ihtiyaçları ve yeni BUYER uygulaması |
| Prisma şeması | Şemanın ve migration'ların sahibi | v1 şemasının salt ayna kopyasını kullanır |
| Yerel adres | Varsayılan API portu | .env.example ile 3001; APP_PORT yoksa kod 3000 kullanır. Swagger /swagger |
İç yapı
v2 üç katmana ayrılır:
| Katman | Kapsam |
| --- | --- | --- |
| core | Kimlik, yapılandırma, veri bağlantıları ve ortak entegrasyonlar |
| domains | catalog, comms, finance, logistics, orders, parties iş alanları |
| ops | Panel yüzeyinde görünmeyen yeniden kurma ve backfill işlemleri |
Her Mongo koleksiyonunun tek bir yazma sahibi vardır. Bir alan başka alanın verisini genel olarak o alanın yayımladığı servisten okur; stok ile faturayı eşleyen açık salt-okuma istisnaları sahipliği değiştirmez. report gibi her şeyi toplayan bağımsız bir iş alanı kurulmaz; rapor, cevapladığı iş sorusunun alanında yaşar.
Detay: v2 mimarisi ve domain haritası.
İki tür uç
v2'de bir HTTP ucu baştan iki sınıftan biri olarak ele alınır:
- Taşınan uç v1'deki yolu, geçerli istek biçimini, yanıtı ve iş mantığını korur. İki servis aynı veriyi okuduğu için sonuçları karşılaştırılabilir.
- Yeni uç
/finance/*,/orders/buyer/*,/parties/*,/logistics/*veya/comms/buyer/*gibi alan önekleri kullanır. Sözleşmesi yeni ekranın ya da yeni mobil uygulamanın ihtiyacına göre kurulur.
Tanımsız parametrelerin 400 dönmesi ve hata gövdesinin farklı olması, taşınan uçlardaki iki genel farktır. Uç bazında başka bir davranış değişikliği ancak tarihli ve açık bir kararla yapılır.
Detay: Geçiş ve veri sahipliği.
Geçiş sınırı
Yeni BUYER uygulaması yalnızca v2 ile konuşur; eski uygulama v1'de kalır. Buna rağmen sipariş yaşam döngüsü henüz tek serviste değildir:
- v2, siparişi v1'in Mongo belge biçiminde oluşturur.
- Kart ödemesini v2 başlatır.
- Ödeme sağlayıcısının geri çağrısı v1'e gelir.
- Hazırlık, fatura ve v1'de kalan diğer adımlar aynı ortak belge üzerinde devam eder.
Zamanlanmış işler, migration ve hesaplama uçlarının çoğu da v1'de kalır. Taşınan ve henüz taşınmayan yüzeyler için geçiş ve veri sahipliği sayfasına bakın.
Eski plan belgeleri
Bu bölüm ilk yazıldığında v2, v1 içindeki 27 modülün dört alana ayrılacağı bir yeniden yapılanma planıydı. v1 modül alan haritası bu tarihsel analizi korur. Planlanan şirket ve depo hiyerarşisi ise uygulanmamış bir tenant tasarımıdır; v2'nin bugünkü depo kapsamı farklıdır.
Mevcut kodda karşılığı olmayan veya kısmen karşılanan ihtiyaçlar Yeni ihtiyaçlar sayfasında izlenir.