Pengujian kontrak untuk API: cegah perubahan yang merusak di tim yang cepat

Mengapa perubahan API yang merusak terus lolos ke rilis

Kebanyakan tim akhirnya punya satu API yang melayani banyak klien: web, iOS, Android, dan kadang alat internal juga. Meskipun semua setuju dengan endpoint “yang sama”, tiap klien mengandalkan API dengan cara sedikit berbeda. Satu layar mungkin mengharapkan sebuah field selalu ada, sementara yang lain hanya menggunakannya saat filter diterapkan.

Masalah nyata muncul ketika bagian-bagian ini dirilis dengan jadwal berbeda. Backend bisa berubah beberapa kali sehari, web deploy cepat, sedangkan rilis mobile lebih lambat karena proses review dan rollout bertahap. Kesenjangan itu menciptakan kejutan: API diperbarui untuk klien terbaru, tapi build mobile kemarin masih beredar dan sekarang menerima respons yang tidak bisa ditangani.

Gejalanya biasanya tidak halus:

• Layar yang tiba-tiba kosong karena sebuah field diganti nama atau dipindah
• Crash disebabkan oleh null atau objek yang hilang
• Tiket dukungan “ada yang rusak” dengan langkah yang sulit direproduksi
• Lonjakan di log error segera setelah deploy backend
• Rilis hotfix yang menambahkan kode defensif alih-alih memperbaiki akar masalah

Pengujian manual dan QA sering melewatkan masalah ini karena kasus berisiko bukanlah jalur bahagia. Tester mungkin memverifikasi bahwa “Buat pesanan” berfungsi, tapi tidak mencoba versi aplikasi yang lebih lama, profil yang terisi sebagian, peran pengguna yang jarang, atau respons di mana daftar kosong. Tambahkan caching, feature flag, dan rollout bertahap, dan Anda mendapatkan lebih banyak kombinasi daripada yang bisa dicakup rencana pengujian.

Contoh khas: backend mengganti status: \"approved\" dengan status: { code: \"approved\" } untuk dukungan lokalisasi. Web diperbarui hari yang sama dan terlihat baik. Tapi rilis iOS saat ini masih mengharapkan string, gagal mem-parse respons, dan pengguna melihat halaman kosong setelah login.

Di sinilah pengujian kontrak API berguna: bukan untuk menggantikan QA, tapi untuk menangkap perubahan “berfungsi untuk klien terbaru saya” sebelum mencapai produksi.

Apa itu pengujian kontrak (dan apa bukan)

Pengujian kontrak adalah cara bagi konsumen API (web, mobile, atau layanan lain) dan penyedia API (backend) untuk menyepakati bagaimana mereka akan berkomunikasi. Kesepakatan itu adalah kontrak. Tes kontrak memeriksa satu hal sederhana: apakah penyedia masih berperilaku seperti yang diandalkan konsumen, setelah perubahan?

Dalam praktiknya, pengujian kontrak berada di antara unit test dan end-to-end test. Unit test cepat dan lokal, tapi bisa melewatkan ketidakcocokan antar tim karena mereka menguji kode internal, bukan batas yang dibagi. End-to-end menguji alur nyata di banyak sistem, tapi lebih lambat, sulit dipelihara, dan sering gagal karena alasan yang tidak terkait perubahan API (data test, timing UI, lingkungan flaky).

Kontrak bukan dokumen besar. Ia adalah deskripsi fokus tentang request yang akan dikirim konsumen dan respons yang harus diterima balik. Kontrak yang baik biasanya mencakup:

• Endpoint dan method (mis. POST /orders)
• Field wajib dan opsional, termasuk tipe dan aturan dasar
• Status code dan bentuk respons error (seperti 400 vs 404)
• Header dan ekspektasi auth (token hadir, content type)
• Default penting dan aturan kompatibilitas (apa yang terjadi jika field hilang)

Contoh sederhana jenis break yang ditangkap tes kontrak lebih awal: backend mengganti total_price menjadi totalPrice. Unit test masih bisa lulus. End-to-end mungkin tidak menutup layar itu atau gagal kemudian dengan cara yang membingungkan. Tes kontrak gagal segera dan menunjuk ketidakcocokan yang tepat.

Perjelas juga apa yang bukan tujuan pengujian kontrak. Ia tidak menggantikan pengujian performa, keamanan, atau alur pengguna penuh. Ia juga tidak akan menangkap setiap bug logika. Yang dilakukannya adalah mengurangi risiko rilis paling umum di tim yang cepat: perubahan API “kecil” yang diam-diam merusak klien.

