Typebase: Backend Cukup Satu Folder TypeScript, Tanpa Boilerplate REST

Developer frontend sering frustrasi dengan jarak antara kode yang mereka tulis dan backend yang harus mereka panggil. REST API butuh endpoint, controller, serializer, dokumentasi, dan penanganan error yang semuanya harus dijaga konsisten dengan tipe data di frontend. Kalau ada satu field berubah di database, perubahannya merambat ke banyak file. Typebase hadir dengan jawaban yang berbeda: backend adalah satu folder TypeScript, dan frontend memanggilnya seperti fungsi lokal.

Proyek ini muncul sebagai Show HN dan langsung menarik perhatian developer yang lelah dengan boilerplate. Artikel ini membahas cara kerja Typebase, apa yang membuatnya menarik, kapan cocok dipakai, dan kapan sebaiknya dihindari.

Apa Itu Typebase?

Typebase adalah framework backend yang mengambil pendekatan "folder-centric". Alih-alih mendefinisikan API lewat route, controller, dan schema terpisah, developer cukup membuat folder typebase/ di dalam aplikasi dan menulis tiga jenis file TypeScript:

• Actions — fungsi-fungsi yang bisa dipanggil dari frontend, berisi logika bisnis.
• Database schema — definisi skema database dalam TypeScript.
• Auth — konfigurasi autentikasi.

Frontend kemudian memanggil actions tersebut seperti memanggil fungsi lokal, dengan type safety end-to-end dari database sampai komponen UI. Tidak ada REST boilerplate, tidak ada endpoint yang harus didokumentasikan manual, tidak ada mismatch tipe antara frontend dan backend.

Filosofi ini mirip dengan server actions di framework modern seperti Next.js, tapi Typebase membawanya lebih jauh dengan mencakup database schema dan auth dalam satu sistem yang terintegrasi, dan dirancang agar bisa dipakai di berbagai framework (Next.js, SvelteKit, Nuxt, Expo) sekaligus.

Bagaimana Cara Kerjanya?

Alih-alih membangun routing HTTP manual, Typebase memanfaatkan tooling yang sudah ada di ekosistem TypeScript. Di balik layar, ia menggabungkan beberapa library yang sudah matang:

• oRPC — untuk mendefinisikan dan memanggil prosedur remote dengan type safety.
• Drizzle ORM — untuk skema database dan query, dengan dukungan TypeScript yang kuat.
• better-auth — untuk autentikasi, lengkap dengan session dan provider.

Dengan kombinasi ini, developer menulis skema sekali dalam TypeScript, dan Typebase menurunkan tipe-tipenya ke seluruh stack. Perubahan di skema database langsung tercermin di tipe yang dipakai frontend. Kalau ada field yang dihapus, TypeScript compiler langsung berteriak di frontend, bukan di produksi.

Ini adalah contoh nyata dari konsep end-to-end typed: satu sumber kebenaran untuk tipe data, dan compiler yang menjaga semuanya tetap sinkron.

Kenapa Ini Menarik untuk Developer?

Ada beberapa alasan Typebase menarik perhatian developer, terutama yang bekerja di tim kecil atau solo:

1. Produktivitas naik drastis. Tanpa boilerplate REST, fitur baru bisa selesai lebih cepat. Tulis action, panggil dari frontend, selesai. Tidak ada layer yang harus dijaga konsisten secara manual.

2. Type safety end-to-end. Mismatch tipe antara frontend dan backend adalah salah satu sumber bug paling umum di aplikasi web. Dengan Typebase, sebagian besar kelas bug ini hilang karena compiler memeriksa semuanya.

3. AI-friendly. Tagline Typebase menyebut "AI loves code", dan ini bukan sekadar marketing. Untuk AI coding assistant, kode yang terpusat di satu folder dengan tipe yang jelas jauh lebih mudah dipahami dan dimodifikasi dibandingkan codebase REST yang tersebar di banyak file dengan konvensi implisit.

4. Satu bahasa di seluruh stack. Frontend dan backend sama-sama TypeScript. Developer fullstack tidak perlu berpindah konteks bahasa, dan tim kecil tidak perlu merekrut spesialis backend terpisah untuk proyek sederhana.

Kapan Typebase Cocok Dipakai?

Typebase paling cocok untuk proyek dengan karakteristik berikut:

• Aplikasi internal dan MVP — kecepatan pengembangan lebih penting daripada fleksibilitas arsitektur jangka panjang.
• Tim kecil atau solo developer — tim yang butuh produktivitas maksimal dengan overhead minimal.
• Proyek dengan model data yang jelas — aplikasi CRUD, dashboard, tools internal, marketplace sederhana.
• Prototipe yang kemungkinan besar tumbuh — mulai cepat dengan Typebase, dan arsitektur yang rapi tetap bisa dievolusi.

Untuk proyek seperti ini, menghindari boilerplate REST bisa menghemat puluhan jam pengembangan di minggu-minggu pertama.

Kapan Sebaiknya Berpikir Dua Kali?

Ada juga skenario di mana pendekatan ini perlu dipertimbangkan lebih hati-hati:

1. Aplikasi dengan API publik. Kalau Anda perlu membuka API untuk pihak ketiga, REST atau GraphQL dengan dokumentasi formal tetap lebih tepat. Konsumen eksternal butuh kontrak API yang stabil dan terdokumentasi, bukan fungsi internal yang berubah sesuka hati.

2. Arsitektur microservices. Typebase dirancang untuk aplikasi monolit yang kohesif. Kalau tim Anda butuh memecah layanan secara fisik, kontrak API eksplisit antar service tetap diperlukan.

3. Tim besar dengan banyak kontributor. Di tim besar, batas-batas yang eksplisit (endpoint, schema, kontrak) membantu koordinasi. Semakin banyak orang, semakin berharga struktur yang eksplisit.

4. Kebutuhan non-standar. WebSocket real-time dengan pola komunikasi kompleks, streaming besar, atau integrasi dengan sistem eksternal yang butuh kontrol HTTP penuh mungkin terasa dibatasi.

Intinya, Typebase mengoptimalkan kecepatan dan kesederhanaan, dan seperti semua trade-off, ada harga yang dibayar dalam fleksibilitas dan eksplisititas.

Membandingkan dengan Pendekatan Lain

Typebase bukan satu-satunya yang mencoba menghapus boilerplate API. Framework seperti tRPC sudah populer dengan konsep serupa untuk TypeScript fullstack. Perbedaannya, Typebase lebih terintegrasi: ia menyertakan skema database dan auth sebagai bagian dari folder yang sama, bukan hanya lapisan API. Sementara itu, server actions di Next.js juga menawarkan fungsi yang dipanggil dari komponen, tapi lebih terikat pada ekosistem Next.js.

Pilihan di antara pendekatan-pendekatan ini sebaiknya didasarkan pada kebutuhan spesifik: framework apa yang dipakai tim, seberapa besar API publik yang dibutuhkan, dan seberapa penting portabilitas antar framework.

Memulai dengan Typebase

Kalau tertarik mencoba, langkah awal yang disarankan adalah membuat proyek kecil: aplikasi todo list atau CRUD sederhana dengan beberapa entitas yang saling berelasi. Tujuannya bukan membangun produk, tapi merasakan workflow-nya: menulis skema, membuat action, memanggil dari frontend, dan melihat bagaimana perubahan tipe merambat ke seluruh stack.

Perhatikan beberapa hal saat mengevaluasi:

• Developer experience — seberapa cepat Anda bisa menulis fitur pertama dibandingkan workflow REST biasa? Catat waktu aktualnya, bukan perasaan.
• Error handling — bagaimana error di action dikomunikasikan ke frontend? Apakah type-safe dan mudah ditangani?
• Deployment — bagaimana aplikasi Typebase di-deploy? Apakah cocok dengan infrastruktur yang sudah ada (VPS, container, serverless)?
• Ekosistem — seberapa aktif komunitasnya, seberapa cepat isu dijawab, dan seberapa lengkap dokumentasinya?

Evaluasi semacam ini lebih jujur daripada membaca testimoni di landing page. Tool yang bagus untuk workload Anda akan terasa bagus dalam dua jam pertama pemakaian, bukan hanya di demo.

Masa Depan Backend Tanpa Boilerplate

Typebase adalah bagian dari gerakan yang lebih besar menuju pengembangan yang lebih langsung: mengurangi jumlah lapisan abstraksi yang harus dijaga developer. Server actions di Next.js, tRPC, dan framework seperti Remix semuanya bergerak ke arah yang sama, meski dengan filosofi berbeda.

