Aturan Validasi Bersama untuk Web dan Aplikasi Mobile

Mengapa validasi bisa bergeser

Validasi menjadi tidak sinkron karena alasan sederhana: formulir web dan mobile sering dibuat pada waktu berbeda oleh orang yang berbeda. Satu tim menambahkan aturan cepat di situs, tim lain menyalin versi lama ke aplikasi, lalu keduanya melanjutkan pekerjaan.

Awalnya perbedaannya tampak kecil. Lalu satu perubahan memperlihatkannya. Sekarang kata sandi membutuhkan 12 karakter bukan 8. Nomor telepon harus menyertakan kode negara. Field yang dulu opsional kini wajib. Jika hanya satu klien yang diperbarui, pelanggan yang sama dapat memasukkan data yang valid di satu perangkat dan terblokir di perangkat lain.

Itulah mengapa aturan validasi bersama penting. Tanpa itu, setiap klien menjadi versi kebenaran yang berbeda.

Bentuk drift dalam praktik

Form pendaftaran menunjukkan masalah ini dengan cepat. Di situs web, "nama perusahaan" mungkin bersifat opsional. Di aplikasi mobile, itu mungkin masih wajib karena layar tersebut dibuat beberapa bulan sebelumnya. Pengguna mengisi formulir yang sama dua kali, mendapat dua hasil berbeda, dan menganggap produk rusak.

Ini biasanya terjadi ketika aturan disalin ke beberapa tempat dan diperbarui secara manual. Waktu rilis memperburuknya. Perubahan web bisa langsung tayang hari ini, sementara perbaikan mobile mungkin menunggu rilis aplikasi berikutnya.

Ketidaksesuaian sering terlihat di hal-hal dasar: field wajib, pengecekan format, dan batasan bisnis seperti usia, ukuran pesanan, atau aturan diskon. Tim dukungan akhirnya menjelaskan mengapa satu layar menerima nilai dan layar lain menolaknya. Seiring waktu, pengguna berhenti mempercayai pesan error, dan tim berhenti mempercayai rilis mereka.

Masalahnya jarang pada aturan itu sendiri. Masalahnya adalah aturan yang sama hidup di terlalu banyak tempat.

Apa yang harus sama di mana-mana

Jika sebuah formulir berperilaku berbeda di web dan mobile, pengguna langsung menyadarinya. Pendekatan paling aman adalah memutuskan aturan mana yang bersifat universal dan menjaganya tetap sama di setiap klien.

Mulailah dari dasar. Sebuah field tidak boleh wajib di satu perangkat dan opsional di perangkat lain kecuali ada alasan produk yang jelas. Pengecekan format juga harus cocok. Email, telepon, tanggal, dan field serupa harus mengikuti pola yang sama di mana-mana. Bahkan perbedaan kecil, seperti satu klien menerima spasi dalam nomor telepon sementara yang lain menolak, menimbulkan kebingungan.

Batas panjang dan karakter yang diizinkan perlu perlakuan yang sama. Jika nama pengguna menerima 30 karakter di mobile tetapi hanya 20 di web, pengguna bisa menyimpan data yang klien lain tidak bisa edit nanti. Masalah yang sama muncul pada nama, catatan, kode, dan ID.

Aturan bisnis sama pentingnya. Jika pengguna harus berusia di atas batas tertentu, berada di wilayah yang didukung, atau memiliki status akun tertentu, pengecekan itu harus bekerja sama di setiap layar.

Kata-kata tidak harus identik di mana-mana, terutama di layar mobile yang kecil, tetapi maknanya harus konsisten. Jika satu aplikasi mengatakan "Masukkan tanggal yang valid" dan yang lain mengatakan "Tanggal tidak didukung," pengguna mungkin mengira aturannya berbeda padahal tidak.

Satu tes sederhana bekerja baik di sini: jika pengguna memasukkan data yang sama di web dan mobile, mereka harus mendapatkan hasil yang sama dan panduan dasar yang sama untuk memperbaikinya.

