Meninggalkan Postman Cloud: Cerita Migrasi ke Bruno dan Efisiensi Git-Native Workflow

Akhir-akhir ini saya merasa Postman terasa semakin cloud-centric juga semakin banyak additional-feature yang sepertinya tidak perlukan untuk sebuah API Client. Masalah utama muncul saat kolaborasi tim menjadi ribet karena batasan workspace atau batasan member untuk bergabung di organisasi Postman free tier. Sebagai engineer yang memuja efisiensi, saya mendambakan sesuatu yang bisa masuk ke dalam ekosistem yang sudah ada: Git.

Lalu, saya bertemu dengan Bruno.

Satu Request, Satu File

Hal pertama yang membuat saya terkesan pada Bruno adalah filosofinya: Offline-first dan Plain Text.

Berbeda dengan Postman yang menyimpan koleksi di dalam satu file collection.json (yang mesti di import ulang ketika ada perubahan) atau cloud mereka yang memiliki batasan member di tier gratis nya, Bruno menyimpan setiap request sebagai sebuah file dengan ekstensi .bru. Bayangkan, satu request adalah satu file teks sederhana.

Karena berbasis file dan folder, saya tidak perlu lagi berlangganan fitur cloud berbayar hanya untuk berbagi koleksi API dengan rekan setim. Saya cukup memasukkan folder koleksi tersebut ke dalam repositori Git proyek. Ingin berbagi update API terbaru? Tinggal git push. Rekan setim ingin mengambilnya? Cukup git pull.

Implementasi Single Source of Truth: OpenAPI ke Bruno

Ini adalah bagian yang paling memuaskan secara teknis. Sebagai backend engineer, saya sering menggunakan OpenAPI Spec (sebut saja berpusat di file bernama api.yml) sebagai dokumentasi utama. Masalah klasik yang sering muncul adalah: Dokumentasi di YAML sudah berubah, tapi koleksi di API Client masih versi lama.

Saya memutuskan untuk membangun sistem otomatisasi menggunakan Bruno CLI. Saya membuat sebuah repositori khusus API Collection dengan alur kerja sebagai berikut:

1. Repo Terpusat: Semua koleksi Bruno untuk berbagai layanan disimpan di sini.
2. Trigger Otomatis: Di dalam repo ini, terdapat GitHub Actions workflow yang memantau perubahan pada file api.yml (OpenAPI Spec).
3. Bruno Build: Setiap kali ada perubahan pada spesifikasi API, workflow akan menjalankan Bruno CLI untuk men-generate atau meng-update koleksi secara otomatis.

“Tidak ada lagi manual update. Jika kontrak API berubah di file YAML, maka koleksi Bruno di tim kami akan ikut berubah setelah proses CI/CD selesai.”

Kenapa Bruno Terasa “Benar” untuk Developer?

Setelah beberapa waktu bermigrasi, ada beberapa alasan mengapa transisi ini terasa sangat natural:

• Git-Friendly (Truly): Karena formatnya teks, saat melakukan code review, saya bisa melihat dengan jelas perubahan apa yang terjadi pada sebuah API (misal: perubahan header atau penambahan parameter) langsung melalui diff di GitHub/GitLab.
• Ringan: Bruno tidak mencoba menjadi segalanya. Ia fokus menjadi API Client yang cepat tanpa bloatware.
• Kolaborasi Tanpa Biaya Tambahan: Selama tim kalian menggunakan Git, kalian sudah memiliki kolaborasi “cloud” secara gratis.
• Scripting yang Fleat: Dukungan terhadap JavaScript untuk pre-request dan post-response tetap ada, sehingga transisi dari Postman terasa sangat familiar.

Penutup: Kembali ke Dasar

Perjalanan berpindah ke Bruno mengajarkan saya bahwa terkadang, solusi terbaik bukanlah alat dengan fitur paling banyak, melainkan alat yang paling baik berintegrasi dengan alur kerja kita. Dengan mengembalikan kontrol koleksi API ke tangan Git, saya tidak hanya menghemat biaya operasional, tapi juga memastikan bahwa knowledge base API kami selalu sinkron dengan kode sumber.

Bagi yang ingin mencoba pendekatan Git-friendly dalam mengelola API, Bruno bisa menjadi opsi yang menarik untuk dieksplorasi. Dokumentasi lengkapnya bisa diakses disini