Jika backend Anda sering digenerate atau berubah cepat (mis. saat meregenerasi API di platform seperti AppMaster), tes kontrak adalah jaring pengaman praktis karena mereka memverifikasi bahwa ekspektasi klien tetap terpenuhi setelah setiap perubahan.

Pilih pendekatan kontrak untuk tim web dan mobile

Saat web dan mobile sering dirilis, bagian tersulit bukanlah “menguji API”. Melainkan menyepakati apa yang tidak boleh berubah untuk tiap klien. Di sinilah pengujian kontrak membantu, tapi Anda tetap harus memilih siapa yang memiliki kontrak.

Opsi 1: Consumer-driven contracts (CDC)

Dengan consumer-driven contracts, tiap klien (web, iOS, Android, partner) mendefinisikan apa yang mereka butuhkan dari API. Penyedia kemudian membuktikan bahwa mereka bisa memenuhi ekspektasi itu.

Ini cocok ketika klien bergerak secara independen, karena kontrak mencerminkan penggunaan nyata, bukan apa yang dipikirkan tim backend. Ini juga sesuai dengan realitas multi-klien: iOS mungkin bergantung pada field yang tidak dipakai web, dan web mungkin peduli aturan sorting atau pagination yang mobile abaikan.

Contoh sederhana: aplikasi mobile mengandalkan price_cents sebagai integer. Web hanya menampilkan harga terformat, jadi tidak akan menyadari jika backend mengubahnya menjadi string. CDC dari mobile akan menangkap perubahan itu sebelum rilis.

Opsi 2: Skema yang dimiliki provider

Dengan skema milik provider, tim backend menerbitkan satu kontrak (sering berupa skema atau spesifikasi) dan menegakkannya. Konsumen menguji terhadap satu sumber kebenaran itu.

Ini cocok saat API bersifat publik atau dibagi ke banyak konsumen yang tidak Anda kontrol, atau saat Anda butuh konsistensi ketat antar tim. Ini juga lebih sederhana untuk memulai: satu kontrak, satu tempat untuk review perubahan, satu jalur persetujuan.

Cara memilih cepat:

• Pilih CDC saat klien sering dirilis dan memakai potongan berbeda dari API.
• Pilih skema milik provider saat Anda butuh satu kontrak “resmi” yang stabil untuk semua.
• Gunakan hybrid ketika memungkinkan: skema provider untuk baseline, plus CDC untuk endpoint berisiko tinggi.

Jika Anda membangun dengan platform seperti AppMaster, ide yang sama berlaku: perlakukan web dan native mobile sebagai konsumen terpisah. Meskipun mereka berbagi backend, mereka jarang bergantung pada field dan aturan yang persis sama.

Apa yang dimasukkan ke dalam kontrak API (supaya menangkap break nyata)

Kontrak API hanya membantu jika mencerminkan apa yang benar-benar diandalkan web dan mobile. Spesifikasi cantik yang tidak dipakai tidak akan menangkap perubahan yang merusak produksi.

Mulai dari penggunaan nyata, bukan tebakan. Ambil panggilan klien yang paling umum (dari kode aplikasi, log gateway API, atau daftar singkat dari tim) dan ubah menjadi kasus kontrak: path, method, header, query param, dan bentuk body request yang tipikal. Ini membuat kontrak kecil, relevan, dan sulit diperdebatkan.

Sertakan respons sukses dan gagal. Tim sering menguji jalur bahagia dan lupa bahwa klien juga bergantung pada error: status code, bentuk error, bahkan kode/pesan error yang stabil. Jika aplikasi mobile menampilkan pesan “email sudah dipakai”, kontrak harus mengunci bentuk respons 409 agar tidak tiba-tiba berubah menjadi 400 dengan body berbeda.

Perhatikan ekstra area yang sering rusak:

• Field opsional vs wajib: menghapus field biasanya lebih aman daripada membuat field opsional menjadi wajib.
• Null: beberapa klien memperlakukan null berbeda dengan “hilang”. Putuskan apa yang diizinkan dan jaga konsistensi.
• Enum: menambahkan nilai baru bisa memecah klien lama yang menganggap daftar tertutup.
• Pagination: sepakati parameter dan field respons (seperti cursor atau nextPageToken) dan jaga stabilitasnya.
• Format tanggal dan angka: buat eksplisit (ISO strings, cents sebagai integer, dll.).