Biarkan backend mengambil keputusan akhir

Umpan balik cepat di frontend berguna, tetapi tidak boleh menjadi kata akhir. Backend harus selalu memutuskan apakah data valid.

Klien web dan mobile tetap harus menangkap masalah jelas lebih awal. Mereka harus menandai field wajib yang kosong, format email yang buruk, tanggal yang tidak mungkin, dan nilai yang jelas di luar rentang. Itu menghemat waktu dan membantu orang memperbaiki kesalahan sebelum menekan Submit.

Tetapi backend melihat gambaran penuh. Backend dapat memeriksa aturan bisnis yang terkait data langsung, status akun, izin, inventaris, atau catatan yang diubah oleh pengguna lain beberapa detik sebelumnya. Kode promo mungkin tampak valid di ponsel, tetapi server mungkin tahu itu sudah kedaluwarsa atau pernah digunakan.

Agar aturan validasi bersama bekerja baik, backend harus mengembalikan error dalam format yang bisa dipahami setiap klien. Hindari balasan samar seperti "Invalid input." Gunakan kode error stabil atau nama aturan bersama pesan yang jelas.

Beberapa contoh sudah cukup:

• required untuk field yang hilang
• invalid_format untuk pola email atau telepon yang buruk
• out_of_range untuk nilai yang melebihi atau di bawah batas
• not_allowed untuk cek berbasis izin atau status
• already_exists untuk email, nama pengguna, atau ID duplikat

Nama-nama itu harus tetap stabil di semua klien. Perbedaan kecil seperti email_invalid di satu aplikasi dan invalid_email di aplikasi lain menciptakan bug yang tidak perlu.

Tes backend yang baik sederhana: jika seseorang melewati UI dan mengirim permintaan langsung ke API, data buruk yang sama harus tetap ditolak dengan alasan yang sama.

Buat satu sumber kebenaran

Perbaikan paling rapi adalah satu buku aturan. Jika setiap tim menulis validasi di setiap form web dan layar mobile, aturan akan bergeser. Aturan validasi bersama bekerja lebih baik saat aturan didefinisikan sekali dan setiap klien mengikuti definisi yang sama.

Sumber bersama ini bisa berupa schema, model backend, atau konfigurasi produk pusat. Format pastinya kurang penting dibandingkan kebiasaan. Definisikan field sekali sebelum siapa pun membangun layar. Simpan nama field, tipe data, status wajib, format, dan batasan bisnis bersama.

Membantu juga jika aturan dikelompokkan berdasarkan objek bisnis daripada berdasarkan perangkat. Seorang user, order, invoice, atau permintaan pendaftaran harus memiliki satu set aturan yang berlaku di mana-mana. Untuk setiap objek, catat field, cek wajib, aturan format, batasan bisnis, dan kode error yang dikembalikan backend.

Ini membuat perubahan lebih aman. Jika bisnis memutuskan nomor telepon opsional, Anda memperbarui satu definisi bersama daripada mencari di iPhone, Android, web, dan layar admin.

Versioning juga penting. Perubahan aturan bisa merusak aplikasi lama yang masih terpasang di ponsel pelanggan. Alih-alih mengganti aturan tanpa jejak, beri versi pada perubahan sehingga backend dapat mendukung klien lama untuk periode singkat sambil versi baru menyebar.

Langkah tinjau singkat membantu lebih dari yang diperkirakan banyak tim. Ketika aturan berubah, product dapat mengonfirmasi tujuan bisnis dan dukungan dapat menandai masalah pelanggan nyata, seperti field nama yang menolak tanda baca umum atau aturan alamat yang terlalu ketat.

Jika Anda membangun dengan AppMaster, pendekatan ini cocok secara alami karena logika backend, aplikasi web, dan aplikasi mobile native bisa dikelola dalam satu platform no-code. Ide yang sama berlaku di mana saja: tulis aturan sekali, taruh di tempat pusat, dan biarkan semua klien mengikutinya.

