Scaling SSR Inertia: Trade-off Daemon Node vs On-Demand Serverless

Server-Side Rendering (SSR) pada Inertia.js bekerja dengan mendelegasikan proses rendering komponen Vue, React, atau Svelte ke runtime Node.js, sementara backend utama (seperti Laravel) bertindak sebagai data orchestrator. Ketika aplikasi tumbuh, layer rendering ini menjadi titik kritis dalam skalabilitas sistem. Terdapat dua paradigma arsitektur utama untuk menjalankan SSR Inertia pada level produksi: Long-running Node.js Daemon (dikelola via PM2 atau Supervisord) dan On-Demand Serverless (AWS Lambda via Bref atau custom execution runtime).

1. Karakteristik Latensi: Loopback IPC vs Network Overhead

Model komunikasi antara backend monolith dan engine SSR menentukan batas minimum latensi P95 dan P99 dari setiap request HTML awal.

Long-running Node Daemon

Pada arsitektur daemon, backend dan proses Node.js biasanya berada di host yang sama (co-located) atau terhubung melalui private container network. Backend berkomunikasi dengan service Node.js melalui local loopback interface (127.0.0.1:13714) atau Unix Domain Socket (UDS).

• Overhead Jaringan: Sub-milidetik (< 0.5 ms untuk loopback, < 0.1 ms untuk UDS).
• Waktu Eksekusi: Murni dibatasi oleh durasi serialisasi props dan rendering komponen oleh engine V8 (umumnya 5–25 ms untuk halaman dengan kompleksitas moderat).
• Throughput: Sangat efisien untuk synchronous render pipelines karena runtime Node.js sudah berada dalam status warmed-up dan JIT compiler V8 telah mengoptimalkan hot paths render tree.

On-Demand Serverless (AWS Lambda)

Serverless memisahkan execution environment ke ephemeral microVM (seperti AWS Firecracker). Backend memanggil fungsi serverless melalui AWS SDK direct invocation, API Gateway, atau Application Load Balancer (ALB).

• Overhead Jaringan: 10–35 ms latensi round-trip (RTT) antar-VPC atau melalui HTTP gateway eksternal sebelum payload mencapai runtime.
• Cold Start: Jika instance baru harus dialokasikan, backend terkena penalti inisialisasi microVM, booting runtime Node.js, parsing bundle bundle SSR JavaScript (ssr.js), dan eksekusi initial modules. Ini menambah latensi 250 ms hingga lebih dari 1.5 detik pada P99.
• Warm Request: Pada container yang sudah aktif, eksekusi render mendekati performa daemon, tetapi tetap memiliki penalti network transit layer transport.

2. V8 Heap Management vs Mitigasi Cold Start

Kedua arsitektur memiliki kelemahan mendasar pada level eksekusi kode JavaScript:

Risiko Memory Leak pada Long-running Daemon

V8 heap pada proses Node.js jangka panjang rentan terhadap memory leak yang disebabkan oleh state global atau closure yang tidak dibersihkan di library pihak ketiga. Pola umum penyebab memory leak di Inertia SSR meliputi:

• Variabel state global di level modul yang terisi pada setiap render cycle.
• Event listener tanpa teardown logic yang benar.
• Cache in-memory komponen yang tidak memiliki batas kapasitas (unbounded).

Akumulasi objek ini memperpanjang durasi stop-the-world Garbage Collection (GC) V8, menyebabkan degradasi performa bertahap hingga proses crash karena Out of Memory (OOM). Solusi standar pada level daemon adalah menerapkan mekanisme restart berkala saat batas memori tercapai (misal: max-memory-restart 500M pada PM2).

Mitigasi Cold Start pada Serverless

Serverless mengeliminasi risiko akumulasi memory leak jangka panjang karena execution environment di-recycle secara berkala oleh cloud provider. Namun, arsitektur ini memindahkan beban optimasi ke mitigasi cold start:

• Bundle Splitting & Tree Shaking: File ssr.js harus sekecil mungkin. Hindari mengimpor library non-SSR atau pustaka browser-only (seperti charting libraries) ke bundle server.
• Provisioned Concurrency: Mengalokasikan instance Lambda yang selalu standby. Solusi ini menyelesaikan cold start, tetapi mengubah model biaya serverless menjadi menyerupai fixed instance cost.

