Komunitas pengembang sedang aktif mendiskusikan eserde, sebuah pustaka Rust baru yang menjanjikan peningkatan dalam pengembangan API dengan melaporkan beberapa kesalahan deserialisasi secara bersamaan. Meskipun pendekatan ini memberikan manfaat yang jelas bagi pengguna API, diskusi yang berkembang menunjukkan adanya antusiasme sekaligus kekhawatiran praktis tentang implementasinya.
Pertimbangan Kinerja dalam Penanganan Error
Komunitas telah menyoroti pertimbangan teknis yang signifikan dalam pendekatan eserde. Ketika menemui kesalahan, pustaka ini melakukan dua kali pemrosesan data masukan - pertama menggunakan deserializer serde_json, kemudian menggunakan deserializer-nya sendiri jika terjadi kesalahan. Meskipun jalur sukses tetap secepat implementasi serde_json tradisional, kasus kesalahan akan memakan waktu setidaknya dua kali lebih lama untuk diproses. Pilihan desain ini mengutamakan kompatibilitas dan keandalan dibandingkan kinerja murni dalam skenario kesalahan.
Pertimbangan Utama untuk eserde:
- Deserialisasi dua-tahap pada kasus error
- Kompatibel dengan implementasi serde_json yang sudah ada
- Waktu kompilasi yang lebih lama (sekitar 2x lebih banyak kode yang dihasilkan)
- Dukungan terbatas untuk pemformatan error kustom
- Tidak ada dukungan untuk deserialisasi dari pembaca yang tidak dapat diputar ulang
Tantangan Pengembangan API di Dunia Nyata
Para pengembang telah berbagi kasus penggunaan yang meyakinkan di mana pelaporan multi-error dapat secara signifikan meningkatkan pengalaman pengembangan. Salah satu contoh yang mencolok berasal dari komunitas:
Saya pernah bekerja pada proyek di mana pengembang BE memiliki masalah mendasar dalam memahami tipe data, sehingga array json akan mengubah tipenya ketika kosong, misalnya dari array menjadi objek kosong.
Skenario dunia nyata seperti ini menunjukkan mengapa memiliki umpan balik kesalahan yang komprehensif dapat menghemat waktu pengembangan dan mengurangi frustrasi.
Kekhawatiran Integrasi dan Implementasi
Komunitas telah mengangkat beberapa kekhawatiran praktis tentang implementasi eserde. Salah satu batasan yang mencolok melibatkan kemampuan pemformatan kesalahan. Beberapa pengembang menunjukkan bahwa sementara pustaka seperti serde_json dan toml menyediakan informasi kesalahan terperinci untuk pemformatan kustom (mirip dengan keluaran rustc), eserde saat ini menyederhanakan hal ini dengan mengkonversi kesalahan menjadi string, yang berpotensi membatasi fleksibilitas dalam penanganan dan presentasi kesalahan.
Perdebatan Field Opsional
Sebuah diskusi menarik telah muncul seputar penanganan hasil deserialisasi parsial. Sementara beberapa pengembang menganjurkan untuk mengembalikan hasil parsial bersama dengan kesalahan, yang lain menekankan pentingnya mempertahankan keamanan tipe yang ketat. Komunitas menunjukkan bahwa fitur serde yang ada, seperti field opsional dan nilai default, sudah menyediakan mekanisme untuk menangani data yang hilang atau parsial bila diperlukan.
Implikasi Masa Depan
Terlepas dari beberapa keterbatasan, komunitas umumnya memandang eserde sebagai pengembangan yang menjanjikan untuk desain API. Pendekatan pustaka ini terhadap pelaporan kesalahan yang komprehensif dapat secara signifikan mengurangi proses bolak-balik yang biasanya diperlukan saat men-debug payload API, meskipun pengembang harus mempertimbangkan dengan cermat implikasi kinerja dan kasus penggunaan sebelum mengadopsinya.
Referensi: eserde: Don't stop at the first deserialization error.