Lab

Selesai · 100%

Product Feed Toolbox

Tool lokal yang gue bikin buat bantu validate, convert, compare, prettify, dan publish product feed JD Sports yang ukurannya terlalu besar buat dicek manual.

Utility Tool

Gambaran umum

Status
Selesai
Kemajuan
100%
Tingkat kesulitan
Challenging
Mulai
26 Jul 2026

Stack & alat

Teknologi
HTMLCSSJavaScriptPython 3Shell scriptJSONXLSX exportcurlUNBXD Feed APILocal HTTP server
Perangkat lunak
CodexLocal browserTerminalUNBXD staging feed service

01 / ALASAN DIBUAT

Kenapa gue bikin ini

Awalnya gue bikin ini karena gue pengen ikut bantu ngetest hasil development dari team BE. Product feed ini bisa berisi 80k+ products, jadi jelas nggak mungkin gue cek satu per satu secara manual. Gue butuh tool yang bisa bantu nemuin potential issue yang nggak sesuai requirement atau dokumentasi. Awalnya keliatan simple: ubah casing variantID, tambahin prefix v_, dan cleanup beberapa attribute. Tapi begitu mulai dipakai buat QA, kebutuhannya berkembang jadi validator dan compare tool juga.

02 / MASALAH YANG DIEKSPLORASI

Apa yang ingin gue pahami atau selesaikan

Product feed besar itu susah banget direview manual. Perbedaan kecil kayak casing attribute, prefix variant, field kosong, atau struktur operation bisa bikin indexing error atau issue di frontend. Feed-nya juga punya beberapa mode. Full feed selalu add, sementara delta bisa add, update, atau delete. Jadi tool ini nggak cukup cuma parse JSON, tapi juga harus ngerti struktur feed yang lagi dicek. Yang paling penting, report-nya harus bisa dibaca manusia. Raw JSON diff mungkin technically benar, tapi kurang membantu kalau pertanyaannya adalah “SKU mana yang berubah, attribute apa yang beda, dan ini penting atau nggak?”

03 / PENDEKATAN

Gimana idenya dibawa jadi sesuatu yang bisa dicoba

Gue mulai dari script Python kecil buat transform attribute di dalam variants. Script ini menjaga variantId tetap tanpa prefix, mengubah variantID jadi variantId, menambahkan prefix v_ ke attribute variant lain, dan menghapus beberapa field parent atau variant yang nggak dibutuhkan. Setelah itu gue bikin versi web app lokal supaya file JSON bisa di-upload lewat browser, dipilih feed type-nya, lalu output-nya bisa langsung di-download tanpa harus jalanin command manual. Lama-lama app-nya berkembang jadi beberapa tab: Convert, Prettify, Validate, dan Compare. Dengan dipisah begini, workflow-nya jadi lebih jelas. Untuk Compare, gue bikin lebih general. Bukan cuma before-after, tapi File 1 dan File 2 bisa dipakai buat compare dua source atau dua snapshot berbeda. uniqueId dipakai sebagai identifier utama, lalu report-nya dikelompokkan per product, variant, price, availability, categoryPath, dan schema. Ada juga fitur publish ke UNBXD dengan routing full/delta dan status polling, karena response upload belum tentu berarti indexing sudah selesai.

04 / CATATAN LAPANGAN

Awalnya cuma cleanup feed

Versi awalnya fokus ke satu requirement yang spesifik: semua attribute di dalam variants perlu ditambah prefix v_, kecuali variantId. Ada juga issue case-sensitive, karena variantID harus diubah jadi variantId.

Detail kayak gini gampang banget kelewat kalau dicek manual di feed besar, tapi efeknya bisa besar kalau downstream system strict soal format.

Validation ternyata sama pentingnya

Setelah converter jalan, gue sadar problemnya bukan cuma “ubah feed”. Gue juga perlu tahu apakah feed itu sudah valid sebelum di-export atau di-publish.

Dari situ validation flow mulai berkembang: cek prefix variant, casing variantId, struktur variants, value kosong atau null, dan collision antara uniqueId dan variantId.

Compare harus bisa dibaca manusia

JSON diff biasa kurang membantu buat QA product feed. Yang gue butuh adalah report yang langsung menjawab: product mana yang hilang, SKU mana yang berubah, attribute apa yang beda, datatype-nya berubah atau nggak, price berubah gimana, availability beda di mana, dan categoryPath masih equivalent atau nggak.

Makanya Compare tab gue bikin makin terstruktur. Price-related fields digabung jadi satu row per SKU. Availability juga dipisah jadi section sendiri supaya product availability dan variant availability bisa kelihatan lebih jelas.

Publish butuh tracking

Publish ke UNBXD juga punya tantangan sendiri. Upload bisa accepted, tapi hasil indexing baru kelihatan setelah dicek ke status endpoint.

Karena itu tool ini punya polling dan local log, supaya proses upload dan indexing bisa dilacak pakai timestamp, bukan cuma nebak dari response pertama.

05 / PELAJARAN

Project ini ngingetin gue kalau QA tool nggak harus mulai dari sistem besar. Kadang versi yang paling berguna justru mulai dari script kecil buat satu aturan format yang ngeselin.

Makin dipakai, makin kelihatan kalau value utamanya bukan cuma automation. Yang lebih penting adalah bikin feed besar jadi bisa direview manusia lewat report yang rapi dan kebaca.

Gue juga belajar kalau workflow publish harus dibuat lebih hati-hati. Response upload yang success belum tentu berarti indexing sudah success, apalagi kalau sistem cuma bisa proses satu file dalam satu waktu.

NGOBROL YUK

Ada yang menarik untuk dibahas?

Soal product, system, sesuatu yang lagi lo bangun, atau sekadar pengen tukar pikiran? boleh banget diobrolin.