# Audit Teknis MPWA - 2026-07-18

## Ringkasan Eksekutif

Codebase MPWA saat ini belum production-ready untuk target arsitektur resmi WhatsApp Business Platform berbasis Meta Cloud API. Implementasi yang ada masih berupa arsitektur hybrid:

- Laravel 12 dipakai untuk dashboard, admin panel, API publik, billing, dan sebagian business logic.
- Node.js + Express dipakai sebagai engine koneksi WhatsApp dan pengiriman pesan.
- Engine WhatsApp saat ini masih bergantung pada `baileys`, sehingga belum selaras dengan target integrasi resmi Meta Cloud API.
- Orkestrasi blast, queue, webhook, auth API, dan monitoring masih tersebar di beberapa layer tanpa boundary yang tegas.

Kesimpulan audit:

- Platform perlu direbuild secara bertahap, bukan sekadar patch incremental.
- Integrasi resmi Meta Cloud API harus dipisahkan secara tegas dari layer legacy non-resmi.
- Queue, webhook, security, dan API contract perlu dijadikan fondasi ulang sebelum optimasi UI lanjutan.

## Temuan Arsitektur Saat Ini

### 1. Arsitektur Hybrid Laravel + Node

Komponen utama:

- Laravel:
  - `app/`
  - `routes/web.php`
  - `routes/api.php`
  - `app/Services/Impl/WhatsappServiceImpl.php`
- Node:
  - `server.js`
  - `server/router/index.js`
  - `server/controllers/*.js`
  - `server/whatsapp.js`

Masalah utama:

- Boundary antara dashboard/API Laravel dan engine WhatsApp Node belum eksplisit.
- Laravel memanggil Node lewat HTTP internal dengan route seperti `/backend-send-text`, `/backend-blast`, `/backend-check-number`.
- Tidak ada abstraction resmi untuk provider WhatsApp, sehingga layer transport bercampur dengan rule bisnis.

Dampak:

- Sulit dipelihara.
- Sulit diuji.
- Sulit dipisah antara integrasi resmi Meta dan konektor legacy.

### 2. Ketergantungan Pada Konektor Non-Resmi

`package.json` masih mendeklarasikan:

- `baileys: 7.0.0-rc13`

Deskripsi package juga masih berorientasi gateway non-resmi dan anti-ban hardening. Ini tidak cocok untuk target implementasi resmi WhatsApp Business Platform.

Risiko:

- Tidak sesuai objective baru.
- Arsitektur lama mendorong coupling kuat ke session device lokal.
- Konsep session, QR, pairing, dan reconnect lama berbeda dengan model Meta Cloud API.

### 3. Route Internal Node Terbuka

Di `server/router/index.js` terdapat banyak endpoint backend, misalnya:

- `/backend-send-text`
- `/backend-send-media`
- `/backend-send-button`
- `/backend-blast`
- `/backend-check-number`
- `/backend-clearCache`
- `/backend-health`

Temuan:

- Route ini dipasang sebagai endpoint HTTP biasa.
- Belum terlihat mekanisme service-to-service authentication yang kuat.
- Belum terlihat request signing, internal secret rotation, atau granular authorization.

Risiko:

- Abuse internal endpoint.
- Message injection.
- Trigger blast tanpa kontrol yang cukup ketat.

### 4. Queue Belum Menjadi Tulang Punggung Sistem

`config/queue.php` masih default ke:

- `QUEUE_CONNECTION=sync`

Blast saat ini tidak digerakkan oleh queue persisten Redis sebagai core workflow. Sebaliknya:

- Laravel scheduler memicu command periodik.
- Node menyimpan queue blast di memori proses.

Masalah:

- State antrean bisa hilang saat proses restart/crash.
- Retry, dead letter, delayed queue, dan monitoring belum matang.
- Tidak cocok untuk sistem messaging production dengan worker pool.

### 5. Query SQL Mentah di Node

Pada `server/database/model.js` masih terdapat raw string concatenation, misalnya query berdasarkan:

- `deviceBody`
- `keyword`

Risiko:

- SQL injection.
- Query error karena escaping yang buruk.
- Sulit diaudit dan diobservasi.

Status:

- Sebagian query pernah diperbaiki pada sesi sebelumnya, tetapi codebase saat ini masih menyisakan query raw yang berisiko.

### 6. API Authentication Masih Lemah dan Tidak Konsisten

`app/Http/Middleware/CheckApiKey.php` menunjukkan model auth API saat ini masih:

- memakai `api_key` plaintext
- mengikat device melalui `sender`
- tanpa token lifecycle modern

Temuan:

- Sanctum ada di dependency, tetapi belum menjadi pola auth utama untuk REST API bisnis.
- Tidak ada pemisahan jelas antara user token, service token, webhook secret, dan device credential.
- Belum ada refresh token flow yang rapi untuk API eksternal platform.

### 7. Webhook Belum Mengikuti Pola Resmi Meta

Istilah webhook di codebase saat ini dominan berarti:

- webhook user-defined per device
- outbound POST untuk automasi/bot internal

Belum terlihat fondasi penuh untuk:

- webhook verification resmi Meta
- signature validation
- idempotent inbound event handling
- event replay aman
- event store dan observability yang kuat

### 8. Scheduler dan Blast Masih Rapuh

Blast dijalankan melalui kombinasi:

- `app/Console/Commands/StartBlast.php`
- `server/controllers/blast.js`

Masalah:

- Queue in-memory.
- Retry dan resume tidak cukup persisten.
- Potensi duplicate send dan lost state setelah restart.
- Belum ada DLQ dan job visibility yang baik.

### 9. Monitoring dan Logging Belum Terpusat

Saat ini logging dan observability masih tersebar:

- Laravel logging default
- `console.log` di sisi Node
- tidak terlihat event taxonomy terpusat

Gap:

- Belum ada structured logging lintas service.
- Belum ada korelasi request ID / job ID / message ID / webhook event ID.
- Belum ada dashboard operasional yang cukup untuk queue, webhook, worker, dan rate limit.

### 10. UI/Dashboard Masih Dashboard Legacy

UI saat ini masih berpusat pada blade theme Vuexy.

Meskipun fungsional, masih ada gap terhadap target:

- real-time operational dashboard
- queue monitor
- webhook monitor
- worker monitor
- health center
- analytics yang lebih operasional
- PWA yang lebih eksplisit untuk monitoring mobile

## Gap Terhadap Target Baru

Target baru meminta platform modern, scalable, secure, dan production-ready untuk:

- cPanel hosting
- PHP + Node.js + MySQL + Redis
- integrasi resmi WhatsApp Business Platform

Gap utama yang harus ditutup:

1. Provider WhatsApp resmi belum menjadi arsitektur inti.
2. Queue Redis belum menjadi backbone pengiriman pesan.
3. Webhook inbound resmi Meta belum dibangun sebagai pipeline yang idempotent.
4. API contract belum distandarkan dengan OpenAPI dan versioning yang jelas.
5. Security baseline belum cukup kuat untuk deployment production multi-tenant.
6. Monitoring, audit log, dan analytics operasional belum matang.

## Risiko Prioritas Tinggi

### P0 - Wajib Ditangani Dulu

- Ketergantungan pada konektor non-resmi sebagai jalur utama pengiriman.
- Endpoint internal Node belum diproteksi secara service-to-service.
- Query raw di Node masih membuka risiko injeksi.
- Queue blast masih berbasis memori proses.
- Webhook/event handling belum idempotent dan belum berbasis event store.

### P1 - Segera Setelah Fondasi

- Auth API belum konsisten.
- Rate limiting belum queue-aware.
- Logging belum terstruktur lintas modul.
- Tidak ada DLQ dan replay workflow.
- Tidak ada pemisahan jelas antara command, webhook event, dan delivery status pipeline.

### P2 - Setelah Core Stabil

- Rebuild dashboard operasional modern dark.
- OpenAPI/Swagger/Postman.
- Backup/restore workflow.
- Storage abstraction multi-backend.
- Analytics dan reporting lanjutan.

## Rekomendasi Arsitektur Baru

### Prinsip

- Official-first: Meta Cloud API menjadi jalur resmi default.
- Legacy isolation: konektor lama dipisahkan sebagai modul kompatibilitas, bukan core.
- Queue-first: semua message dispatch melewati queue persisten.
- Event-driven: status, webhook, dan analytics mengikuti event pipeline.
- Secure-by-default: semua endpoint internal dan eksternal dilindungi.
- cPanel-aware: tetap realistis terhadap batas shared hosting.

### Boundary Service Yang Disarankan

1. Laravel App
- Dashboard
- REST API
- Auth/RBAC
- OpenAPI docs
- Admin config
- Billing/subscription

2. Messaging Domain
- Message validation
- permission check
- quota check
- pipeline orchestration
- status update
- audit log

3. Official Meta Cloud API Adapter
- phone number management
- template management
- media upload/download
- send message
- message status mapping
- webhook verification

4. Queue + Worker Layer
- Redis queue
- priority queue
- delayed queue
- retry queue
- DLQ
- worker pool

5. Webhook Intake Layer
- verify token
- signature validation
- duplicate detection
- inbound event store
- replay endpoint

6. Monitoring Layer
- health check
- queue metrics
- worker metrics
- webhook metrics
- API usage metrics

## Scope Rebuild Yang Direkomendasikan

### Fase 1

- Pisahkan arsitektur official Meta dari engine legacy.
- Bangun fondasi config, credential storage, provider interface, dan service contract.
- Kunci endpoint internal dan rapikan auth service-to-service.
- Hilangkan query raw prioritas tinggi di Node.

### Fase 2

- Bangun Redis queue backbone.
- Refactor blast dan scheduling ke job-worker persisten.
- Tambahkan retry policy, DLQ, throttling, dan worker monitoring.

### Fase 3

- Bangun webhook resmi Meta end-to-end.
- Tambahkan verification, signature validation, idempotency, replay, analytics.

### Fase 4

- Bangun REST API v1 yang terdokumentasi.
- Refactor auth ke model token yang lebih modern.
- Tambahkan audit log, RBAC, rate limit, dan API usage monitoring.

### Fase 5

- Rebuild dashboard modern dark + PWA.
- Tambahkan realtime health, queue monitor, webhook monitor, worker monitor.

## Catatan Implementasi Penting

- Fitur non-resmi tidak boleh menjadi jalur default untuk production resmi.
- Jangan menambahkan fitur yang bertujuan menghindari pembatasan atau penegakan kebijakan WhatsApp.
- Fitur legacy yang masih dipertahankan harus diberi label jelas sebagai compatibility mode.
- Semua implementasi baru harus mengacu pada dokumentasi resmi Meta Cloud API.

## Deliverable Audit Ini

Dokumen ini menjadi baseline untuk:

- refactor plan
- issue breakdown
- prioritas batch implementasi
- pemisahan official vs legacy architecture