3. Kompleksitas Observabilitas Runtime

Mendiagnosis kendala SSR membutuhkan visibilitas terhadap CPU profiling, heap snapshot, dan alur request antar-service.

4. Analisis Struktur Biaya: Steady vs Burst Traffic

Model penetapan biaya infrastruktur menentukan efisiensi ekonomi bergantung pada profil beban traffic:

Traffic Konstan dan Terprediksi (Steady State)

Jika aplikasi menerima beban konsisten sebesar 200 RPS sepanjang hari, model Node Daemon jauh lebih murah secara signifikan.

Total Permintaan per Bulan:
200 RPS * 86,400 detik * 30 hari = 518,400,000 requests.

Biaya Node Daemon (Dedicated Compute):
- 2x VM 4 vCPU, 8GB RAM (High Availability): ~$80 - $120 / bulan.
Total: ~$120 / bulan.

Biaya Serverless (AWS Lambda, 512MB RAM, avg duration 35ms):
- Compute (GB-second): ~518.4M * 0.035s * 0.5GB = 9,072,000 GB-s -> ~$150
- Invocations: 518.4M requests -> ~$103
- API Gateway / ALB data transfer: ~$500+
Total: ~$750+ / bulan.

Traffic Berfluktuasi Ekstrem atau Sporadis (Burst / Off-peak Panik)

Untuk aplikasi dengan variasi load tinggi (misal: 5 RPS pada jam kerja normal, melonjak ke 1.000 RPS saat flash sale selama 15 menit), model Serverless menghindari pemborosan alokasi idle capacity. Daemon memerlukan over-provisioning kapasitas komputasi untuk menampung peak load, yang berujung pada tingginya biaya idle capacity saat off-peak.

5. Pola Resiliensi: Failover Graceful ke CSR

SSR pada Inertia.js adalah layer optimasi untuk SEO dan First Contentful Paint (FCP), bukan dependensi fungsional mutlak. Jika engine SSR mengalami timeout, OOM, atau network failure, backend wajib melakukan fallback otomatis ke Client-Side Rendering (CSR) tanpa mengembalikan HTTP 500 ke end-user.

Berikut adalah implementasi custom SSR Gateway pada Laravel yang menerapkan circuit-breaker timeout sederhana untuk fallback otomatis ke CSR:

<?php

namespace App\Services\Inertia;

use Exception;
use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Log;
use Inertia\Ssr\Gateway;
use Inertia\Ssr\Response;

class ResilientSsrGateway implements Gateway
{
    public function dispatch(array $page): ?Response
    {
        if (!config('inertia.ssr.enabled', false)) {
            return null;
        }

        $url = str_finish(config('inertia.ssr.url', 'http://127.0.0.1:13714'), '/') . 'render';

        try {
            // Strict timeout: Jangan biarkan SSR memblokir response backend lebih dari 350ms
            $response = Http::timeout(0.35)
                ->connectTimeout(0.1)
                ->post($url, $page)
                ->throw();

            return new Response(
                implode("\n", $response->json('head', [])),
                $response->json('body', '')
            );
        } catch (Exception $e) {
            // Log anomaly untuk monitoring, tapi biarkan user menerima unrendered page (CSR fallback)
            Log::warning('SSR render failed, falling back to CSR: ' . $e->getMessage(), [
                'component' => $page['component'] ?? 'Unknown',
                'url' => $page['url'] ?? '',
            ]);

            return null; // Return null memicu default template CSR bawaan Inertia
        }
    }
}

Registrasikan gateway ini pada service provider (AppServiceProvider.php):

public function register(): void
{
    $this->app->bind(\Inertia\Ssr\Gateway::class, \App\Services\Inertia\ResilientSsrGateway::class);
}

6. Matriks Keputusan Pemilihan Arsitektur

Gunakan acuan teknis berikut untuk menentukan arsitektur deployment yang sesuai dengan kapasitas tim dan karakteristik sistem: