BaaS (Backend-as-a-Service): Kelebihan dan Risiko Masa Depan

Kalo lo udah pernah pake firebase untuk membuat projek aplikasi, berarti lo udah nerapin BaaS (Backend-as-a-Service).

  • Lo ga perlu pusing soal Authentication
  • Semua logic ada di frontend
  • ga perlu setup dan manajemen server

Kehebatan BaaS ini yang jadi andalan. Kalo lo tanya ke AI, sebagian besar pasti nyaranin metode ini, karena ia pikir ini solusi terbaik dan tercepat—memang benar tapi lo perlu pikir lagi deh.

Provider BaaS

Sebelum bahas jauh, mari kita bahas provider apa aja yang tersedia. Masing-masing provider punya kelebihan, disini kita bahas sekilas saja.

Firebase pilihan populer saat ini, lo ga perlu setup server, database sampe logic authentication, karena firebase udah punya lengkap semua fitur itu semua. Aplikasi lo ga butuh waktu lama untuk selesai, dan user lo ga butuh waktu lama buat belajar.

Kalo ga suka provider perusahaan gede (google), lo bisa pakai alternatif remoteStorage. Projek open source untuk integrasi aplikasi lo ke server mereka, atau install di server lo sendiri. Bahkan remoteStorage beri user opsi untuk simpan data di dropbox atau Google Drive. Dengan begitu, user lo memegang data dia sendiri.

Gimana dengan vercel? lo bisa deploy aplikasi, tapi datanya simpan dimana? vercel nyediain database untuk siap pakai. Tapi ini gue pikir bukan BaaS karena masih logic dari aplikasi jalan di server, bukan di client.

Perbedaan BaaS dengan lainnya adalah semua proses logic ada di client (browser atau aplikasi).

Provider lainnya adalah Supabase, menyediakan Postgresql-as-a-service sekaligus menyediakan authentication. Mirip BaaS tapi logic dari aplikasi lo tetap di server, tapi walaupun bisa di frontend lo perlu bikin pondasi arsitektur kepemilikan data per-user sendiri.

Kita udah liat banyak provider yang nyediain BaaS tapi mana yang cocok untuk projek lo?

Keunggulan: Fokus di Client, No Backend

BaaS mengedepankan no-backend, artinya seluruh logic ada di client. Mirip aplikasi bawaan OS, file management misalnya yang mana seluruh proses ada di ruang user, bukan di server.

Client disini bisa berupa aplikasi-di-install atau aplikasi-di-browser. Walaupun begitu, user sekarang pengen data bisa di akses dari device lainnya, maka dibutuhkan penyimpanan cloud untuk tetap sinkronisasi di beberapa device lainnya.

BaaS biasanya punya fitur:

  • Cloud Storage: penyimpanan data di cloud
  • Authentication/Authorization: mudah untuk register, login, forget password dan lain-lain.
  • Manajemen akun dilakukan di provider akun sendiri, aplikasi fokus pada fiturnya saja
  • Offline-first, aplikasi bisa jalan bahkan tanpa internet. Aplikasi akan melakukan sinkronisasi saat sudah ada akses internet.

Bagi developer Front-end ga perlu belajar Backend, manajemen akun dan reset password ga perlu dipikirin lagi. Semua proses dan logic ada di client. User memegang data dan alur dari aplikasi itu sendiri.

Masalah dari metode ini adalah, logic client yang kompleks. Aplikasi Notepad ga butuh permission yang kompleks, tetapi kalo aplikasi bisnis (mirip ERP) butuh permission yang sangat kompleks. Siapa-bisa-akses-apa dilakukan diserver, sebelum user menerima data.

Selain kompleks, juga beresiko secara keamanan karena user punya akses terhadap logic di client. Maka beberapa provider menyediakan pembatasan akses lewat server—tetap saja menyentuh server tapi lebih minim.

No-Backend menjadi kelebihan sekaligus kelemahan dari metode ini.

Apakah cocok untuk Prototyping?

Jika dilihat sekilas, lo bakal mikir cocok untuk prototyping karena iterasi yang cepat dan mudah dikembangkan. Tetapi, ada biaya besar yang harus dibayar nantinya.

Jika projek berkembang menjadi lebih besar, dan membutuhkan hak akses dan logika yang kompleks. Maka, akan ada titik dimana perlu melakukan migrasi besar-besaran ke solusi lain. Risiko ini perlu diperhatikan jika lo berencana ngembangin jadi lebih gede. Apakah mau membayar risiko ini?

Lalu aplikasi apa yang cocok?, aplikasi user-oriented. Aplikasi yang sederhana, simpel, dan alternatif dari spreadsheet. Aplikasi ini ga akan scale-up karena tujuan dari aplikasi sudah terpenuhi, Misalnya:

  • Aplikasi note-taking
  • Aplikasi invoicing
  • Aplikasi habbit tracker

Aplikasi diatas ga perlu hak akses yang rumit, setiap user punya datanya masing-masing, minim digunakan bersama. Aplikasi diatas cocok pake BaaS karena pengembangan mudah, cepat dan ga perlu setup server.

Kesimpulan

Kalo lo ngembangin aplikasi, apalagi pake AI. Pikir-pikir dulu solusi yang akan dipakai, dan solusi AI juga jangan diambil mentah-mentah. BaaS cocok untuk aplikasi yang ga butuh hak akses yang kompleks, mecahin masalah pengguna, dan lo ga perlu pusing soal database, server dan lain-lain. Tinggal bikin logic aplikasi dan deploy siap pakai. Gue pikir ini cocok untuk beberapa kasus, tapi jadi petaka kalau ga pikir matang-matang.

Sekian dari gue, terima kasih.

  1. Djembar Arafat as Djembara

    Cukup menarik, kebetulan saya sedang memakainya untuk membuat ecommerce pribadi, untuk menjual source code maupun SaaS saya. Karena saya saat ini ingin menerapkan No cost (Modal domain saja) Saya menerapkan BaaS tersebut dan deploy menggunakan vercel.

    Ijin tanya mas, saran buat kedepannya masa depan project saya ini, memang buat pribadi, tapi saya ada kepikiran untuk nanti kedepannya kalo project saya berkembang, saya ingin menerapkan backend dan VPS manual. Apakah memungkinka atau migrasinya bisa dibilang sulit?

    1. riochndr

      BaaS memang cocok untuk projek dengan low-cost, minim biaya dan maintenance. Tapi kekurangan BaaS adalah vendor lock-in, untuk migrasi dengan biaya murah perlu punya backend/server yang mirip dengan BaaS yang dipakai. Sedangkan kalau bikin backend custom sendiri, perlu update kode frontend juga dan itu butuh waktu dan biaya ga sedikit.

Add a comment

Subscribe now!