OUKITEL B2B Paketi

Problem

OUKITEL'in bölgesel operasyonu, hepsi aynı stok ve müşteri kayıtlarına dokunan farklı roller için araçlara ihtiyaç duyuyordu: bir satış uygulaması, bir servis takip uygulaması, bir program uygulaması ve bir iade akışı.

Dört ayrı kullanıcı kitlesi, dört ayrı uygulama, tek bir kayıt kümesi. Dört arka uç yazmak; cihazın, müşterinin ve servis kaydının dört farklı tanımını garanti ederdi. Dört modlu tek bir uygulama yazmak ise her role, hiç yapmadığı işlerle dolu kalabalık bir arayüz teslim ederdi.

Yaklaşım

Role göre kapsamlanmış yüzeyler sunan tek bir NestJS API'si ve her biri yalnızca kendi rolünün ihtiyacını gösteren dört ince Flutter istemcisi. Dosyalar API üzerinden değil, ön imzalı S3 bağlantılarıyla taşınıyor; böylece servis fotoğrafı yüklemek bir istek işçisini meşgul etmiyor. Yavaş işler — bildirimler, dışa aktarmalar, rapor üretimi — BullMQ kuyruklarına gidiyor.

Fark yaratan kararlar

1. 01

   Tek API, dört istemci

   Şemanın sahibi olan tek bir NestJS servisi, Swagger ile belgelenmiş, role göre kapsamlanmış yüzeyler sunuyor. Her Flutter uygulaması bunun üzerinde ince bir istemci. Beşinci bir rol eklemek, bir yüzey eklemek demek; yeni bir arka uç değil.

2. 02

   Ön imzalı yüklemeler

   Servis fotoğrafları, ön imzalı bağlantılarla cihazdan doğrudan S3'e gidiyor. API kimlik bilgisini üretiyor ve sonucu kaydediyor; baytları hiçbir zaman aktarmıyor. Böylece yükleme trafiği, istek işleme ile aynı işçi havuzu için yarışmayı bırakıyor.

3. 03

   Yavaş olan her şey kuyruğa

   Bildirim dağıtımı, tablo dışa aktarımı ve rapor üretimi Redis üzerinde BullMQ ile çalışıyor. Bin bildirim tetikleyen bir istek anında dönüyor, iş arka planda tükeniyor.

4. 04

   Yerelleştirme istemcide değil, API'de

   `nestjs-i18n` dili sunucu tarafında çözüyor; böylece dört istemci, aynı mesaj kataloğunun birbirinden ayrışan dört kopyasını taşımıyor.

Zor problemler

1. 01

   Dört uygulama, tek sürüm disiplini

   Ortak Dart modelleri ve paylaşılan HTTP katmanı tek tek uygulamalardan çıkarıldı; böylece bir sözleşme değişikliği dört kez değil, bir kez iniyor. Alternatifi — modeli dört depoya kopyalayıp yapıştırmak — biri birini unuttuğu ilk anda sessizce bozulur.

2. 02

   Saha koşulları

   Servis kabulü, bağlantısı güvenilmez atölyelerde yapılıyor. Güvenli yerel depolama, kimlik bilgilerini ve yarım kalmış kayıtları tutuyor; bağlantı koptuğunda hiçbir şey kaybolmuyor ve cihaz döndüğünde yazmalar uzlaştırılıyor.

3. 03

   Tersine mühendislik yapılmış istemciye dayanan yetkilendirme

   Uygulamadaki rol kontrolü kullanıcının ne göreceğini belirler; onu durduran şey o değildir. Her uç nokta, herhangi bir istemcinin değiştirilebileceği varsayımıyla kendi guard'ını sunucu tarafında uygular.