موتوشاب: وضعیت فعلی، معماری هدف و نقشه‌راه محصول

01 وضعیت فعلی در یک نگاه

دو مخزن مستقل، دو دنیای جدا که هنوز به هم وصل نشده‌اند.

02 چه چیزی از موتوشاب فعلی API دارد؟

استخراج‌شده از dispatcher واقعی (web_service_general.php) و انوتیشن‌های @OA.

03 معماری فعلی

یک مونولیت Oxwall به‌ازای هر مشتری؛ همه‌چیز روی یک دیسک، یک دیتابیس.

flowchart TB
  M["Mobile apps
iOS / Android (FCM)"]:::client
  W["Web browsers"]:::client
  M --> IMS
  W --> IMS
  subgraph OX["Oxwall PHP 7.4 monolith — ONE per customer"]
    IMS["iismobilesupport
= API gateway
mobile/services/{information,action}/:type"]:::acc
    PL["~141 iis* plugins
(social + domain + SMS + SSO)"]
    CORE["Oxwall core
ow_base_config (settings)"]
    IMS --> PL --> CORE
  end
  CORE --> DB[("MariaDB 10.5
ow_* tables")]:::store
  CORE --> FS[("ow_userfiles/
local disk, per-plugin")]:::store
  classDef client fill:#eef1f4,stroke:#9aa6b4,color:#1b2431;
  classDef acc fill:#b45e28,stroke:#8a4620,color:#fff;
  classDef store fill:#e3f3ec,stroke:#2e9e6b,color:#14432f;
  

Fig 1 — امروز: هر مشتری = یک کپی کامل از کد + یک دیتابیس + یک پوشه‌ی فایل، به‌صورت دستی نصب می‌شود.

• هیچ لایه‌ی جداکننده‌ای بین کلاینت و مونولیت نیست — اپ مستقیم با پلاگین حرف می‌زند.
• Auth: access_token در واقع همان کوکی ow_login اکسوال است؛ هر ریکوئست دوباره لاگین می‌شود.
• تنظیمات: سه لایه — config.php (per-instance، pepper هاردکد)، جدول ow_base_config (قابل‌ویرایش از ادمین)، و .env (فقط نصب/داکر).
• لیمیت آپلود ۲۰M در سطح php-fpm/nginx هاردکد است — از داشبورد قابل‌تغییر نیست.

04 معماری هدف — «موتور» چندمشتری

یک frontend، یک Gateway، و دو بک‌اند (قدیمی PHP + جدید Django) پشت یک هویت واحد.

flowchart TB
  FE["New React frontend
(from prototype)"]:::acc
  FE --> GW["API Gateway / BFF
یک host، JWT auth واحد"]:::acc
  IDP["Identity Provider
Keycloak / OIDC"]:::idp
  IDP -. validate JWT .- GW
  GW --> BR{"Router / Bridge"}
  BR -->|"social: users, groups,
feed, chat, media, forum"| LEG["Legacy Oxwall API
iismobilesupport"]
  BR -->|"projects, contracts, funds,
research, reports,
settings, storage"| DJ["Django + DRF
services (new)"]:::new
  LEG --> LDB[("tenant MariaDB")]:::store
  DJ --> PGDB[("tenant PostgreSQL")]:::store
  DJ --> OBJ[("Object storage
MinIO / S3")]:::store
  classDef acc fill:#b45e28,stroke:#8a4620,color:#fff;
  classDef new fill:#2e9e6b,stroke:#1f6f4b,color:#fff;
  classDef idp fill:#3e6cb0,stroke:#2c4d80,color:#fff;
  classDef store fill:#e3f3ec,stroke:#2e9e6b,color:#14432f;
  

Fig 2 — هدف: Gateway تصمیم می‌گیرد هر درخواست به دنیای قدیمی برود یا جدید؛ فرانت فقط یک API می‌بیند.

05 اتصال Front Gateway Back و جایگاه Git

پاسخ مستقیم به سؤالت: فرانت چطور به بک وصل می‌شود، bridge چیست، git کجاست.

flowchart LR
  subgraph SRC["Source control"]
    GH["GitHub
frontend + docs
 demo.shub.ir"]:::git
    GL["GitLab (internal)
motoshub-web
+ Django (new repo)"]:::git
  end
  GH -->|"GitHub Actions"| FEBUILD["Frontend build
(static SPA)"]
  GL -->|"GitLab CI"| IMG["Versioned images
+ registry"]
  FEBUILD --> RUNFE["Frontend (served)"]
  RUNFE -->|"HTTPS /api/*"| GW["API Gateway"]
  GW -->|"REST"| DJ["Django services"]
  GW -->|"HTTP form-POST
access_token bridge"| LEG["Oxwall iismobilesupport"]
  IMG --> DJ
  IMG --> LEG
  classDef git fill:#3e6cb0,stroke:#2c4d80,color:#fff;
  

Fig 3 — Git دو جا زندگی می‌کند: فرانت روی GitHub، بک‌اندها روی GitLab. CI هر کدام artifact نسخه‌دار می‌سازد.

Bridge دقیقاً چیست؟

یک آداپتور کوچک داخل Gateway که درخواست REST مدرن فرانت را به قرارداد قدیمی Oxwall ترجمه می‌کند: فرانت GET /api/social/feed می‌فرستد؛ bridge آن را به POST mobile/services/information/get_dashboard با فیلد access_token تبدیل می‌کند، JWT کاربر را به session/کوکی اکسوال map می‌کند، و جواب JSON را نرمال برمی‌گرداند. فرانت از وجود این ترجمه بی‌خبر است.

06 SSO و لاگین — پیشنهاد

همین حالا سه SSO در کد هست؛ باید یکی‌شان را «منبع حقیقت هویت» کنیم.

در سورس این‌ها را داری: iishajsso (OpenID Connect کامل، با کلاینت Jumbojett)، iissso (تیکتی/CAS با single-logout)، و iisgmailconnect (OAuth گوگل). یعنی زیرساخت OIDC از قبل وجود دارد.

sequenceDiagram
  participant U as User
  participant FE as Frontend
  participant GW as Gateway
  participant IDP as Keycloak (OIDC)
  participant OX as Oxwall API
  U->>FE: open app
  FE->>IDP: OIDC login
  IDP-->>FE: id_token + access (JWT)
  FE->>GW: request + Bearer JWT
  GW->>GW: validate JWT (per-tenant realm)
  GW->>OX: bridge  map to ow_login session
  OX-->>GW: data
  GW-->>FE: normalized JSON
  

Fig 4 — لاگین یک‌بار در Keycloak؛ همان توکن هم برای Django و هم (از طریق bridge) برای Oxwall کار می‌کند.

07 چندمشتری بودن و فروش فیچر

قلب مدل کسب‌وکار تو: یک تیم maintain، N مشتری، فروش فیچر به همه.

واقعیت سخت از سورس: هیچ مفهوم tenant/license/feature-flag در کد نیست. اکسوال ذاتاً single-tenant است (یک DB، یک config.php، یک پوشه‌ی فایل به‌ازای هر نصب). پس دو مسیر داری:

توصیه: مدل Instance-per-tenant با یک Control Plane مرکزی. اکسوال را دست‌نخورده نگه می‌داری و multi-tenancy را در لایه‌ی اورکستریشن حل می‌کنی، نه داخل کد قدیمی.

flowchart TB
  GL["GitLab: یک codebase
یک تیم maintenance"]:::git --> REG["Image registry
نسخه‌های immutable (semver)"]
  CP["Control Plane
tenants · licenses · enabled features"]:::acc
  REG --> PROV["Provisioner
(scripted / IaC)"]
  CP --> PROV
  PROV --> T1["Tenant A
app + db + files + settings"]:::t
  PROV --> T2["Tenant B
features: {social, projects}"]:::t
  PROV --> T3["Tenant C
features: {social, funds, SSO}"]:::t
  classDef acc fill:#b45e28,stroke:#8a4620,color:#fff;
  classDef git fill:#3e6cb0,stroke:#2c4d80,color:#fff;
  classDef t fill:#e3f3ec,stroke:#2e9e6b,color:#14432f;
  

Fig 5 — فیچر جدید یک‌بار روی GitLab merge می‌شود یک image نسخه‌دار Control Plane تعیین می‌کند کدام مشتری کدام فیچر را (طبق لایسنسی که خریده) روشن دارد.

«فروش فیچر به مشتری دیگر» یعنی صرفاً یک feature-flag/entitlement در Control Plane روشن شود — نه یک دیپلوی جدید. برای این کار باید یک لایه‌ی سبک tenant + license + entitlement ساخته شود (در Django، به‌عنوان بخشی از فاز ۳).

08 تنظیمات پویا و مدیریت دیسک از داشبورد

دو خواسته‌ی مشخص تو — و اینکه در سورس کجا قلاب می‌شوند.

الف) متغیرهای سیستمی قابل‌مدیریت (upload size و…)

مشکل فعلی: سقف واقعی آپلود در php-fpm.conf/www.conf/nginx روی ۲۰M هاردکد است. راه‌حل حرفه‌ای:

1. در سطح image، محدودیت php/nginx با حاشیه‌ی اطمینان کافی تنظیم شود (برای نمونه 512M) تا سقف سخت‌گیرانه نباشد.
2. لیمیت مؤثر را به جدول ow_base_config (که از قبل زیرساخت admin-editable دارد) منتقل کن و در کد آپلود، به‌جای ini_get() این مقدار DB را بخوان.
3. در پروتوتایپ، بخش SystemSection (که الان mock است) را به این API واقعی وصل کن: GET/PUT /api/core/settings. متغیرهایی که خودت طراحی کرده‌ای (upload_max_mb, chunk_size_mb, user_quota_gb, session_hours…) دقیقاً همین‌ها هستند.

ب) مدیریت مرتب فایل‌ها روی دیسک + داشبورد حجم

الان فایل‌ها زیر ow_userfiles/<plugin>/… ذخیره می‌شوند (لوکال، cloudfiles خاموش)، ولی هیچ quota/آمار/پاکسازی مرکزی نیست. برای داشبوردی که در پروتوتایپ (StorageSection) طراحی کرده‌ای:

• یک collector زمان‌بندی‌شده (cron/Celery) که مصرف هر دسته (پیوست/عکس/ویدیو/temp/بکاپ) و «مصرف‌کننده‌های برتر» را در DB می‌نویسد.
• API: GET /api/storage/stats و POST /api/storage/cleanup (retention). پلاگین iisdatabackup نقطه‌ی شروع خوبی برای بخش بکاپ است.
• برای مقیاس، مسیر مهاجرت به Object Storage (MinIO/S3) باز نگه داشته شود؛ اکسوال از پیش کلید OW_USE_CLOUDFILES دارد.

09 نقشه‌راه قدم‌به‌قدم

پنج فاز؛ هر فاز یک خروجی قابل‌عرضه دارد. تخمین برای یک تیم کوچک بک‌اند.

10 لیست API برای تحویل به فرانت

دو گروه: آماده‌ها (مستندسازی/اتصال) و ساختنی‌ها (Django جدید).

گروه A — از قبل روی Gateway هست (فقط داکس + اتصال)

گروه B — باید ساخته شوند (Django، REST)

11 تسک‌های بک‌اند به‌ترتیب + زمان پیشنهادی

تخمین «مهندسی خالص» برای یک بک‌اند سینیور؛ تست/ریویو جداست.

جمع تقریبی تا پایان فاز ۳: ~۴ تا ۵ ماه کار مهندسی خالص برای یک نفر؛ با تیم دو-سه‌نفره و موازی‌سازی کمتر.

12 نسخه‌گذاری، بکاپ و مدیریت منابع

آنچه امروز شکسته است و فرایند حرفه‌ای پیشنهادی.