Rencana rollout sederhana

Anda tidak perlu rewrite besar untuk memperbaiki drift validasi. Mulailah dengan satu formulir dan buat aturannya eksplisit.

Pertama, daftarkan setiap field dan jelaskan dengan bahasa sederhana. Catat jenis nilai yang diterima, apakah wajib, format yang harus diikuti, dan kondisi bisnis apa pun yang terkait. "Email diperlukan" tidak cukup jika satu klien menerima format buruk dan yang lain memblokirnya.

Lalu terapkan cek backend terlebih dahulu. Setelah itu, cerminkan cek yang sama di formulir web dan formulir mobile sehingga pengguna mendapat umpan balik cepat sebelum submit.

Urutan sederhana bekerja baik:

1. Tulis daftar aturan per field.
2. Letakkan aturan di validasi backend terlebih dahulu.
3. Tambahkan cek frontend yang cocok di web.
4. Tambahkan cek yang sama di mobile.
5. Uji contoh input yang sama di mana-mana.

Testing adalah tempat perbedaan tersembunyi biasanya muncul. Gunakan seperangkat contoh valid dan tidak valid untuk setiap field: nilai kosong, format salah, nilai tepat di bawah batas, nilai tepat pada batas, dan nilai tepat di atasnya. Jika web dan mobile sama-sama cocok dengan backend pada setiap kasus, Anda memiliki sistem yang dapat dipercaya.

Contoh: formulir pendaftaran pelanggan

Form pendaftaran membuat ini mudah terlihat. Bayangkan formulir memiliki tiga field: email, password, dan tanggal lahir.

Di web dan mobile, formulir harus bereaksi sama sebelum pengguna mengirimkannya. Jika email kosong, keduanya harus berhenti dan menampilkan pesan yang sama. Jika format salah, keduanya harus menangkapnya juga.

Aturan password harus cocok persis. Jika minimum 8 karakter, itu harus 8 di mana-mana, bukan 6 di web dan 10 di mobile. Ketidaksesuaian kecil seperti ini cepat membingungkan pengguna, terutama saat mereka berpindah perangkat.

Tanggal lahir sering menjadi area di mana logika bisnis bergeser. Jika produk Anda hanya mengizinkan pendaftaran bagi yang berusia 18 tahun ke atas, kedua klien harus menggunakan aturan cutoff yang sama dan definisi "hari ini" yang sama. Kalau tidak, satu pengguna disetujui di situs sementara ditolak di aplikasi.

Backend tetap harus memeriksa semuanya lagi saat permintaan tiba. Di situlah Anda menangkap akun duplikat, permintaan yang diedit, dan versi aplikasi lama yang masih mengirim data usang.

Pesan juga harus jelas dan konsisten. Contoh yang baik adalah "Masukkan alamat email Anda", "Masukkan alamat email yang valid", "Kata sandi harus minimal 8 karakter", dan "Sudah ada akun dengan email ini." Ketika pengguna melihat bahasa yang sama di mana-mana, dukungan menjadi lebih mudah dan kepercayaan meningkat.

Kesalahan yang menyebabkan drift

Sebagian besar masalah validasi tidak muncul dari satu aturan yang jelas rusak. Mereka muncul dari ketidaksesuaian kecil yang menumpuk seiring waktu.

Salah satu kesalahan umum adalah menyembunyikan aturan hanya di satu klien. Aplikasi iPhone mungkin mengharuskan nomor telepon sementara aplikasi web menganggapnya opsional. Kesalahan lain adalah menggunakan pola berbeda untuk field yang sama. Form web mungkin mengizinkan spasi di kode pos sementara aplikasi Android memblokirnya, atau satu klien menerima tanda plus di nomor telepon sementara yang lain menghapusnya.

