Pelajari bagaimana microframework memungkinkan tim merakit arsitektur kustom dengan modul jelas, middleware teratur, dan batas yang tegas—termasuk trade-off, pola, dan jebakan.
Microframework adalah framework web ringan yang fokus pada hal-hal esensial: menerima request, merutekannya ke handler yang tepat, dan mengembalikan response. Berbeda dengan framework full-stack, mereka biasanya tidak menyertakan semua yang mungkin Anda butuhkan (panel admin, lapisan ORM/database, pembuat form, pekerjaan latar, alur otentikasi). Sebagai gantinya, mereka menyediakan inti kecil dan stabil dan membiarkan Anda menambahkan hanya apa yang benar-benar dibutuhkan produk Anda.
Framework full-stack seperti membeli rumah yang sudah lengkap perabotannya: konsisten dan nyaman, tetapi sulit untuk dirombak. Microframework lebih mirip ruang kosong yang kokoh secara struktural: Anda menentukan ruangan, furnitur, dan utilitasnya.
Kebebasan itulah yang kami maksud dengan arsitektur kustom—desain sistem yang dibentuk sekitar kebutuhan tim, domain Anda, dan kendala operasional. Singkatnya: Anda memilih komponen (logging, akses database, validasi, auth, pemrosesan latar) dan menentukan bagaimana mereka terhubung, bukan menerima “satu cara benar” yang sudah ditetapkan.
Tim sering memilih microframework ketika mereka menginginkan:
Kami akan fokus pada bagaimana microframework mendukung desain modular: menyusun blok bangunan, menggunakan middleware, dan menambahkan injeksi dependensi tanpa mengubah proyek menjadi eksperimen sains.
Kami tidak akan membandingkan framework tertentu baris demi baris atau mengklaim microframework selalu lebih baik. Tujuannya adalah membantu Anda memilih struktur secara sengaja—dan mengembangkannya dengan aman saat kebutuhan berubah.
Microframework bekerja paling baik ketika Anda memperlakukan aplikasi seperti kit, bukan rumah jadi. Alih-alih menerima stack yang opinionated, Anda memulai dengan inti kecil dan menambahkan kapabilitas hanya ketika benar-benar memberikan nilai.
“Inti” praktis biasanya hanya:
Itu sudah cukup untuk meluncurkan endpoint API atau halaman web yang berfungsi. Segala sesuatu lainnya bersifat opsional sampai Anda punya alasan konkret.
Saat Anda butuh otentikasi, validasi, atau logging, tambahkan sebagai komponen terpisah—sebaiknya di balik antarmuka yang jelas. Ini menjaga arsitektur tetap mudah dipahami: setiap bagian baru harus menjawab “masalah apa yang diselesaikan ini?” dan “di mana ia terpasang?”.
Contoh modul “tambahkan hanya bila perlu”:
Di awal, pilih solusi yang tidak memenjarakan Anda. Pilih pembungkus tipis dan konfigurasi daripada sihir framework yang dalam. Jika Anda dapat mengganti modul tanpa menulis ulang logika bisnis, berarti Anda melakukan hal yang benar.
Definisi selesai sederhana untuk pilihan arsitektur: tim bisa menjelaskan tujuan setiap modul, menggantinya dalam sehari atau dua, dan mengetesnya secara independen.
Microframework tetap kecil secara desain, yang berarti Anda dapat memilih “organ” aplikasi alih-alih mewarisi seluruh tubuh. Inilah yang membuat arsitektur kustom menjadi praktis: Anda bisa mulai minimal, lalu menambahkan bagian hanya saat kebutuhan nyata muncul.
Sebagian besar aplikasi berbasis microframework dimulai dengan router yang memetakan URL ke controller (atau handler yang lebih sederhana). Controller dapat diorganisir berdasarkan fitur (billing, accounts) atau berdasarkan antarmuka (web vs API), tergantung cara Anda ingin memelihara kode.
Middleware biasanya membungkus aliran request/response dan adalah tempat terbaik untuk concern lintas-cutting:
Karena middleware bersifat komposabel, Anda bisa menerapkannya secara global (semua butuh logging) atau hanya pada route tertentu (endpoint admin butuh auth lebih ketat).
Microframework jarang memaksa lapisan data, sehingga Anda bisa memilih yang sesuai dengan tim dan beban kerja:
Polanya yang baik adalah menyimpan akses data di balik repository atau lapisan service, sehingga mengganti alat nanti tidak merambat ke handler Anda.
Tidak setiap produk membutuhkan pemrosesan async di hari pertama. Saat perlu, tambahkan job runner dan antrean (pengiriman email, pemrosesan video, webhook). Perlakukan pekerjaan latar sebagai “entry point” terpisah ke logika domain Anda, berbagi service yang sama dengan lapisan HTTP daripada menduplikasi aturan.
Middleware adalah tempat microframework memberi leverage terbesar: memungkinkan Anda menangani kebutuhan lintas-cutting—hal yang harus terjadi untuk setiap request—tanpa membuat setiap route handler menjadi bengkak. Tujuannya sederhana: buat handler fokus pada logika bisnis, dan biarkan middleware menangani instalasi.
Alih-alih mengulangi cek dan header yang sama di setiap endpoint, tambahkan middleware sekali saja. Handler yang bersih lalu terlihat seperti: parse input, panggil service, kembalikan response. Semua yang lain—auth, logging, default validasi, format response—bisa terjadi sebelum atau sesudah.
Urutan adalah perilaku. Urutan umum yang dapat dibaca adalah:
Jika kompresi berjalan terlalu awal, bisa kehilangan error; jika penanganan error berjalan terlalu terlambat, Anda berisiko membocorkan stack trace atau mengembalikan format yang tidak konsisten.
X-Request-Id dan sertakan di log.{ error, message, requestId }).Kelompokkan middleware berdasarkan tujuan (observability, keamanan, parsing, shaping respons) dan terapkan pada scope yang tepat: global untuk aturan yang benar-benar universal, dan middleware grup-route untuk area spesifik (mis., /admin). Beri nama setiap middleware dengan jelas dan dokumentasikan urutan yang diharapkan di komentar singkat dekat setup agar perubahan di masa depan tidak merusak perilaku secara diam-diam.
Microframework memberi inti tipis “request masuk, response keluar.” Segala sesuatu selain itu—akses database, caching, email, API pihak ketiga—seharusnya bisa ditukar. Di situlah Inversi Kontrol (IoC) dan Injeksi Dependensi (DI) membantu, tanpa mengubah basis kode Anda menjadi eksperimen akademis.
Jika sebuah fitur butuh database, menggoda untuk membuatnya langsung di fitur itu sendiri ("new database client di sini"). Kekurangannya: setiap tempat yang “pergi belanja” kini terikat erat ke klien database tersebut.
IoC membalik itu: fitur Anda meminta apa yang dibutuhkannya, dan wiring aplikasi memberikannya. Fitur Anda jadi lebih mudah dipakai ulang dan lebih mudah diubah.
Injeksi dependensi hanya berarti meneruskan dependensi masuk alih-alih membuatnya di dalam. Dalam setup microframework, ini sering dilakukan saat startup:
Anda tidak memerlukan container DI besar untuk mendapatkan manfaat. Mulailah dengan aturan sederhana: konstruksi dependensi di satu tempat, dan teruskan ke bawah.
Untuk membuat komponen bisa saling dipertukarkan, definisikan “apa yang Anda butuhkan” sebagai interface kecil, lalu tulis adapter untuk alat spesifik.
Pola contoh:
UserRepository (interface): findById, create, listPostgresUserRepository (adapter): mengimplementasikan metode itu menggunakan PostgresInMemoryUserRepository (adapter): mengimplementasikannya untuk pengujianLogika bisnis Anda hanya mengenal UserRepository, bukan Postgres. Mengganti penyimpanan menjadi pilihan konfigurasi, bukan penulisan ulang.
Ide yang sama bekerja untuk API eksternal:
PaymentsGateway interfaceStripePaymentsGateway adapterFakePaymentsGateway untuk pengembangan lokalMicroframework membuatnya mudah tanpa sadar menyebarkan konfigurasi ke seluruh modul. Tahan diri dari itu.
Pola yang mudah dipelihara:
Ini memberi tujuan utama: tukar komponen tanpa menulis ulang aplikasi. Mengganti database, mengganti klien API, atau memperkenalkan antrean menjadi perubahan kecil di lapisan wiring—sementara sisa kode tetap stabil.
Microframework tidak memaksa “satu cara benar” untuk menyusun kode Anda. Sebaliknya, mereka memberi routing, penanganan request/response, dan sekumpulan titik ekstensi kecil—sehingga Anda dapat mengadopsi pola yang cocok dengan ukuran tim, kematangan produk, dan laju perubahan.
Ini setup “bersih dan sederhana” yang familier: controller menangani urusan HTTP, service memegang aturan bisnis, dan repository bicara ke database.
Cocok saat domain Anda sederhana, tim kecil sampai menengah, dan Anda ingin tempat-tempat yang bisa diprediksi untuk menaruh kode. Microframework mendukungnya secara alami: route memetakan ke controller, controller memanggil service, dan repository di-wiring via komposisi manual ringan.
Arsitektur hexagonal berguna ketika Anda mengharapkan sistem bertahan lebih lama dari pilihan hari ini—database, message bus, API pihak ketiga, atau bahkan UI.
Microframework bekerja baik di sini karena lapisan “adapter” seringkali adalah handler HTTP Anda plus langkah translasi tipis ke perintah domain. Port adalah interface di domain, dan adapter mengimplementasikannya (SQL, klien REST, antrean). Framework tetap berada di tepian, bukan di pusat.
Jika Anda menginginkan kejelasan ala mikroservis tanpa overhead operasional, modular monolith adalah opsi kuat. Anda tetap punya satu unit yang dapat dideploy, tetapi memisahkannya secara internal menjadi modul fitur (mis., Billing, Accounts, Notifications) dengan API publik eksplisit.
Microframework mempermudah ini karena mereka tidak meng-auto-wire segalanya: setiap modul dapat mendaftarkan route, dependensi, dan akses datanya sendiri, membuat batas terlihat dan lebih sulit dilanggar tanpa sengaja.
Di ketiga pola itu, manfaatnya sama: Anda memilih aturan—struktur folder, arah dependensi, dan batas modul—sementara microframework menyediakan permukaan kecil dan stabil untuk dihubungkan.
Microframework membuatnya mudah mulai kecil dan tetap fleksibel, tetapi mereka tidak menjawab pertanyaan besar: bentuk apa yang sebaiknya sistem Anda ambil? Pilihan yang tepat lebih bergantung pada ukuran tim, frekuensi rilis, dan seberapa menyakitkan koordinasi menjadi.
Sebuah monolit dikirim sebagai satu unit deployable. Ini sering jalur tercepat menuju produk yang bekerja: satu build, satu set log, satu tempat untuk debug.
Modular monolith tetap satu deployable, tetapi dipisah secara internal menjadi modul jelas (package, bounded context, folder fitur). Ini sering langkah “selanjutnya” terbaik saat basis kode tumbuh—terutama dengan microframework, di mana Anda bisa menjaga modul eksplisit.
Mikroservis membagi unit deployable menjadi banyak layanan. Ini bisa mengurangi coupling antar tim, tetapi juga menggandakan pekerjaan operasional.
Pisahkan ketika batas itu sudah nyata dalam pekerjaan Anda:
Hindari pemisahan ketika itu cuma demi kenyamanan ("folder ini besar") atau ketika layanan akan berbagi tabel database yang sama. Itu tanda Anda belum menemukan batas yang stabil.
API gateway dapat menyederhanakan klien (satu entry point, auth/rate limiting terpusat). Kekurangannya: bisa menjadi bottleneck dan titik kegagalan tunggal jika menjadi terlalu “pintar”.
Pustaka bersama mempercepat pengembangan (validasi umum, logging, SDK), tetapi juga menciptakan coupling tersembunyi. Jika banyak layanan harus upgrade bersama, Anda telah mereplikasi monolit terdistribusi.
Mikroservis menambah biaya berulang: lebih banyak pipeline deploy, versioning, service discovery, monitoring, tracing, respon insiden, dan rotasi on-call. Jika tim Anda tidak nyaman menjalankan mesin itu, modular monolith yang dibangun dengan komponen microframework seringkali arsitektur yang lebih aman.
Microframework memberi kebebasan, tetapi pemeliharaan harus Anda rancang. Tujuannya adalah membuat bagian “kustom” mudah ditemukan, mudah diganti, dan sulit disalahgunakan.
Pilih struktur yang bisa Anda jelaskan dalam satu menit dan tegakkan lewat code review. Satu pembagian praktis:
app/ (composition root: menghubungkan modul)modules/ (kapabilitas bisnis)transport/ (routing HTTP, pemetaan request/response)shared/ (utilitas lintas-cutting: config, logging, tipe error)tests/Jaga penamaan konsisten: folder modul gunakan kata benda (billing, users), dan entry point dapat diprediksi (index, routes, service).
Perlakukan setiap modul seperti produk kecil dengan batas jelas:
modules/users/public.ts)modules/users/internal/*)Hindari import “reach-through” seperti modules/orders/internal/db.ts dari modul lain. Jika bagian lain aplikasi membutuhkannya, promosikan ke API publik.
Bahkan layanan kecil butuh visibilitas dasar:
Letakkan ini di shared/observability sehingga setiap route handler memakai konvensi yang sama.
Buat error dapat diprediksi untuk klien dan mudah bagi manusia untuk debug. Tetapkan satu bentuk error (mis., code, message, details, requestId) dan satu pendekatan validasi (schema per endpoint). Pusatkan pemetaan dari exception internal ke respons HTTP agar handler tetap fokus pada logika bisnis.
Jika tujuan Anda bergerak cepat sambil menjaga arsitektur microframework eksplisit, Koder.ai bisa berguna sebagai alat scaffolding dan iterasi daripada pengganti desain yang baik. Anda bisa menjabarkan batas modul, tumpukan middleware, dan format error di chat, menghasilkan baseline aplikasi yang bekerja (mis., frontend React dengan backend Go + PostgreSQL), lalu menyempurnakan wiring secara sengaja.
Dua fitur yang cocok untuk kerja arsitektur kustom:
Karena Koder.ai mendukung ekspor kode sumber, Anda bisa tetap memiliki kepemilikan arsitektur dan mengembangkannya di repo Anda seperti proyek microframework buatan tangan.
Sistem berbasis microframework bisa terasa “dirakit tangan”, sehingga pengujian lebih tentang melindungi sambungan antar bagian daripada konvensi satu framework. Tujuannya adalah mendapatkan kepercayaan tanpa mengubah setiap perubahan menjadi run end-to-end penuh.
Mulailah dengan unit test untuk aturan bisnis (validasi, penetapan harga, logika izin) karena cepat dan menunjuk tepat kegagalan.
Lalu investasikan pada sejumlah integration test bernilai tinggi yang menguji wiring: routing → middleware → handler → boundary persistence. Ini menangkap bug halus yang muncul saat komponen digabung.
Middleware adalah tempat perilaku lintas-cutting bersembunyi (auth, logging, rate limit). Uji seperti pipeline:
Untuk handler, lebih baik menguji bentuk HTTP publik (status code, header, body respons) daripada panggilan fungsi internal. Ini menjaga test stabil meski internals berubah.
Gunakan injeksi dependensi (atau parameter konstruktor sederhana) untuk menukar dependensi nyata dengan fake:
Ketika banyak tim atau layanan bergantung pada API, tambahkan contract test yang mengunci ekspektasi request/response. Contract provider-side memastikan Anda tidak tanpa sengaja memutus konsumen, walau setup microframework dan modul internal berkembang.
Microframework memberi kebebasan, tetapi kebebasan tidak otomatis berarti kejelasan. Risiko utama muncul belakangan—saat tim tumbuh, basis kode meluas, dan keputusan “sementara” menjadi permanen.
Dengan lebih sedikit konvensi bawaan, dua tim bisa membangun fitur yang sama dengan gaya berbeda (routing, penanganan error, format respons, logging). Inkonsistensi itu memperlambat review dan menyulitkan onboarding.
Guardrail sederhana membantu: tulis dokumen “service template” singkat (struktur proyek, penamaan, format error, field logging) dan tegakkan dengan repo starter serta beberapa lint.
Proyek microframework sering mulai bersih, lalu mengumpulkan folder utils/ yang perlahan menjadi framework kedua. Saat modul berbagi helper, konstanta, dan state global, batas kabur dan perubahan menyebabkan breakage tak terduga.
Mending gunakan paket bersama yang eksplisit dengan versioning, atau batasi sharing: tipe, interface, dan primitif yang telah teruji. Jika helper bergantung pada aturan bisnis, besar kemungkinan ia seharusnya berada di modul domain, bukan di “utils.”
Saat Anda men-wiring otentikasi, otorisasi, validasi input, dan rate limiting secara manual, mudah melewatkan route, lupa middleware, atau hanya memvalidasi input jalur “happy path.”
Sentralisasikan default keamanan: header aman, pengecekan auth yang konsisten, dan validasi di tepi. Tambahkan tes yang memastikan endpoint terlindungi.
Lapisan middleware yang tidak direncanakan menambah overhead—terutama jika beberapa middleware melakukan parsing body, mengakses storage, atau serialisasi log.
Buat middleware kecil dan terukur. Dokumentasikan urutan standar, dan tinjau middleware baru dari sisi biaya. Jika Anda curiga terjadi pembengkakan, profiling request dan hapus langkah yang redundan.
Microframework memberi Anda opsi—tetapi opsi perlu proses pengambilan keputusan. Tujuannya bukan menemukan “arsitektur terbaik”; melainkan memilih bentuk yang tim Anda bisa bangun, operasikan, dan ubah tanpa drama.
Sebelum memilih “monolit” atau “mikroservis”, jawab ini:
Jika ragu, default ke modular monolith yang dibangun dengan microframework. Itu menjaga batas jelas sambil tetap mudah dikirim.
Microframework tidak akan menegakkan konsistensi untuk Anda, jadi pilih konvensi sejak awal:
Satu halaman “service contract” di /docs biasanya cukup.
Mulailah dengan bagian lintas-cutting yang Anda butuhkan di mana-mana:
Perlakukan ini sebagai modul bersama, bukan cuplikan yang disalin-tempel.
Arsitektur harus berubah seiring kebutuhan. Setiap kuartal, tinjau bagian mana yang memperlambat deployment, bagian yang butuh skala berbeda, dan apa yang paling sering rusak. Jika satu domain menjadi bottleneck, itu kandidat Anda untuk dipisah berikutnya—bukan seluruh sistem.
Setup microframework jarang dimulai “sepenuhnya dirancang.” Biasanya dimulai dengan satu API, satu tim, dan tenggat ketat. Nilai muncul saat produk tumbuh: fitur baru datang, lebih banyak orang menyentuh kode, dan arsitektur perlu meregang tanpa putus.
Anda mulai dengan service minimal: routing, parsing request, dan satu adapter database. Sebagian besar logika dekat endpoint karena lebih cepat dirilis.
Saat menambahkan auth, pembayaran, notifikasi, dan pelaporan, Anda memisahkannya menjadi modul (folder atau package) dengan interface publik yang jelas. Setiap modul memiliki model, aturan bisnis, dan akses data sendiri, mengekspos hanya apa yang diperlukan modul lain.
Logging, pengecekan auth, rate limiting, dan validasi request bermigrasi ke middleware sehingga setiap endpoint berperilaku konsisten. Karena urutan penting, dokumentasikan.
Dokumentasikan:
Refactor saat modul mulai saling berbagi banyak internals, waktu build melambat terasa, atau “perubahan kecil” memerlukan edit di banyak modul.
Pertimbangkan memisahkan menjadi layanan terpisah saat tim terblokir oleh deploy bersama, bagian berbeda butuh skala berbeda, atau boundary integrasi sudah berperilaku seperti produk yang terpisah.
Microframework cocok ketika Anda ingin membentuk aplikasi sekitar domain Anda daripada di sekitar stack yang ditetapkan. Mereka sangat cocok untuk tim yang menghargai kejelasan daripada kenyamanan: Anda bersedia memilih (dan memelihara) beberapa blok bangunan utama sebagai imbalan untuk basis kode yang tetap dapat dipahami saat kebutuhan berubah.
Fleksibilitas Anda hanya membayar jika Anda melindunginya dengan beberapa kebiasaan:
Mulailah dengan dua artefak ringan:
Akhirnya, dokumentasikan keputusan saat Anda membuatnya—catatan singkat saja membantu. Simpan halaman “Architecture Decisions” di repo Anda dan tinjau secara berkala agar jalan pintas kemarin tidak menjadi kendala hari ini.
Microframework berfokus pada hal-hal esensial: routing, penanganan request/response, dan titik ekstensi dasar.
Framework full-stack biasanya menyertakan banyak fitur “batteries included” (ORM, otentikasi, panel admin, form, pekerjaan latar belakang). Microframework menukar kenyamanan dengan kontrol—Anda menambahkan hanya yang Anda butuhkan dan menentukan bagaimana bagian-bagiannya terhubung.
Microframework cocok ketika Anda ingin:
“Core” terkecil yang berguna biasanya:
Mulailah dari situ, rilis satu endpoint, lalu tambahkan modul hanya saat mereka jelas memberikan manfaat (auth, validasi, observability, antrean).
Middleware paling cocok untuk concern lintas-cutting yang berlaku luas, seperti:
Biarkan handler route fokus pada logika bisnis: parse → panggil service → kembalikan response.
Urutan mengubah perilaku. Urutan yang umum dan dapat diandalkan:
Dokumentasikan urutan itu dekat kode setup agar perubahan di masa depan tidak merusak respons atau asumsi keamanan.
Inversi Kontrol berarti kode bisnis Anda tidak membangun sendiri dependensinya (tidak “pergi belanja”). Sebaliknya, wiring aplikasi yang menyediakan apa yang dibutuhkan.
Praktisnya: buat klien database, logger, dan klien API saat startup, lalu teruskan ke service/handler. Ini mengurangi coupling dan mempermudah pengujian serta penggantian implementasi.
Tidak. Anda bisa mendapatkan sebagian besar manfaat DI dengan composition root sederhana:
Tambahkan container hanya jika grafik dependensi menjadi menyulitkan untuk dikelola secara manual—jangan mulai dengan kompleksitas berlebih.
Letakkan penyimpanan dan API eksternal di balik antarmuka kecil (port), lalu buat adapter:
UserRepository interface dengan findById, create, listPostgresUserRepository untuk produksiStruktur praktis yang menjaga batas terlihat:
app/ composition root (wiring)modules/ modul fitur (kapabilitas domain)transport/ routing HTTP + pemetaan request/responseshared/ config, logging, tipe error, observabilityPrioritaskan unit test cepat untuk aturan bisnis, lalu tambahkan sejumlah integration test bernilai tinggi yang menguji pipeline lengkap (routing → middleware → handler → boundary persistence).
Gunakan DI/fake untuk mengisolasi layanan eksternal, dan uji middleware seperti pipeline (assert header, efek samping, dan perilaku blocking). Jika banyak tim bergantung pada API, tambahkan contract test untuk mencegah breaking changes.
InMemoryUserRepository untuk pengujianHandler/service bergantung pada interface, bukan implementasi konkrit. Mengganti database atau penyedia pihak ketiga menjadi masalah wiring/konfigurasi, bukan rewrite.
tests/Terapkan API publik modul (mis. modules/users/public.ts) dan hindari import “reach-through” ke internals.