Cara merepresentasikan kontrak

Pilih format yang bisa dibaca tim dan divalidasi oleh tooling. Opsi umum adalah JSON Schema, kontrak berbasis contoh, atau model bertipe yang digenerate dari spesifikasi OpenAPI. Dalam praktiknya, contoh plus pemeriksaan skema bekerja baik: contoh menunjukkan payload nyata, sedangkan aturan skema menangkap kesalahan seperti “field diganti nama” atau “tipe berubah”.

Aturan sederhana: jika sebuah perubahan memaksa klien untuk diperbarui, perubahan itu harus membuat tes kontrak gagal. Pola pikir itu menjaga kontrak fokus pada break nyata, bukan kesempurnaan teoretis.

Langkah demi langkah: tambahkan tes kontrak ke pipeline CI Anda

Tujuan pengujian kontrak API sederhana: saat seseorang mengubah API, CI Anda harus memberi tahu apakah web atau mobile akan rusak sebelum perubahan itu dikirim.

1) Mulai dengan menangkap apa yang benar-benar diandalkan klien

Pilih satu endpoint dan catat ekspektasi yang penting dalam penggunaan nyata: field wajib, tipe field, nilai yang diizinkan, status code, dan respons error umum. Jangan coba deskripsikan seluruh API sekaligus. Untuk aplikasi mobile, sertakan ekspektasi “versi app yang lebih lama” juga, karena pengguna tidak selalu memperbarui segera.

Cara praktis: ambil beberapa request nyata yang dibuat klien hari ini (dari log atau fixture test) dan ubah menjadi contoh yang dapat diulang.

2) Letakkan kontrak di tempat yang mudah dipelihara tim

Kontrak gagal ketika mereka berada di folder terlupakan. Simpan dekat dengan kode yang berubah:

• Jika satu tim menguasai kedua sisi, simpan kontrak di repo API.
• Jika tim berbeda menguasai web, mobile, dan API, gunakan repo bersama yang dimiliki tim, bukan satu orang.
• Perlakukan pembaruan kontrak seperti kode: direview, versioned, dan didiskusikan.

3) Tambahkan pemeriksaan di kedua sisi di CI

Anda ingin dua sinyal:

• Verifikasi provider di tiap build API: “Apakah API masih memenuhi semua kontrak yang diketahui?”
• Pemeriksaan konsumen di tiap build klien: “Apakah klien ini masih kompatibel dengan kontrak yang dipublikasikan terakhir?”

Ini menangkap masalah dari kedua arah. Jika API mengubah field respons, pipeline API gagal. Jika klien mulai mengharapkan field baru, pipeline klien gagal sampai API mendukungnya.

4) Putuskan aturan gagal dan tegakkan

Jelas tentang apa yang memblokir merge atau rilis. Aturan umum: setiap perubahan yang memecah kontrak membuat CI gagal dan memblokir merge ke main. Jika butuh pengecualian, minta keputusan tertulis (mis. tanggal rilis terkoordinasi).

Contoh konkret: backend mengganti totalPrice menjadi total_amount. Verifikasi provider gagal segera, sehingga tim backend menambahkan field baru sambil mempertahankan yang lama untuk masa transisi, dan web serta mobile tetap bisa rilis aman.

Versioning dan kompatibilitas mundur tanpa memperlambat tim

Tim cepat paling sering memecah API dengan mengubah apa yang sudah diandalkan klien. “Breaking change” adalah apa pun yang membuat request yang sebelumnya bekerja menjadi gagal, atau membuat respons berbeda secara bermakna sehingga klien tidak bisa menanganinya.

Berikut perubahan umum yang memecah (meskipun endpoint masih ada):

• Menghapus field respons yang dibaca klien
• Mengubah tipe field (mis. "total": "12" menjadi "total": 12)
• Mengubah field opsional menjadi wajib (atau menambahkan field request wajib baru)
• Mengubah aturan auth (endpoint publik kini butuh token)
• Mengubah status code atau bentuk error yang diparse klien (200 menjadi 204, atau format error baru)

