Arsitektur & Filosofi Desain

Tiga keputusan desain fundamental RESTForge — code generation, action-based endpoint, dan multi-database setara

RESTForge dibangun di atas tiga keputusan desain fundamental yang membentuk cara kerja framework. Memahami filosofi ini membantu menilai apakah pendekatan RESTForge sesuai dengan kebutuhan dan budaya tim.

Code Generation, Bukan Runtime Interpretation

Banyak framework menggunakan pendekatan runtime interpretation, di mana konfigurasi dibaca dan dijalankan setiap kali request masuk. RESTForge memilih jalur berbeda: konfigurasi JSON di-translate menjadi source code JavaScript saat build, dan runtime hanya menjalankan code yang sudah jadi.

Aspek	Runtime Interpretation	Code Generation (RESTForge)
Performa	Overhead parsing setiap request	Tanpa overhead karena code sudah optimal
Debugging	Stack trace masuk ke framework internal	Stack trace masuk ke generated code yang bisa dibaca
Kustomisasi	Sulit karena harus override mekanisme framework	Mudah karena generated code bisa diedit langsung
Tooling	Butuh tooling khusus framework	Bisa menggunakan tooling Node.js standar (debugger, profiler, linter)

Generated code adalah aset yang dapat di-review, di-version, di-debug, dan di-extend. Tim tetap memegang kendali penuh, bukan tergantung pada vendor framework untuk fix bug atau menambah fitur.

Alur Kerja (Workflow)

┌──────────────┐      ┌───────────────┐      ┌──────────────────┐
│  Payload JSON │─────▶│  Generator    │─────▶│  JavaScript Code │
│  (konfigurasi)│      │  (CLI)        │      │  (siap jalankan) │
└──────────────┘      └───────────────┘      └──────────────────┘
                                                      │
                                                      ▼
                                              ┌──────────────────┐
                                              │  Express Server  │
                                              │  (runtime)       │
                                              └──────────────────┘

Payload JSON berfungsi sebagai single source of truth. Generator membaca payload dan menghasilkan module JavaScript yang sudah optimal per database. Runtime kemudian menjalankan module tersebut di Express server tanpa overhead interpretasi.

Action-Based Endpoint Pattern

REST tradisional menggunakan HTTP method (GET, POST, PUT, DELETE) untuk membedakan operasi. RESTForge mengadopsi pola action-based di mana operasi dilakukan via HTTP POST dengan nama action di URL path.

POST /api/{project}/{endpoint}/{action}

Contoh Pola URL (URL Pattern Examples)

Operasi	Pola URL
Membuat data baru	`POST /api/inventory/supplier/create`
Membaca banyak record	`POST /api/inventory/supplier/read`
Membaca satu record	`POST /api/inventory/supplier/first`
Mengubah data	`POST /api/inventory/supplier/update`
Menghapus data	`POST /api/inventory/supplier/delete`
Data untuk tabel	`POST /api/inventory/supplier/datatables`
Data untuk dropdown	`POST /api/inventory/supplier/lookup`
Agregasi data	`POST /api/inventory/supplier/aggregate`

Alasan Pendekatan Ini Dipilih

Manfaat	Penjelasan
Mendukung query kompleks	Filter dengan nested condition, multi-operator, dan logika AND/OR dapat dikirim di body tanpa limitasi URL length
Konsisten lintas operasi	Tim tidak perlu beralih antara GET, POST, PUT, DELETE dengan semantik yang berbeda-beda
Mendukung payload besar	Operasi seperti import, bulk create, atau composite master-detail dapat dikirim dalam satu request
Mudah didokumentasikan	Setiap action adalah resource terpisah dengan format yang sama sehingga lebih mudah di-document dan di-version

RESTForge tidak sepenuhnya REST purist, tetapi pragmatis. Trade-off ini diambil dengan sadar karena kebutuhan praktis tim backend lebih penting daripada konformitas penuh terhadap standar REST.

Multi-Database Setara (Equal Multi-Database Support)

RESTForge mendukung tiga database dengan posisi setara, bukan satu sebagai default dan lainnya sebagai second-class citizen. Setiap database mendapat template generator dan dialect adapter tersendiri.

Database	Status	Karakteristik Spesifik
PostgreSQL	Setara	Mendukung `RETURNING`, JSONB, dan fitur lanjutan PostgreSQL
MySQL	Setara	INSERT+SELECT pattern untuk return data, charset handling
Oracle	Setara	UPPERCASE keys, native Date driver, schema awareness

Mengapa Setara, Bukan Abstraction Layer

Pendekatan umum untuk multi-database adalah membangun satu abstraction layer (ORM) yang menyeragamkan akses ke semua database. Pendekatan ini menghasilkan lowest common denominator di mana fitur spesifik setiap database hilang.

RESTForge memilih pendekatan template per database: setiap database mendapat SQL yang spesifik dan optimal. Konsekuensinya, code yang di-generate untuk PostgreSQL memanfaatkan fitur PostgreSQL secara penuh, begitu pula untuk MySQL dan Oracle.

Pendekatan	Karakteristik	Pilihan RESTForge
Single ORM Abstraction	Lowest common denominator, fitur database-specific hilang	Tidak dipilih karena mengorbankan optimasi per database
Template per Database	SQL spesifik dan optimal per database	Dipilih karena tim mendapat code yang sudah optimal

Implikasi untuk Tim

Tim dengan investasi Oracle yang besar tidak perlu migrasi ke database lain
Tim baru dapat memilih PostgreSQL atau MySQL sesuai preferensi tanpa kekhawatiran perbedaan treatment dari framework
Migrasi antar database dapat dilakukan dengan effort minimal karena perubahan hanya di level konfigurasi dan re-generate

Arsitektur & Filosofi Desain

On this page