saya masih belajar Untuk API saya biasa pakai struktur template seperti ini id : string , ini sama seperti request_id nya pak eko biasanya formatnya username+ Unix time took : number data : T extends Object | null error : K extends Object | null message : string Untuk yang error yang bagian errornya itu biasanya count : number | null , kalau error 429 form : T extends Record | null , ini buat error kalau validasi form gagal yang T itu sesuai interface form nya. untuk error yang sensitif misal errornya di class apa,SQL,line nya dimana di file apa itu gak dikirim ke response error, yang dikirim paling internal server error di message nya wkwk, informasi error seperti itu dikirimnya ke log Kalau pesan errornya kan udah ada di bagian message, Kalau status itu udah dikirim di back end nya, jadi yang diatas itu cuma isi response ya aja kurang lebih template nya seperti itu. Btw yang mau koreksi atau ngasih saran reply saja komentar ini, kita sama-sama belajar.
saya biasanya kalo error stack itu cuma sampe log level aja, ga sampe response ke front-end, kecuali sedang dalam development, jadi biasanya kita bikin kondisi, untuk non-production env, kita balikin error stack nya kedepan, biar kalo misalnya error nya ga di tangkap di backend, frontend, dan juga QA mungkin detect error tersebut saat proses development
hal yang perlu diimprove saat ini adalah kemampuan debugging, pengendalian error, yang seperti itu, bukan lagi cara membuat. karena barusan aku kesel aplikasi mobile banking error ga jelas tulisannya "mohon install apk nya dari playstore" lah apk aku dari dulu dari playstore njir sebelumnya lancar tau-tau error kayak gitu njir :( seharusnya sebelum release update itu di test sampe bener-bener ga ada bug, ini ada bug direlease, sekelas apk bank lagi yang digunakan orang banyak dan penting karena untuk bayar belanja mereka, tadi ga bisa beli jadinya padahal promo murah
mas mau tanya di menit 10:54 dijelaskan biasanya atau lebih baik errornya di detailkan gitu ya tapi masalahnya klw kita nemuin suatu error kan langsung di break mas, misal di username kurang panjang nah ini langsung di break dan di return jadi keputus tuh pengecekan lainnya apakah baiknya kita kalau nemuin error2 seperti ini baiknya di teruskan dulu pengecekannya agar mendapatkan validitas error message secara keseluruhan?
Halo Bang Eko, izin stich ya Saya rasa yg dimaksud di poin "Document common errors" (13:20) tuh agar yg bikin API menyertakan detil struktur pesan error, contoh dari pesan error-nya, dan saran buat mengatasi error-nya Misal dengan contoh dari Bang Eko di 15:41, maka di dokumentasi API baiknya dijelasin apa maksudnya UNIQUE, TOO_LONG, dan MUST_BE_LETTERS. Terus bisa juga dikasi tau apa yang bisa menyebabkan API me-return kode2 tersebut
@@ProgrammerZamanNow keknya maksudnya gt deh.. nanti dari "kode" error itu di translate di fenya jadi bahasa manusia, jadi dari sisi user tahu errornya apa (even banyak kasus user tetep tanya errornya kenapa 😁), kita sebagai programmer juga bisa pinpoin buat checkingnya lebih cepet (kasus di saay programnya memang gede dan macem2,, klo di saya biar sat set carinya)
Kang Eko, mau tanya Kalau ada kolom di db itu unique, tapi pakai soft delete juga, baiknya bagaimana ngasih tau ke client yang consume API kita? Kadang waktu cek di FE ga ada row itu, tapi waktu create gagal karena unique, waktu di cek di db ternyata ada tapi sudah di soft delete. Best practice nya bagaimana itu Kang
izin nanya bang, @21:20 kalo untuk edit data biasanya saya meletakkan id yang akan diedit pada hidden input (HTML+PHP), apakah cara ini tidak aman? bagaimana cara memvalidasi nya.. atau mengamankan nya?
aman harusnya, metod request post, karena modal id aja ga bakal bisa ngehack kalau ga ter autentifikasi, makanya pastiin api nya hanya bisa diakses yang sudah terautentifikasi
@@juancesarAndrianto itu buat user? yang buat developer gimana? kamu buat log ga? isi lognya kayak gimana? struktur datanya jelas sama kan sama-sama pakai database yang sama, ga dibedakan databasenya. bahkan kalau itu pesan error untuk user itu masih ga informatif kalau semua pesan error sama karena disetting lewat middleware, misal pesan error di middleware mu "error internal server" dengan kode 500, si user pas login salah memasukkan password dapat tulisan pesan error "error internal server", si usernya mikir gini tuh "waduh servernya error" alhasil dia akan nunggu servernya membaik bukan mengklik lupa password padahal errornya berkaitan dengan password, tetapi karena pesan errornya "error internal server" si user jadi ga ada pikiran buat klik lupa password, tapi malah nunggu server membaik padahal servernya udah baik, alhasil user ga pernah berhasil login karena dia tidak tau kalau yang error tuh passwordnya karena pesan errornya "error internal server"
nonton ini jadi ingat dulu pernah integrasi dengan "ekspedisi yang namanya sudah gede". detail error validationnya gak informatif banget hanya sekedar mengenai "field tidak sesuai dengan validasi". sudah begitu di dokumentasinya pun kurang jelas per field nya mengenai apa dan rules gimana. jadinya tiap ada error validasi mesti up ke group IT nya mengenai error tersebut.
![[LIVE] : ONE ลุมพินี 84 วันนี้!! คู่เอก "ก้องศึก vs เมืองไทย"](http://i.ytimg.com/vi/3kuzsAIDf1c/mqdefault.jpg)
{message, data}
struktur terbaik sejauh ini sejak 2014 gua implement Rest API
Status Code: 200 OK
Body:
{
status: "error"
}
😅
Bang Eko bahas backup data di production dong baiknya seperti apa 🙌🏻🔥🙌🏻
saya masih belajar
Untuk API saya biasa pakai struktur template seperti ini
id : string , ini sama seperti request_id nya pak eko biasanya formatnya username+ Unix time
took : number
data : T extends Object | null
error : K extends Object | null
message : string
Untuk yang error yang bagian errornya itu biasanya
count : number | null , kalau error 429
form : T extends Record | null , ini buat error kalau validasi form gagal yang T itu sesuai interface form nya.
untuk error yang sensitif misal errornya di class apa,SQL,line nya dimana di file apa itu gak dikirim ke response error, yang dikirim paling internal server error di message nya wkwk, informasi error seperti itu dikirimnya ke log
Kalau pesan errornya kan udah ada di bagian message,
Kalau status itu udah dikirim di back end nya, jadi yang diatas itu cuma isi response ya aja kurang lebih template nya seperti itu.
Btw yang mau koreksi atau ngasih saran reply saja komentar ini, kita sama-sama belajar.
saya biasanya kalo error stack itu cuma sampe log level aja, ga sampe response ke front-end, kecuali sedang dalam development, jadi biasanya kita bikin kondisi, untuk non-production env, kita balikin error stack nya kedepan, biar kalo misalnya error nya ga di tangkap di backend, frontend, dan juga QA mungkin detect error tersebut saat proses development
Agak susah sih kalau responnya acak" di saat harus consume api di type language, bikin banyak model respon yang perlu dibuat.
kadang males ngingetin krna takut di anggap nambah2in kerjaan, eh malah saya yg kbagian frontend yg keteteran 😫
hayok pindah jalur ke BE, wkwkwk
debug mode matiin, selalu gunakan try catch untuk meng-override exception
Saya tau tuh yg dibahas sama bapak yg "error":"errors" 😂😂
Salah satu api yg sering bgt dipake di Indonesia 🤣🤣🤣
kalo di express cukup gini aja (res.status(xxx).json({ data: .. })) atau dituliskan status codenya juga di jsonnya?
hal yang perlu diimprove saat ini adalah kemampuan debugging, pengendalian error, yang seperti itu, bukan lagi cara membuat. karena barusan aku kesel aplikasi mobile banking error ga jelas tulisannya "mohon install apk nya dari playstore" lah apk aku dari dulu dari playstore njir sebelumnya lancar tau-tau error kayak gitu njir :( seharusnya sebelum release update itu di test sampe bener-bener ga ada bug, ini ada bug direlease, sekelas apk bank lagi yang digunakan orang banyak dan penting karena untuk bayar belanja mereka, tadi ga bisa beli jadinya padahal promo murah
mau bertanya, kalau yang menentukan semua edge case itu apakah developer nya saja? atau dari QA? atau semua?
terhitung 3 kali divideo ini Pak Eko bilang "saya sih gak pernah ngasih status code" haha. bener2 keukeuh ceuk sunda mah . 😁
HTTP Status 418 : I'm a teapot
Kang eko mau pembahasan bikin loging error yg pakai request_id itu ya
atau ada source video contohnya ga ya . Nuhun kang 🙂
bener banget pak eko kalo response error nya gak informatif seperti itu, seakan akan kita menerawang sendiri dimana errornya bagai seorang spiritual😁
kalau error array seperti itu, di frontend nampilinnya cuma 1 aja atau gimana ya?
mas mau tanya di menit 10:54 dijelaskan biasanya atau lebih baik errornya di detailkan gitu ya
tapi masalahnya klw kita nemuin suatu error kan langsung di break mas, misal di username kurang panjang nah ini langsung di break dan di return jadi keputus tuh pengecekan lainnya
apakah baiknya kita kalau nemuin error2 seperti ini baiknya di teruskan dulu pengecekannya agar mendapatkan validitas error message secara keseluruhan?
harusnya temuin semua error dulu, di tiap teknologi udah ada validation framework, gak perlu satu2 lagi pake if else
Pak ada rencana buat bikin course belajar python?
Pak Eko ada niatan untuk buat materi Laravel Zero ga ?
22:53 bash script di dalam format extension file jpg atau png emang di eksekusi ? perasaan ga bisa
Pak Eko, ingin bertanya apakah bahasa low level seperti c/c++ worth di pelajari untuk loker indonesia
masih dikit kalo di indonesia
Smith Dorothy Perez Mark Lewis George
sangat bermanfaat mas eko bagi saya yang suka asal kasih message wkwk. terima kasih
Halo Bang Eko, izin stich ya
Saya rasa yg dimaksud di poin "Document common errors" (13:20) tuh agar yg bikin API menyertakan detil struktur pesan error, contoh dari pesan error-nya, dan saran buat mengatasi error-nya
Misal dengan contoh dari Bang Eko di 15:41, maka di dokumentasi API baiknya dijelasin apa maksudnya UNIQUE, TOO_LONG, dan MUST_BE_LETTERS. Terus bisa juga dikasi tau apa yang bisa menyebabkan API me-return kode2 tersebut
Benar
yang penting itu important
klo status code disaya itu biasanya berupa "code" tertentu untuk translate message error spesifik kebutuhan bisnis... misal ERCA001 dkk gt lah bang
cocok untuk mesin, gak cocok untuk manusia, orang bingung dengan error kode seperti ini
@@ProgrammerZamanNow keknya maksudnya gt deh.. nanti dari "kode" error itu di translate di fenya jadi bahasa manusia, jadi dari sisi user tahu errornya apa (even banyak kasus user tetep tanya errornya kenapa 😁), kita sebagai programmer juga bisa pinpoin buat checkingnya lebih cepet (kasus di saay programnya memang gede dan macem2,, klo di saya biar sat set carinya)
@@samuelhandoko5320yap gua juga nambahin itu biar ngetracenya mudah
ERCA001 : Error Response Code Application no. 001
#I'mRobot
Kang Eko, mau tanya
Kalau ada kolom di db itu unique, tapi pakai soft delete juga, baiknya bagaimana ngasih tau ke client yang consume API kita?
Kadang waktu cek di FE ga ada row itu, tapi waktu create gagal karena unique, waktu di cek di db ternyata ada tapi sudah di soft delete.
Best practice nya bagaimana itu Kang
Waktu soft delete, jadiin null kolom unik nya
di postgres bisa pakai
CREATE UNIQUE INDEX index_unique_users_email ON "users" USING btree(email) WHERE deleted_at IS NULL;
3735 Constantin Motorway
Paling bete ketika respon error tapi messagenya 200😊😅😅😅😅😅😮😮😢😢😢
jadi maksutnya sukses diproses tapi juga eror😂
@@reinjin2371 di hasil response nya error
Tapi status yg dibuat dari back end 200 wkwkwk
Pass magang nih, APInya kek gini ngesellin, semuanya 200OK 🥴
konsisten, bersih dan informatif adalah koentji
Pak review lok bit 32 dong
Ini ni yang bikin sering berantem fe sama be wkwwkkw
{status:200,message:"bad request",data:[]} 😂😂
izin nanya bang,
@21:20
kalo untuk edit data biasanya saya meletakkan id yang akan diedit pada hidden input (HTML+PHP), apakah cara ini tidak aman? bagaimana cara memvalidasi nya.. atau mengamankan nya?
Ngirim datanya lewat fetch bang
aman harusnya, metod request post, karena modal id aja ga bakal bisa ngehack kalau ga ter autentifikasi, makanya pastiin api nya hanya bisa diakses yang sudah terautentifikasi
biasa bikin API pke apa nih ?
Pak eko masih sodaraan sama leon kennedy ?
kalau ak tak bikin middleware global jadi response erorr dan response suksesnya itu sama semua
wa ini salah kayaknya bang, kalau gitu kan nanti erro database sama error akun sama pesan errornya, alhasil bingung
@@Fuji-gn9nx kalau error db misal, code 500 langsung lempar aja errror nya yang penting struktur datanya sama baik error atau yang sukses.
@@juancesarAndrianto itu buat user? yang buat developer gimana? kamu buat log ga? isi lognya kayak gimana? struktur datanya jelas sama kan sama-sama pakai database yang sama, ga dibedakan databasenya. bahkan kalau itu pesan error untuk user itu masih ga informatif kalau semua pesan error sama karena disetting lewat middleware, misal pesan error di middleware mu "error internal server" dengan kode 500, si user pas login salah memasukkan password dapat tulisan pesan error "error internal server", si usernya mikir gini tuh "waduh servernya error" alhasil dia akan nunggu servernya membaik bukan mengklik lupa password padahal errornya berkaitan dengan password, tetapi karena pesan errornya "error internal server" si user jadi ga ada pikiran buat klik lupa password, tapi malah nunggu server membaik padahal servernya udah baik, alhasil user ga pernah berhasil login karena dia tidak tau kalau yang error tuh passwordnya karena pesan errornya "error internal server"
Keren
10:18 kurang fokus nih pak eko, bilangnya 200 karakter tapi yang muncul angaka 20 😄
AI nya belum bisa nebak isi pikiran saya sepertinya
@@ProgrammerZamanNow pak ada pembahasan multitenant architecture ga ?
pake joi/zod bagus ga pak eko ?
bagus, di kelas saya pake itu
@@ProgrammerZamanNow siap pakk.
nonton ini jadi ingat dulu pernah integrasi dengan "ekspedisi yang namanya sudah gede". detail error validationnya gak informatif banget hanya sekedar mengenai "field tidak sesuai dengan validasi". sudah begitu di dokumentasinya pun kurang jelas per field nya mengenai apa dan rules gimana. jadinya tiap ada error validasi mesti up ke group IT nya mengenai error tersebut.
dan semoga sekarang sudah gak seperti tahun kemaren lagi
kapankah kita butuh grpc?
Kalau make golang
@@slingingslasher7427make semua bahasa bisa ga hanya golang
Status, messages, resources
tiap error dikirim "something bad happened" biar errornya bikin penasaran banyak orang 🤣🤣
diri sendiri bilek : "sorry ya aku ini sebenernya programmer yang susah di tebak....