Kebanyakan tim bisa menghindari bump versi dengan memilih alternatif yang lebih aman. Jika butuh data lebih, tambahkan field baru daripada mengganti nama. Jika butuh endpoint baru, tambahkan route baru dan biarkan route lama tetap bekerja. Jika perlu mengetatkan validasi, terima input lama dan baru untuk sementara, lalu tegakkan aturan baru secara bertahap. Tes kontrak membantu karena memaksa Anda membuktikan konsumen lama masih mendapatkan yang diharapkan.

Deprecation adalah bagian yang menjaga kecepatan tanpa menyakiti pengguna. Klien web bisa update harian, tapi mobile bisa tertinggal berminggu-minggu karena antrian review dan adopsi yang lambat. Rencanakan deprecasi berdasarkan perilaku klien nyata, bukan harapan.

Kebijakan deprecasi praktis terlihat seperti ini:

• Umumkan perubahan lebih awal (catatan rilis, channel internal, tiket)
• Pertahankan perilaku lama sampai penggunaan turun di bawah ambang yang disepakati
• Kembalikan peringatan di header/log saat path terdepresiasi dipakai
• Tetapkan tanggal penghapusan hanya setelah memastikan sebagian besar klien telah upgrade
• Hapus perilaku lama hanya setelah tes kontrak menunjukkan tidak ada konsumen aktif yang masih membutuhkannya

Gunakan versioning eksplisit hanya ketika Anda tidak bisa membuat perubahan kompatibel mundur (mis. perubahan fundamental pada bentuk resource atau model keamanan). Versioning menambah biaya jangka panjang: sekarang Anda memelihara dua perilaku, dua set dokumentasi, dan lebih banyak edge case. Simpan versi jarang dan disengaja, dan gunakan kontrak untuk memastikan kedua versi jujur sampai yang lama benar-benar aman untuk dihilangkan.

Kesalahan umum dalam pengujian kontrak (dan cara menghindarinya)

Pengujian kontrak bekerja terbaik saat memeriksa ekspektasi nyata, bukan versi main-main dari sistem Anda. Sebagian besar kegagalan datang dari beberapa pola yang bisa diprediksi yang membuat tim merasa aman sementara bug masih lolos ke produksi.

Kesalahan 1: Menganggap kontrak seperti "mock keren"

Over-mocking adalah jebakan klasik: tes kontrak lulus karena perilaku provider dimock agar sesuai kontrak, bukan karena layanan nyata benar-benar bisa melakukannya. Saat deploy, panggilan nyata pertama gagal.

Aturan yang lebih aman: kontrak harus diverifikasi terhadap provider yang berjalan (atau artefak build yang berperilaku sama), dengan serialisasi nyata, validasi nyata, dan aturan auth nyata.

Berikut kesalahan yang sering muncul, dan perbaikan yang biasanya bertahan:

• Over-mocking perilaku provider: verifikasi kontrak terhadap build provider nyata, bukan service stub.
• Membuat kontrak terlalu ketat: gunakan pencocokan fleksibel untuk ID, timestamp, dan array; hindari meng-assert setiap field jika klien tidak bergantung padanya.
• Mengabaikan respons error: uji setidaknya kasus error utama (401, 403, 404, 409, 422, 500) dan bentuk body error yang diparse klien.
• Tidak ada kepemilikan yang jelas: tentukan siapa yang memperbarui kontrak saat persyaratan berubah; jadikan itu bagian dari “definition of done” untuk perubahan API.
• Melupakan realitas mobile: uji dengan jaringan lebih lambat dan versi app yang lebih lama, bukan hanya build terbaru di Wi‑Fi cepat.

Kesalahan 2: Kontrak rapuh yang memblokir perubahan harmless

Jika kontrak gagal setiap kali Anda menambahkan field opsional baru atau mengubah urutan JSON, pengembang akan belajar mengabaikan build merah. Itu mengalahkan tujuan.

Sasaran: “ketat di tempat yang penting.” Ketatlah pada field wajib, tipe, nilai enum, dan aturan validasi. Fleksibel pada field tambahan, urutan, dan nilai yang wajar bervariasi.

Contoh kecil: backend mengubah status dari "active" | "paused" menjadi "active" | "paused" | "trial". Jika aplikasi mobile menganggap nilai tak dikenal menyebabkan crash, ini adalah breaking change. Kontrak harus menangkapnya dengan memeriksa bagaimana klien menangani nilai enum tak dikenal, atau dengan mewajibkan provider untuk tetap mengembalikan nilai yang diketahui sampai semua klien bisa menangani nilai baru.

