ijin nimbrung, untuk POST create sebaiknya pakai request_id (di body) jadi jika user misal di FE nya klik button save 2x itu akan mengirimkan request_id yang sama sehingga di BE bisa memproses itu sebagai data yang sama
ini akan jadi PR tambahan, karena BE harus maintain request_id nya, apalagi request banyak banget, maka harus siapin tabel khusus untuk menyimpan data request_id nya, dan ini gak scale , lebih baik fokus di unique column di tabel nya saja
Cara yg lebih elegan adlh dgn melakukan caching transaksi. BE akan menyimpan transaksi d chace. Jika transaksi selesai (sukses ataupun gagal) maka transaksi dihapus dr cache. Atau jika sdh lewat jangka waktu tertentu maka transaksi dihapus dr cache. Dan yg disimpan d cache cukup hasil hash dr data2 yg dikirimkan.
User call api POST, lalu cache di redis, jika sukses maka hapus data di redis, begitukah? Jika sudah sukses lalu user call api tersebut lagi, apa yang terjadi?
bener.. saya nerapin ini. karna, darimana kita tau itu tidak disengaja, atau memang mau insert 2x? kalo cuma andelin check di db datanya exist atau ga, masi ada possibility jg dia double insert
Yup ,bener bnget.. kembali lagi ke case.. Ku pernah buat apps penjualan, Ad case dimana cust mau buat invoice based on po.. di po ad 2 barang yg sama tpi beda record tpi qty beda.. Mereka maunya inputnya sma persis di PO (2record). Jdi emang begitu wkwkwkw 😂😂😂
aku pernah juga om case begini, akhirnya bikin sistem konfirmasi aja. di UI, user dikasih prompt kalo POST request nya ada kemungkinan double request (dikasih restriction aja misalnya kalo request sebelumnya jarak terlalu deket, etc.) kalo user nya ok, dia konfirmasi dan UI akan kirim ulang request yg disertai sebuah flagging
Harus didefinisikan dahulu kondisi yang menyebabkan 2 objek/data adalah sama (equal). Kemudian, sebelum Backend memproses insert, harus dilakukan dulu pengecekan terkait kesamaan objek yang akan di-insert dengan objek-objek yang sudah eksis di database. Jika ada kesamaan objek yang akan di-insert dengan objek yang sudah eksis di database, maka muncul peringatan.
selama ada unique kolom, gak masalah, asal jangan tidak ada unique column, karena kalo request datang bareng2, maka secara otomatis dua dua nya waktu ngecek tidak akan dapat data, jadi dianggap masih kosong datanya, akhirnya dua dua nya akan create data baru
practice yang aku tau bisanya pake header "Idempotency-Key" yang digenerate di client, terus di store di table Request... setiap request POST yang masuk ke api akan selalu check table ini untuk memastikan requestnya ga double...
apakah idempotency keynya uuid aja? kalau iya, gimana kalau requestnya timeout? user/client akan retry, otomatis keynya ke generate baru kan? masih possible double insert
@@bakajwd697 iya mas pake uuid sebagai keynya, ketika user retry dia tetap pake key yg sama, kecuali di refresh halaman, atau ulangi prosesnya dari awal ...
Sebenarnya idempotent di frontend ini simple, setiap request selalu buat state loading dan disable button untuk submit datanya, lalu clear form setelah prosesnya berhasil di submit, jadi kejadian double click dan ngirim data yang sama seharusnya ngga ada. Cuma terkadang buat frontend engineer yang kurang teliti, bisa aja state loading atau disablenya kelupaan, nah mungkin idempotent key bisa dibuat untuk prevent itu. Nah dengan case kaya gini, itulah kenapa unit test frontend ini perlu di implement.
dulu pernah dapet kasus begini karena FEnya ga mau ubah (karena di apinya kalo dengan req sama akan muncul validasi duplicate) akhirnya, tampung respon pertama di redis, jika dalam waktu dekat ada request yang sama, jadikan response pertama di response kedua, jadi di FE seperti meruquest 1 aja
kalo misal fe nya pake react atau js framework yg lain. sesimple dibuat state loading buttonnya (ga bisa di klik hingga response selesai) dihandle dari sisi FE. nah tapi resiko juga sih misal manipulasi kode html atau js sehingga mekanisme state loading ga jalan atau yg aneh kondisi race dimana ada multi device masukin inputan yg sama dan dua2 nya berhasil. idealnya emg implement BE nya jga.
Iya sih, kalau misalkan kita ngirim POST untuk generate API Key, itu bisa problem sih, respondnya yang ketangkep yang pertama, yang kedua gk ke result.. yah jadinya invalid. Makasih banyak mas ilmunya 🙏
kang eko saya izin me re design website programmer zaman now untuk belajar mengimplementasikan hasil belajar saya, apakah boleh? kalo gak boleh gak apa2
mungkin bisa menggunakan count data terakhir sebagai unique id. contoh user A sudah input 1, cek dengan db count row, result 1, data yg kedua yg akan diinsert adalah: count + 1 = 2, maka unique id = user uuid + 2. dalam kondisi race condition, 2 data yg diinsert akan sama unique id nya: user uuid + 2 (karena pengecekan db count terakhir sama2 count = 1) kalau ingin result error: maka cukup perintah sql insert, kalau ingin result sukses, maka perintahnya adalah sql replace (replace where unique id = "user uuid + 2"). setelah data 2 berhasil dimasukkan, dan selanjutnya user A akan input kembali, maka unique id nya: user uuid + 3. mohon koreksi kalau ada kesalahan. terima kasih
1. Darimana tau itu ga disengaja, atau emang sengaja mau insert 2x? 2. kenapa demonya sepsifik kasi usecase e-commerce? apaka ini titipan ordal kah? harusnya judulnya ganti. Handle double request pada E-COMMERCE 🤗 di issue / questionnya nanyain bestpractice... at least ada jg scenario2 lain... kaya timeout, ga punya "SKU", disengaja atau ga disengaja, dll so, what is the best practice sir?
@@AmbriBlack tapi ini udah jadi issue yg umum pak. kalau yg di video kan mengandalkan unique constraint dari DB. sementara ada use case lain dimana secara data emang ga masalah kalau datanya dobel. mungkin karena emang disengaja mau buat datanya lebih dari satu aja gitu.. nah, tapi dobel yang ga disengaja karena faktor lain gimana validasinya?
@@bakajwd697 ya susah juga sih karena kebanyakan pada validasi unique data, ya meskipun misal ada cara mungkin kayak rate limiter tapi kadang itu juga nggak membantu. Kemungkinan cara - cara yang udah ada cuman bisa meminimalkan kesalahan bukan menghilangkan sepenuhnya.
@@bakajwd697 itu kayanya banyak solusinya, di vidio itu bisa pakai tambahan kolom buat handlenya, bisa aja lu bikin unique tapi nanti kl casenya ky yg di video itu ya bakal kebingungan usernya knp error sebetulnya bisa pake prefix juga pas insert
kalau untuk kasus insert transaksi seperti ini bisa ditambahin key misalnya 'x-idempotency-key' di header saat request api, bisa berupa uuid yang penting unique setiap request dari sisi client, nanti di backend check aja kalau nilai x-idempotency-key udah ada di cache bisa di skip process insert transaksinya.
Bedakan antara beli 2 kali (berarti 2 transaksi) dengan dobel transaksi (dobel post), yg dibahas disini terjadi dobel post, jadi transaksi yg sama kekirim (post) 2 kali sebelum proses transaksi selesai. Transaksi disini bukan jual beli ya. Tapi transaksi sistem.
@@farrel6788 gak bisa gmn ya, kan tinggal bikin unique aja misalnya di tablenya di tambahin key unique untuk fieldnya misalnya idempotency_key, kalau insert yang sama pasti gagal, di sisi client juga bisa ditambahin fungsi misalnya pas on submit posisi tombolnya langsung disable biar gak double click. Di backend juga bisa di tambahin database locking biar row yang sedang diproses gak bisa diupdate sebelum transaksi selesai(commited). Bisa juga ditambahin validasi misalnya untuk user id dan nominal yang sama transaksi gak bisa dilakukan dalam beberapa waktu / dikasih timeout. Intinya sih karena request POST itu engga idempotent gimana cara handlenya supaya data itu gak double input kalau terjadi masalah misalnya karena jaringan lemot / user double click dsb.
sebenernya tadi ga paham, kalau client ga sengaja ngirim dua request dan idempotency-key dari dua request itu berbeda, tapi setelah google2 lagi sudah paham
Siapa yang kaget suaranya jadi English?😂
Google udah fitur auto dubbing
iya lagi wkwk, tapi bagus jadinya bisa ngereach penonton luar indonesia juga
itu pake tools apa ya? wkwk
Wkwk we baru tau ternyata bisa pilih bahasanya😂
ternyata tidak sendiri wkwk
ijin nimbrung,
untuk POST create sebaiknya pakai request_id (di body) jadi jika user misal di FE nya klik button save 2x itu akan mengirimkan request_id yang sama sehingga di BE bisa memproses itu sebagai data yang sama
@@MartinCode-f8n akhirnya, cuman baca komen ini bisa paham harus gimana, baca komen yang lain kurang cocok untuk newbie :' wkwk
ini akan jadi PR tambahan, karena BE harus maintain request_id nya, apalagi request banyak banget, maka harus siapin tabel khusus untuk menyimpan data request_id nya, dan ini gak scale , lebih baik fokus di unique column di tabel nya saja
Cara yg lebih elegan adlh dgn melakukan caching transaksi. BE akan menyimpan transaksi d chace. Jika transaksi selesai (sukses ataupun gagal) maka transaksi dihapus dr cache. Atau jika sdh lewat jangka waktu tertentu maka transaksi dihapus dr cache. Dan yg disimpan d cache cukup hasil hash dr data2 yg dikirimkan.
User call api POST, lalu cache di redis, jika sukses maka hapus data di redis, begitukah?
Jika sudah sukses lalu user call api tersebut lagi, apa yang terjadi?
Tapi jika dihapusnya berdasarkan jangka waktu tertentu, problem tersebut solved
@@adninsijawa445 yes... Semacam ini
@@adninsijawa445 biasanya disimpan dalam jangka waktu tertentu
bener.. saya nerapin ini. karna, darimana kita tau itu tidak disengaja, atau memang mau insert 2x? kalo cuma andelin check di db datanya exist atau ga, masi ada possibility jg dia double insert
terimakasih ilmunya mas..
Yup ,bener bnget.. kembali lagi ke case..
Ku pernah buat apps penjualan,
Ad case dimana cust mau buat invoice based on po.. di po ad 2 barang yg sama tpi beda record tpi qty beda..
Mereka maunya inputnya sma persis di PO (2record).
Jdi emang begitu wkwkwkw 😂😂😂
ini sih case bikin bum waktu kedepannya 😁
aku pernah juga om case begini, akhirnya bikin sistem konfirmasi aja. di UI, user dikasih prompt kalo POST request nya ada kemungkinan double request (dikasih restriction aja misalnya kalo request sebelumnya jarak terlalu deket, etc.) kalo user nya ok, dia konfirmasi dan UI akan kirim ulang request yg disertai sebuah flagging
Harus didefinisikan dahulu kondisi yang menyebabkan 2 objek/data adalah sama (equal). Kemudian, sebelum Backend memproses insert, harus dilakukan dulu pengecekan terkait kesamaan objek yang akan di-insert dengan objek-objek yang sudah eksis di database. Jika ada kesamaan objek yang akan di-insert dengan objek yang sudah eksis di database, maka muncul peringatan.
selama ada unique kolom, gak masalah, asal jangan tidak ada unique column, karena kalo request datang bareng2, maka secara otomatis dua dua nya waktu ngecek tidak akan dapat data, jadi dianggap masih kosong datanya, akhirnya dua dua nya akan create data baru
yg sederhana memang pake unik key, tinggal check klo data nya blum ada maka create jika udah ada maka ubah jadi update untuk mereplace.
Lebih baik tambah satu kolom yg isinya hasil hash dari kolom2 yg di insert (post) dan tipe kolom tersebut hrs unik.
Biasanya pake apa hashingnya ? Soalnya kalo datanya besar kan proses hashingnya makan CPU juga
@@dolanan5039 klo hashnya di sisi client nya gmana bang?
practice yang aku tau bisanya pake header "Idempotency-Key" yang digenerate di client, terus di store di table Request... setiap request POST yang masuk ke api akan selalu check table ini untuk memastikan requestnya ga double...
apakah idempotency keynya uuid aja?
kalau iya, gimana kalau requestnya timeout?
user/client akan retry, otomatis keynya ke generate baru kan? masih possible double insert
@@bakajwd697 iya mas pake uuid sebagai keynya, ketika user retry dia tetap pake key yg sama, kecuali di refresh halaman, atau ulangi prosesnya dari awal ...
@@bakajwd697 iya mas keynya pake uuid, ketika user retry tetap pake key yang sama, kecual user refresh halaman atau ulangin prosesnya dari awal...
@@bakajwd697 saya tadi reply kok hilang ya replynya
@@bakajwd697 iya mas key nya pake uuid, kalau retry masih pake key yang sama mas, kecuali user refresh halaman atau ulangi prosesnya dari awal
Sebenarnya idempotent di frontend ini simple, setiap request selalu buat state loading dan disable button untuk submit datanya, lalu clear form setelah prosesnya berhasil di submit, jadi kejadian double click dan ngirim data yang sama seharusnya ngga ada. Cuma terkadang buat frontend engineer yang kurang teliti, bisa aja state loading atau disablenya kelupaan, nah mungkin idempotent key bisa dibuat untuk prevent itu. Nah dengan case kaya gini, itulah kenapa unit test frontend ini perlu di implement.
jangan terlalu percaya request dari FE, apalagi di html nya, bisa gampang diakalin misal di inspect element untuk enabled lagi form nya
Coba baca konsep Atomic Lock, saya sering terapin di project, terutama kalau pakai Laravel udah ada fiturnya
double request kemungkinan besar race condition juga,
laravel bisa pake firstOrCreate atau updateOrCreate
bener ini
Kalau CRUD biasa emang bisa, Kalau Case nya pembayaran kan repot 😂
bikin part 2 pak, untuk case proses transaksi.
dulu pernah dapet kasus begini karena FEnya ga mau ubah (karena di apinya kalo dengan req sama akan muncul validasi duplicate) akhirnya, tampung respon pertama di redis, jika dalam waktu dekat ada request yang sama, jadikan response pertama di response kedua, jadi di FE seperti meruquest 1 aja
Kenapa malah terlihat ribet ya? Apakah dengan menggunakan state loading untuk melakukan disabled button tidak mengatasi?
dulu ngide pake rate limit di middleware khusus case beginian wkwk, jadi di middleware check berdasarkan endpoint dan user_id dibatasin max 1x
bisa juga pakai update and insert seperti di mongoDB, update kalau sudah ada datanya, insert kalau belum ada datanya
pak eko, saya request tutorial setup environment di VPS pak yang production ready 🙏
Eloquent laravel punya Upserts yang handling case ini nih 💥
tapi "kelemahannya" ya harus di define primary atau unique key, kalau enggak, gak bakalan jalan upsertnya
@@brainplusplus1 ia define aja skunya
kalo di prisma orm pake upsert ya pak? bisa cek kalo ada data dengan sku yang sama replace alias update kalo belum ada create
kalo misal fe nya pake react atau js framework yg lain. sesimple dibuat state loading buttonnya (ga bisa di klik hingga response selesai) dihandle dari sisi FE. nah tapi resiko juga sih misal manipulasi kode html atau js sehingga mekanisme state loading ga jalan atau yg aneh kondisi race dimana ada multi device masukin inputan yg sama dan dua2 nya berhasil. idealnya emg implement BE nya jga.
walalupun sudah dijaga di FE, tetep BE harus jaga juga, karena FE gampang di manipulasi oleh user, karena bisa di edit misal via inspect element
Iya sih, kalau misalkan kita ngirim POST untuk generate API Key, itu bisa problem sih, respondnya yang ketangkep yang pertama, yang kedua gk ke result.. yah jadinya invalid. Makasih banyak mas ilmunya 🙏
kang eko saya izin me re design website programmer zaman now untuk belajar mengimplementasikan hasil belajar saya, apakah boleh? kalo gak boleh gak apa2
ngerti cara kerja nya, tapi baru tau namanya indempoten 😅. paling ga bsa ngapalin istilah2 gini
Terimakasih pak Eko. Mau tanya pak, kalau ingin idempotent tapi ada kemungkinan racing condition pada method post. Gimana ya cara handle nya?
mungkin bisa menggunakan count data terakhir sebagai unique id. contoh user A sudah input 1, cek dengan db count row, result 1, data yg kedua yg akan diinsert adalah: count + 1 = 2, maka unique id = user uuid + 2. dalam kondisi race condition, 2 data yg diinsert akan sama unique id nya: user uuid + 2 (karena pengecekan db count terakhir sama2 count = 1) kalau ingin result error: maka cukup perintah sql insert, kalau ingin result sukses, maka perintahnya adalah sql replace (replace where unique id = "user uuid + 2"). setelah data 2 berhasil dimasukkan, dan selanjutnya user A akan input kembali, maka unique id nya: user uuid + 3. mohon koreksi kalau ada kesalahan. terima kasih
Pake insert ignore aja bisa gak si? 🤔
Asal salah satu fieldnya dibikin jadi unique
di beberapa bahasa pemograman bisa gunain upsert jika di support
Nggak kepikiran kalau ini yang namanya idempotent, yang ku paham ya pokoknya nggak ada entry double.
bisa di DB nya pakai composite key, atau uniqe kolom seperti yang dijelaskan di video
upsert (update or insert) adalah kunci
Bahas quarkus dong bang 😅
1. Darimana tau itu ga disengaja, atau emang sengaja mau insert 2x?
2. kenapa demonya sepsifik kasi usecase e-commerce? apaka ini titipan ordal kah? harusnya judulnya ganti. Handle double request pada E-COMMERCE 🤗
di issue / questionnya nanyain bestpractice... at least ada jg scenario2 lain... kaya timeout, ga punya "SKU", disengaja atau ga disengaja, dll
so, what is the best practice sir?
Nggak ada best practice sepertinya, karena kuncinya adalah di keunikan value dari data yang dikirim.
@@AmbriBlack tapi ini udah jadi issue yg umum pak. kalau yg di video kan mengandalkan unique constraint dari DB. sementara ada use case lain dimana secara data emang ga masalah kalau datanya dobel. mungkin karena emang disengaja mau buat datanya lebih dari satu aja gitu..
nah, tapi dobel yang ga disengaja karena faktor lain gimana validasinya?
@@bakajwd697 ya susah juga sih karena kebanyakan pada validasi unique data, ya meskipun misal ada cara mungkin kayak rate limiter tapi kadang itu juga nggak membantu.
Kemungkinan cara - cara yang udah ada cuman bisa meminimalkan kesalahan bukan menghilangkan sepenuhnya.
@@bakajwd697 itu kayanya banyak solusinya, di vidio itu bisa pakai tambahan kolom buat handlenya, bisa aja lu bikin unique tapi nanti kl casenya ky yg di video itu ya bakal kebingungan usernya knp error sebetulnya bisa pake prefix juga pas insert
use transactions and use rabbit MQ to handle queue
Kalau misal sku nya udh ada di dB tapi yg insert orng lain berarti ke update tidak pak? Apakah nanti ada pengecekan juga by created at nya?
Bisa juga
Kaget pake bahasa Inggris, audio track nya otomatis kepilih ya kwwk
pake upsert aja, create and update if exist
bisa, tapi tetap harus ada kolom yang unique
apakah jika data tidak di temukan ketika delete maka akan "Di Abaikan" sehingga responseya tetap 200 seperti ketika delete ?
204, commandnya sukses tp data tdk ditemukan
Pak request cara kerja Jwt refresh token pake bagan seperti ini pak🙏
coba di cari lagi di video bang, sepertinya sudah pernah di bahas
apakah idempotency ini menggunakan token csrf saja sudah cukup ??
tidak ada hubungannya antara idempotency sama csrf
anjay.., hasil setup mobile
hmm baru tau ada yg namanya idempotent
Sama
njir tiba tiba bahasa ingris
Skunya itu cara buatnya gimana pak
kaget suaranya gak kyk biasanya
❤❤❤❤❤
kenapa ga di pasang primary key di database utk yg unique,
dan di bbackend di kasih commit transaction, klo
kalau usernya memang beli iphone 2 kali gimana?
kalau untuk kasus insert transaksi seperti ini bisa ditambahin key misalnya 'x-idempotency-key' di header saat request api, bisa berupa uuid yang penting unique setiap request dari sisi client, nanti di backend check aja kalau nilai x-idempotency-key udah ada di cache bisa di skip process insert transaksinya.
@@ardhyui hmm kalau unique setiap request berarti backend ga akan bisa ngecek gasi?
Bedakan antara beli 2 kali (berarti 2 transaksi) dengan dobel transaksi (dobel post), yg dibahas disini terjadi dobel post, jadi transaksi yg sama kekirim (post) 2 kali sebelum proses transaksi selesai.
Transaksi disini bukan jual beli ya. Tapi transaksi sistem.
@@farrel6788 gak bisa gmn ya, kan tinggal bikin unique aja misalnya di tablenya di tambahin key unique untuk fieldnya misalnya idempotency_key, kalau insert yang sama pasti gagal, di sisi client juga bisa ditambahin fungsi misalnya pas on submit posisi tombolnya langsung disable biar gak double click. Di backend juga bisa di tambahin database locking biar row yang sedang diproses gak bisa diupdate sebelum transaksi selesai(commited).
Bisa juga ditambahin validasi misalnya untuk user id dan nominal yang sama transaksi gak bisa dilakukan dalam beberapa waktu / dikasih timeout. Intinya sih karena request POST itu engga idempotent gimana cara handlenya supaya data itu gak double input kalau terjadi masalah misalnya karena jaringan lemot / user double click dsb.
sebenernya tadi ga paham, kalau client ga sengaja ngirim dua request dan idempotency-key dari dua request itu berbeda, tapi setelah google2 lagi sudah paham
saya taunya impotent bg
suaranya beda ya?
Lagi serak
Iyaa haha bener, tadi awal buka pake hp kirain ini dari hp nya yg convert jadi english, pas buka pake PC sama ternyata wkwk
@@ProgrammerZamanNow ehhh serak.. kirain berak kang..
@@ProgrammerZamanNow bukan seraknya pa, audionya jadi bahasa inggris
Fitur baru audio track
pleasee pak pake bahasa indonesia ehe 🙏🏼
tinggal diganti aja itu di video nya, bahasa nya jadi Indonesia
@@ProgrammerZamanNow oh di audio track? nuhun kang eko 🙏🏼