Pertanyaannya bukan apakah pendekatan ini akan bertahan, tapi bagaimana ia berevolusi. Kemungkinan besar kita akan melihat konsolidasi: pola end-to-end typed menjadi standar untuk aplikasi internal, sementara API publik tetap memakai kontrak eksplisit. Developer yang memahami kedua dunia ini, kapan memakai yang mana, akan punya keunggulan.

Yang perlu diingat, tidak ada tool yang menghapus kebutuhan memahami fundamental. Typebase menghapus boilerplate, tapi logika bisnis, desain database, keamanan, dan skalabilitas tetap tanggung jawab developer. Tool yang baik mempermudah, bukan menggantikan pemikiran.

Typebase vs Pendekatan Konvensional: Kapan Beralih

Keputusan untuk beralih dari REST konvensional ke pendekatan seperti Typebase sebaiknya tidak diambil berdasarkan preferensi pribadi, tapi berdasarkan karakteristik proyek. Beberapa sinyal bahwa Anda mungkin siap beralih:

• Kelelahan boilerplate — Anda menghabiskan lebih banyak waktu menulis endpoint, serializer, dan dokumentasi daripada logika bisnis.
• Sering ada mismatch tipe — bug yang muncul karena field berubah di backend tapi tidak di frontend, atau sebaliknya.
• Tim kecil — dengan tim 1-3 developer, overhead koordinasi kontrak API terasa tidak proporsional dengan ukuran proyek.
• Aplikasi internal — tidak ada konsumen eksternal yang butuh dokumentasi API formal.

Sinyal sebaliknya, bahwa Anda sebaiknya bertahan dengan pendekatan konvensional: API publik yang dipakai pihak ketiga, tim besar dengan banyak kontributor, kebutuhan integrasi dengan sistem non-TypeScript, atau arsitektur yang harus mendukung banyak bahasa pemrograman.

Tidak ada jawaban universal. Yang penting adalah membuat keputusan berdasarkan kebutuhan nyata, bukan mengikuti tren. Evaluasi berkala: tanyakan pada diri sendiri apakah biaya boilerplate saat ini lebih besar daripada biaya migrasi ke pendekatan baru.

Sebagai penutup area ini, perlu ditegaskan bahwa tools seperti Typebase tidak menghilangkan kebutuhan akan pemahaman HTTP, database, atau keamanan. Yang dihilangkan adalah kerumitan yang tidak perlu. Developer yang memahami fondasi tetap bisa memakai Typebase secara efektif, dan ketika kebutuhan melampaui kapasitas tool, mereka tahu persis ke mana harus melangkah karena fondasinya tetap sama.

Pada akhirnya, pilihan tool adalah pilihan trade-off, dan trade-off yang tepat bergantung pada konteks. Coba, ukur, dan putuskan berdasarkan data. Itu cara terbaik memanfaatkan gelombang inovasi tanpa tenggelam di dalamnya.

Dan kalau suatu saat Typebase tidak lagi cocok, investasi belajarnya tidak sia-sia: konsep end-to-end typed, skema sebagai sumber kebenaran, dan fungsi sebagai antarmuka akan tetap relevan di tool lain yang datang kemudian.

Kesimpulan

Typebase mewakili arah yang menarik dalam pengembangan web: menghapus lapisan yang tidak perlu dengan mengandalkan kekuatan type system TypeScript. Untuk developer yang membangun aplikasi internal, MVP, atau produk dengan tim kecil, pendekatan "backend satu folder" ini bisa menjadi penghemat waktu yang signifikan.

Seperti semua tool baru, keputusan terbaik datang dari eksperimen: coba di proyek kecil, ukur produktivitasnya, dan bandingkan dengan workflow yang selama ini dipakai. Kalau cocok, Typebase bisa mengubah cara Anda membangun backend; kalau tidak, setidaknya Anda belajar trade-off dari pendekatan end-to-end typed.

Yang jelas, tren menghapus boilerplate tidak akan berhenti di sini. Semakin matang ekosistem TypeScript, semakin banyak tool yang akan mencoba menjembatani jarak antara frontend dan backend. Dan developer yang terbiasa mengevaluasi tool baru dengan kritis akan selalu punya keunggulan.