Klien mobile pantas mendapat perhatian ekstra karena mereka beredar lebih lama di wild. Sebelum menyatakan perubahan API “aman”, tanyakan:

• Bisakah versi app yang lebih lama tetap mem-parse respons?
• Apa yang terjadi jika request di-retry setelah timeout?
• Akankah data cache bertabrakan dengan format baru?
• Apakah kita punya fallback saat sebuah field hilang?

Jika API Anda digenerate atau diperbarui cepat (termasuk dengan platform seperti AppMaster), kontrak adalah pilar pengaman praktis: mereka memungkinkan Anda bergerak cepat sambil membuktikan bahwa web dan mobile akan tetap bekerja setelah setiap perubahan.

Daftar periksa cepat sebelum mengirim perubahan API

Gunakan ini tepat sebelum Anda merge atau merilis perubahan API. Dirancang untuk menangkap edit kecil yang menyebabkan api besar saat web dan mobile sering dirilis. Jika Anda sudah melakukan pengujian kontrak, daftar ini membantu fokus pada break yang harusnya diblokir oleh kontrak.

5 pertanyaan yang harus ditanyakan setiap kali

• Apakah kami menambah, menghapus, atau mengganti nama field respons yang dibaca klien (termasuk field bersarang)?
• Apakah status code berubah (200 vs 201, 400 vs 422, 404 vs 410), atau bentuk body error berubah?
• Apakah ada field yang berubah dari wajib ke opsional atau sebaliknya (termasuk “bisa null” vs “harus hadir”)?
• Apakah sorting, pagination, atau filter default berubah (ukuran halaman, ordering, token cursor)?
• Apakah tes kontrak dijalankan untuk provider dan semua konsumen aktif (web, iOS, Android, dan alat internal)?

Contoh sederhana: API dulu mengembalikan totalCount, dan klien menggunakannya untuk menampilkan “24 hasil”. Anda menghapusnya karena “daftar sudah ada itemnya”. Backend tidak crash, tapi UI mulai menampilkan kosong atau “0 results” untuk beberapa pengguna. Itu adalah breaking change nyata, meskipun endpoint masih mengembalikan 200.

Jika Anda menjawab “ya” untuk salah satu item

Lakukan tindak lanjut cepat sebelum shipping:

• Konfirmasi apakah klien lama akan tetap bekerja tanpa update. Jika tidak, tambahkan jalur kompatibel mundur (pertahankan field lama, atau dukung kedua format sementara).
• Periksa penanganan error di klien. Banyak aplikasi memperlakukan bentuk error tak dikenal sebagai “Terjadi kesalahan” dan menyembunyikan pesan yang berguna.
• Jalankan tes kontrak konsumen untuk setiap versi klien yang masih Anda dukung, bukan hanya branch terbaru.

Jika Anda cepat membangun alat internal (mis. panel admin atau dashboard dukungan), sertakan juga konsumen tersebut. Di AppMaster, tim sering meng-generate web app dan mobile dari model backend yang sama, yang membuat mudah lupa bahwa tweak skema kecil masih bisa memecah klien yang sudah dirilis jika kontrak tidak dicek di CI.

Contoh: menangkap breaking change sebelum web dan mobile rilis

Bayangkan setup umum: tim API deploy beberapa kali sehari, web rilis harian, dan mobile mingguan (karena review app store dan rollout bertahap). Semua bergerak cepat, jadi risikonya bukan niat buruk, melainkan perubahan kecil yang tampak tak berbahaya.

Tiket dukungan meminta penamaan yang lebih jelas di respons profil pengguna. Tim API mengganti nama field di GET /users/{id} dari phone menjadi mobileNumber.

Penggantian nama itu terasa rapi, tapi itu breaking change. Web mungkin menampilkan nomor telepon kosong di halaman profil. Lebih parah, mobile bisa crash jika menganggap phone wajib, atau gagal validasi saat menyimpan profil.

Dengan pengujian kontrak, ini tertangkap sebelum pengguna terpengaruh. Begini bagaimana biasanya kegagalan muncul, tergantung cara Anda menjalankan cek:

• Verifikasi provider gagal (sisi API): job CI API memverifikasi provider terhadap kontrak konsumen web dan mobile yang tersimpan. Ia melihat konsumen masih mengharapkan phone, tapi provider sekarang mengembalikan mobileNumber, sehingga verifikasi gagal dan deploy diblokir.
• Build konsumen gagal (sisi klien): tim web memperbarui kontrak mereka untuk mengharapkan mobileNumber sebelum API mengirimkannya. Tes kontrak mereka gagal karena provider belum menyuplai field itu.

