Arsitektur CAD di Browser: WebAssembly vs Server-Side Rendering

Menjalankan Computer-Aided Design (CAD) berbasis web menghadirkan tantangan komputasi grafis dan pemodelan parametrik yang berat. Mesin CAD tradisional seperti OpenCASCADE (fondasi FreeCAD) mengandalkan perhitungan matematis Boundary Representation (B-Rep), tessellation dinamis, dan raycasting yang rakus CPU serta memori. Dua pendekatan utama mendominasi arsitektur ini: mengeksekusi komputasi langsung di browser via WebAssembly (WASM) atau memprosesnya di backend menggunakan Server-Side Rendering (SSR) berbasis streaming WebRTC.

Arsitektur 1: Client-Side WebAssembly (WASM)

Pada arsitektur WASM, seluruh runtime CAD atau modul geometri inti (kernel C++) dikompilasi ke format biner .wasm via Emscripten. Browser bertindak sebagai runtime independen yang menangani logika B-Rep, tessellation, dan manipulasi objek di client.

Pipeline Rendering dan Komputasi

Eksekusi geometri berat tidak boleh memblokir thread UI browser. Arsitektur WASM modern memisahkan thread menggunakan Web Workers dan antarmuka shared buffer:

• Web Workers & pthreads: Emscripten mengabstraksi POSIX threads menggunakan Web Workers dan SharedArrayBuffer. Komputasi kernel B-Rep berjalan di worker thread tanpa membekukan antarmuka browser.
• WebGPU / WebGL: Hasil tessellation menghasilkan vertex dan index buffers. Data ini ditransfer langsung ke GPU client menggunakan context WebGPU atau WebGL2 untuk rendering interaktif 60 FPS.

Contoh isolasi worker untuk komputasi kernel CAD dan rendering offscreen:

// main.js - Inisialisasi OffscreenCanvas ke Web Worker
const canvas = document.getElementById('cad-viewport');
const offscreen = canvas.transferControlToOffscreen();

const cadWorker = new Worker('cad-worker.js', { type: 'module' });
cadWorker.postMessage({ canvas: offscreen }, [offscreen]);

// cad-worker.js - Eksekusi WASM & pipeline render
import initCadModule from './cad_core.js';

let cadModule;
self.onmessage = async (e) => {
  if (e.data.canvas) {
    const gpuContext = e.data.canvas.getContext('webgpu');
    cadModule = await initCadModule();
    // Inisialisasi loop rendering dan alokasi buffer vertex
  }
};

Arsitektur 2: Server-Side Rendering via WebRTC Streaming

Arsitektur SSR mempertahankan kernel CAD native di container Linux server yang dilengkapi GPU virtual (vGPU). Interaksi mouse/keyboard dikirim dari browser via DataChannel WebRTC, server merender frame menggunakan EGL/OpenGL tanpa display window (headless), lalu melakukan hardware video encoding (H.264/AV1) untuk di-stream kembali ke elemen <video> di browser.

Pipeline WebRTC Headless

1. Browser menangkap event PointerEvent dan mengirim payload koordinat/perintah melalui WebRTC DataChannel.
2. Server menerima event, memodifikasi scene graph, dan melakukan render via OpenGL/Vulkan konteks headless.
3. Frame buffer disalin langsung ke encoder NVENC/VA-API tanpa transisi memory host berlebih.
4. RTP stream dikirim kembali ke browser dengan latensi sub-100ms tergantung jarak jaringan.

Analisis Trade-Off Teknis

1. Latensi Input (Interaction Latency)

Pada WASM, latensi rotasi viewport, hovering, dan snapping berbasis lokal mencapai <16ms (1 frame pada refresh rate 60Hz). Pengguna mendapatkan respon instan tanpa interferensi jitter jaringan. Pada SSR, round-trip time (RTT) jaringan, jitter buffer, serta overhead decoding video menghasilkan latensi interaksi input-to-photon minimum 50ms hingga 150ms. Angka ini sering kali terasa lagging untuk seleksi edge atau vertex presisi tinggi.

2. Konsumsi Memori Browser

WASM CAD memerlukan alokasi memori besar di sisi browser. Kompilasi kernel seperti OpenCASCADE bersama dependency C++ membutuhkan heap WASM yang diatur via INITIAL_MEMORY dan batas maksimal memori 32-bit (maksimal 4GB per instance). Model perakitan (assembly) besar dapat memicu error Out of Memory (OOM) pada browser mobile atau laptop spesifikasi rendah. Sebaliknya, SSR mempertahankan footprint memori browser tetap kecil karena browser hanya memutar video stream dan merender UI ringan.

3. Biaya Infrastruktur Server

4. Kompleksitas Maintainability dan Cross-Compilation

Mempertahankan kode native C++ di WASM memiliki friksi engineering tinggi. Pengembang harus menyelesaikan masalah keterbatasan arsitektur browser:

• Tidak adanya akses filesystem native (harus menggunakan Emscripten virtual filesystem MEMFS/IDBFS).
• Keterbatasan threading: Tidak ada fork(), debugging deadlock via web workers jauh lebih kompleks.
• Ukuran bundle biner besar: File .wasm berkisar antara 20MB hingga 100MB+ yang menuntut implementasi Brotli compression dan caching Service Worker agresif.

Panduan Evaluasi: Kapan Harus Memilih?

Pilih Client-Side WebAssembly jika:

• Aplikasi menyasar freemium, model SaaS massal, atau platform edukasi dengan skala pengguna besar yang tidak memungkinkan subsidi biaya vGPU per pengguna.
• Model CAD berupa single-part atau perakitan menengah (under 500k polygons).
• Pengguna membutuhkan kapabilitas kerja luring (offline-first) via PWA.
• Kebutuhan input snapping, pengukuran jarak, dan seleksi edge membutuhkan latensi 0ms.

Pilih Server-Side Rendering jika:

• CAD melibatkan perakitan raksasa berskala jutaan komponen (misal: industri otomotif, kedirgantaraan, BIM utuh) yang melampaui batas memori 4GB browser.
• Perlindungan intellectual property (IP) adalah prioritas mutlak. Data CAD asli (file STEP/IGES) tidak boleh terunduh ke RAM client.
• Dukungan hardware client sangat heterogen dan tidak memiliki kartu grafis yang memadai untuk WebGPU/WebGL.