Kapan tepat melakukan perhitungan di front-end?

Tim saya sedang mengembangkan aplikasi keuangan berbasis WEB dan ada sedikit perdebatan dengan seorang kolega di mana harus menyimpan perhitungan - murni di back-end atau menyimpan beberapa di front-end juga?

Penjelasan singkat: Kami menggunakan Java (ZK, Spring) untuk front-end dan Progress 4gl untuk back-end. Perhitungan yang melibatkan beberapa matematika hardcore & data dari database disimpan di back-end, jadi saya tidak membicarakannya. Saya berbicara tentang situasi di mana pengguna memasukkan nilai X, kemudian ditambahkan ke nilai Y (ditampilkan di layar) dan hasilnya ditampilkan di bidang Z. Operasi jQuery-ish murni dan sederhana, maksud saya.

Jadi apa yang akan menjadi praktik terbaik di sini:

1) Tambahkan nilai dengan JavaScript yang menyelamatkan dari pergi ke back-end dan kembali dan kemudian memvalidasi mereka di back-end "on save"?

2) Menyimpan semua logika bisnis di tempat yang sama - karena itu membawa nilai-nilai ke back-end dan melakukan perhitungan di sana?

3) Lakukan perhitungan di front-end; kemudian kirim data ke back-end, validasi di sana, lakukan perhitungan lagi dan hanya jika hasilnya valid dan sama, tampilkan ke pengguna?

4) Sesuatu yang lain?

Catatan: Kami melakukan beberapa validasi dasar di Jawa tetapi sebagian besar masih di back-end karena semua logika bisnis lainnya.

Peningkatan data yang akan dikirim dengan menghitung ulang semua yang ada di back-end tidak akan menjadi masalah (ukuran XML kecil; server dan bandwidth akan menahan peningkatan jumlah operasi yang dilakukan oleh pengguna).

programming-practices web-applications front-end

— IgnasK
sumber

Rule of thumb: ketika menggunakan bahasa yang sangat diketik.

— Den

Pengujian Unit Otomatis akan lebih mudah jika semua logika ada di ujung belakang. Jika 90% harus menjadi ujung belakang dan 10% bisa di ujung belakang, maka saya akan menempatkan 100% di ujung belakang.

— Ian

@Ian: Anda dapat melakukan pengujian unit otomatis untuk kode front end juga jika Anda menyusun kode dengan baik.

— Lie Ryan

Rule of thumb: Setiap kali Anda bisa lolos begitu saja.

— goldilocks

Rule of thumb: menganggap pengguna meretas JavaScript Anda dan melakukan perhitungan sendiri. Dari sudut pandang keamanan, perhitungan harus dilakukan di back-end. Anda dapat melakukan keduanya juga: JS dapat memberikan umpan balik yang lebih cepat, tetapi perhitungan yang benar-benar dihitung dilakukan di server.

Jawaban:

Seperti biasa, keputusan semacam itu melibatkan pertukaran antara berbagai tujuan, yang beberapa di antaranya saling bertentangan.

Efisiensi menyarankan agar Anda melakukan perhitungan di front-end - baik karena cara itu komputer pengguna menggunakan lebih banyak daya dan server Anda menggunakan lebih sedikit, dan karena pengguna melihat umpan balik yang lebih cepat, yang meningkatkan pengalaman pengguna.
Keamanan menuntut agar setiap operasi yang mengubah keadaan tidak dapat mengandalkan data yang sedang diperiksa atau dihitung di komputer klien, karena komputer klien mungkin berada di bawah kendali penyerang jahat. Oleh karena itu, Anda harus memvalidasi apa pun yang berasal dari sumber yang tidak tepercaya di sisi server.
Memprogram efisiensi dan pemeliharaan menunjukkan bahwa Anda tidak harus melakukan perhitungan yang sama dua kali karena usaha yang sia-sia.

Dangkal ini terdengar seolah-olah semuanya harus dilakukan di sisi server, tetapi itu tidak selalu terjadi. Jika Anda dapat dengan mudah mempertahankan kode duplikat (mis. Dengan secara otomatis membuat validasi javascript dari Java validator sisi-server Anda), maka mengulangi perhitungan dapat menjadi solusi yang baik. Jika data yang terlibat semuanya tidak penting, misalnya jika pengguna hanya bisa menipu diri mereka sendiri dan bukan Anda jika mereka memanipulasi nilai, maka validasi sisi server tidak diperlukan. Jika waktu respons Anda didominasi oleh hambatan yang sangat berbeda sehingga penundaan pulang-pergi tidak terlihat, maka pertimbangan UX tidak menentukan, dll. Oleh karena itu, Anda harus mempertimbangkan seberapa kuat masing-masing tekanan ini dalam situasi Anda, dan memutuskan dengan tepat .

— Kilian Foth
sumber

Saya ingin menambahkan yang

Programming efficiency and maintainability suggests that you shouldn't do the same computation twice because of the wasted effort.

tidak benar karena [1] Validasi di front-end dapat memberikan umpan balik cepat kepada pengguna untuk melakukan koreksi jika diperlukan. [2] Validasi di back-end tidak responsif, dan dengan demikian tidak memberikan pengguna kesempatan terbaik untuk melakukan koreksi. Pengguna harus menunggu dan mengulangi lebih banyak pekerjaan. Jadi saya pikir kedua validasinya tidak persis sama.

— InformedA

Bukan itu yang ingin saya sampaikan - rawatan memang menyiratkan "jangan ulangi diri sendiri", dan menurut prinsip ini pengulangannya tentu saja buruk. Jika tidak ada pertimbangan lain, Anda tidak harus melakukannya. Fakta bahwa itu tetap sering ide yang baik karena ada yang pertimbangan lain yang bertentangan prinsip ini, yaitu kegunaan yang lebih baik melalui perputaran cepat.

— Kilian Foth

@randomA Anda salah menerapkan prinsip itu, jika Anda bermaksud bahwa sesuatu yang perlu divalidasi di server hanya boleh dihitung di server, karena jika "nilai server divalidasi" (atau apa pun yang bergantung padanya) dikembalikan ke klien kemudian pada titik tertentu dikirim kembali ke server, Anda harus memvalidasinya lagi - tidak berguna. Atau Anda perlu beberapa sistem referensi aman, yang mungkin lebih tidak efisien. Saya akan mengatakan jika Anda dapat melakukan perhitungan pada klien, melakukannya pada klien , tetapi juga tidak pernah percaya apa yang klien katakan kepada Anda .

— goldilocks

@goldilocks Apa yang Anda katakan dalam huruf tebal juga adalah apa yang saya setujui juga, Anda harus memvalidasi semua yang ada di back-end. Maksud saya adalah: validasi pada front-end lebih responsif, jadi tidak sepenuhnya sama dengan validasi pada back-end.

— InformedA

Ada alasan kuat untuk melakukan perhitungan di backend

Logika bisnis tidak termasuk dalam lapisan presentasi
Logika bisnis dalam JavaScript menimbulkan ancaman
Anda menganggap ada hubungan satu ujung depan -> hubungan satu ujung belakang yang tidak selalu benar , ujung belakang harus dianggap mampu atau melayani lebih dari satu aplikasi ujung depan, sehingga Anda tidak dapat mengasumsikan apa pun.
Jika perhitungan menggunakan jumlah data yang besar, itu tidak akan efisien untuk menyimpannya di front-end
Jika perhitungan menggunakan database, Anda tidak akan dapat mereplikasi di ujung depan

Rekomendasi saya

Mintalah database menegakkan aturan bisnis sebanyak mungkin dalam model, termasuk kunci asing, kunci primer, periksa batasan dan pemicu
Membuat pengecualian lapisan bisnis melemparkan ketika aturan bisnis tidak terpenuhi (baik karena database mengembalikan kesalahan atau karena lapisan bisnis itu sendiri memvalidasi data)
Jika dan hanya jika waktu respon tidak dapat diterima, lakukan validasi atau preproses menggunakan Ajax (pekerjaan tidak akan benar-benar dilakukan dalam JavaScript, itu akan dilakukan di backend tanpa harus memuat ulang halaman)
Anda dapat melakukan validasi sederhana dalam JavaScript seperti tidak mengizinkan nilai kosong, atau nilai yang terlalu panjang, atau di luar kisaran (untuk yang terakhir Anda mungkin ingin membuat rentang di back-end)

— Tulains Córdova
sumber

Masalah dengan memiliki database menegakkan aturan bisnis adalah melaporkan pelanggaran ke ujung depan! Jika ujung depan memberlakukan aturan bisnis, ia dapat dengan cepat memberi umpan balik pesan kesalahan yang berarti kepada pengguna. Jika back-end melakukannya, ada banyak lalu lintas dua arah yang kikuk antara ujung depan dan belakang karena kesalahan dilaporkan satu per satu.

— James Anderson

@ JamesAnderson Tidak ada lagi "front-end". Mungkin ada beberapa ujung depan ke database yang sama, atau beberapa database ke beberapa ujung depan. Juga, memiliki back-end menegakkan aturan bisnis tidak berarti front-end dilarang melakukannya. Saya menyoroti itu di poin kedua.

— Tulains Córdova