Di salah satu kasus, kegagalan terjadi lebih awal, keras, dan spesifik: ia menunjuk endpoint dan field yang tepat, bukan muncul sebagai “halaman profil rusak” setelah rilis.

Perbaikannya biasanya sederhana: buat perubahan bersifat additif, bukan destruktif. API mengembalikan kedua field untuk sementara:

• Tambah mobileNumber.
• Pertahankan phone sebagai alias (nilai sama).
• Tandai phone sebagai deprecated di catatan kontrak.
• Perbarui web dan mobile untuk membaca mobileNumber.
• Hapus phone hanya setelah semua versi klien yang didukung telah pindah.

Timeline realistis di bawah tekanan rilis bisa seperti ini:

• Senin 10:00: Tim API menambahkan mobileNumber dan mempertahankan phone. Tes kontrak provider lulus.
• Senin 16:00: Web beralih ke mobileNumber dan rilis.
• Kamis: Mobile beralih ke mobileNumber dan mengajukan rilis.
• Selasa berikutnya: Rilis mobile mencapai sebagian besar pengguna.
• Sprint berikutnya: API menghapus phone, dan tes kontrak mengonfirmasi tidak ada konsumen aktif yang masih membutuhkannya.

Ini adalah nilai inti: tes kontrak mengubah “rolet perubahan yang merusak” menjadi transisi yang terkontrol dan terjadwal.

Langkah selanjutnya untuk tim yang bergerak cepat (termasuk opsi tanpa kode)

Jika Anda ingin pengujian kontrak benar-benar mencegah kerusakan (bukan hanya menambah cek), lakukan rollout kecil dan buat kepemilikan jelas. Tujuannya sederhana: tangkap breaking change sebelum mencapai rilis web dan mobile.

Mulai dengan rencana rollout ringan. Pilih 3 endpoint teratas yang paling menyakitkan saat berubah, biasanya auth, profil pengguna, dan endpoint inti “list atau search”. Kunci-kan itu dulu, lalu perluas saat tim mulai percaya dengan alurnya.

Rollout praktis yang tetap terkelola:

• Minggu 1: tes kontrak untuk 3 endpoint teratas, dijalankan di setiap pull request
• Minggu 2: tambahkan 5 endpoint berikutnya dengan penggunaan mobile terbanyak
• Minggu 3: tutupi respons error dan kasus tepi (empty states, validasi)
• Minggu 4: jadikan “kontrak hijau” sebagai gerbang rilis untuk perubahan backend

Selanjutnya, tentukan siapa melakukan apa. Tim bergerak lebih cepat saat jelas siapa yang menangani kegagalan dan siapa yang menyetujui perubahan.

Peran sederhana:

• Pemilik kontrak: biasanya tim backend, bertanggung jawab memperbarui kontrak saat perilaku berubah
• Reviewer konsumen: lead web dan mobile yang mengonfirmasi perubahan aman untuk klien mereka
• Build sheriff: bergiliran harian atau mingguan, men-triage kegagalan tes kontrak di CI
• Pemilik rilis: mengambil keputusan untuk memblokir rilis jika kontrak rusak

Lacak satu metrik keberhasilan yang semua peduli. Untuk banyak tim, sinyal terbaik adalah lebih sedikit hotfix setelah rilis dan lebih sedikit “regresi klien” seperti crash app, layar kosong, atau checkout rusak terkait perubahan API.

Jika Anda mencari loop feedback yang lebih cepat, platform tanpa kode dapat mengurangi drift dengan meregenerasi kode bersih setelah perubahan. Ketika logika atau model data bergeser, regenerasi membantu menghindari penumpukan patch yang perlahan mengubah perilaku.

Jika Anda membangun API dan klien dengan AppMaster, langkah praktis berikutnya adalah mencoba sekarang dengan membuat aplikasi, memodelkan data di Data Designer (PostgreSQL), memperbarui workflow di Business Process Editor, lalu meregenerasi dan deploy ke cloud Anda (atau mengekspor source code). Padukan itu dengan pengecekan kontrak di CI sehingga setiap build yang dihasilkan ulang tetap membuktikan bahwa ia sesuai dengan apa yang diharapkan web dan mobile.