Masalah yang lebih serius adalah terlalu mengandalkan UI. Validasi sisi klien membantu pengguna memperbaiki kesalahan lebih cepat, tetapi tidak pernah cukup sendiri. Aplikasi lama, gangguan browser, dan permintaan API langsung semua dapat mengirim data buruk jika backend tidak menegakkan batasan bisnis yang sama.

Pesan error yang buruk membuat semuanya lebih buruk. "Invalid input" tidak memberi tahu pengguna apa yang harus diperbaiki. Pesan yang jelas melakukannya. Versi aplikasi lama juga mudah terlupakan. Jika rilis baru menambah field wajib, klien lama mungkin terus mengirim data tidak lengkap selama berminggu-minggu.

Ketika validasi terus bergeser, penyebab biasanya sederhana: field wajib tersembunyi, aturan format berbeda, pengecekan backend yang lemah, pesan error samar, dan tidak ada rencana untuk versi lama.

Pemeriksaan rilis yang menangkap masalah

Sebelum dikirim, uji formulir yang sama dengan cara yang sama di setiap klien. Gunakan satu set contoh input kecil dan jalankan melalui aplikasi web, aplikasi mobile, dan API backend. Jika satu klien menerima nilai yang lain tolak, aturan validasi bersama Anda sebenarnya belum benar-benar bersama.

Mulailah dengan kasus dasar terlebih dahulu. Biarkan field wajib kosong, masukkan nilai berformat buruk, dan coba kasus tepi seperti tanggal di batas tepat, nama dengan satu karakter, atau field diisi hingga panjang maksimum.

Pemeriksaan pra-rilis Anda harus menjawab beberapa pertanyaan langsung: apakah web menolak input buruk yang sama seperti mobile, apakah backend masih menolak data tidak valid meskipun klien melewatkannya, dan apakah pengguna melihat makna yang sama dalam pesan error di mana-mana?

Pemeriksaan backend adalah yang paling penting. Jika seseorang melewati UI, menggunakan aplikasi lama, atau mengirim data langsung ke API, hasilnya harus tetap aman dan dapat diprediksi.

Juga berharga meninjau teks error berdampingan. Jika web mengatakan "Masukkan email yang valid" tetapi mobile mengatakan "Error tidak dikenal", orang akan mengira aplikasi berperilaku berbeda walau aturannya sama.

Setelah peluncuran, pantau tiket dukungan dan komentar pengguna selama beberapa hari. Keluhan seperti "berfungsi di ponsel tapi tidak di desktop" biasanya menunjukkan celah validasi lebih cepat daripada dasbor mana pun.

Langkah pembersihan berikutnya

Jika formulir Anda terus rusak dengan cara berbeda di web dan mobile, jangan coba memperbaiki semua formulir sekaligus. Mulailah dengan formulir yang paling sering menimbulkan masalah, biasanya pendaftaran, checkout, atau pengeditan profil.

Pindahkan aturan ketat ke logika backend terlebih dahulu. Itu termasuk field wajib, cek format, cek duplikat, dan batasan bisnis seperti usia, tipe akun, atau wilayah. Lalu biarkan web dan mobile mencerminkan cek yang sama untuk kecepatan dan kejelasan.

Tulis aturan dengan sederhana. Alih-alih "validasi status pelanggan," tulis "Pelanggan bisnis harus memasukkan NPWP" atau "Nomor telepon opsional kecuali notifikasi SMS diaktifkan." Kata-kata yang jelas memudahkan desainer, pengembang, tester, dan tim dukungan menemukan celah sebelum rilis.

Jika ingin mengurangi pekerjaan berulang, AppMaster dapat membantu karena memungkinkan tim membangun backend, web, dan aplikasi mobile native dari satu sistem. Itu mempermudah menyelaraskan logika bisnis sambil tetap memberi pengguna umpan balik cepat di setiap klien.

Tujuannya bukan formulir sempurna dalam semalam. Tujuannya adalah lebih sedikit kejutan, lebih sedikit tiket dukungan, dan validasi web serta mobile yang tetap konsisten seiring produk Anda tumbuh.