1. Texnologiyani tanlash ortida: berilgan muhit (Ag-Grid)ning maksimalizatsiyasi va TypeScript ehtiyoji
Loyihaning eng katta vazifalaridan biri foydalanuvchilarga yuzlab minglab ma'lumotlarni tez va intuitiv ravishda ko'rish imkoniyatini taqdim etish edi. Ayniqsa, oddiy ko'rish darajasidan farqli o'laroq, Excelga o'xshash foydalanuvchi tajribasini taqdim etish kerak bo'lganligi sababli talablarning murakkabligi juda yuqori edi.
Foydalanuvchilar quyidagi funksiyalardan tabiiy ravishda kutgan edilar.
● Real vaqt rejimida qidirish va filtr qilish
● Ustunliklar va qayd etish
● Bir nechta tanlash
● Rulash optimizatsiyasi va katta hajmdagi ma'lumotlarni render qilish
● Excel yuklab olish
Men loyiha joriy etilganda, bunday katta hajmdagi ma'lumotlarni qayta ishlash uchun mo'ljallangan Ag-Grid asosidagi React ilgari asosiy komponent sifatida joriy etilgan edi. Oddiy HTML Table brauzer DOM'iga ortiqcha yuklanish sababli qabul qilinmaydigan darajadagi ma'lumotlarni o'z ichiga olgan edi, shuning uchun virtual aylanishni (Virtual Scrolling) asosiy qo'llab-quvvatlovchi Ag-Grid'ni joriy etish zaruriy tanlov edi.
Mening asosiy vazifam allaqachon joriy etilgan Ag-Grid'ning samaradorligini chegara darajasigacha oshirish va talablarimga muvofiq moslashtirish edi. Ag-Grid tomonidan taklif qilinayotgan server tomonidagi Row Model, ko'p tartib, maxsus Cell Rendererlardan foydalanib, o'n minglab ma'lumotlarni ham silliq qayta ishlashni optimallashtirdim.
Bundan tashqari, loyiha TypeScriptni majburiy ravishda qo'llagan. Xizmatning hajmi kattalashgan sayin, API javob tuzilishi va holatni boshqarish tuzilishi tobora murakkablashdi. Faqat JavaScriptdan foydalanilganda, ko'pincha ishga tushirish paytida xatolarni aniqlash holatlari paydo bo'lgan, ammo API javob tuzilishini interfeys asosida aniq belgilash orqali buni hal qildik.
● API Javob Interfeysi
● Grid Row Model / Domain Type
● State Type / Event Payload Type
Natija kodini ko‘rganimda ma'lumotlar tuzilishini darhol tushunib oldim va hamkorlik jarayonida kommunikatsiya xarajatlarini sezilarli darajada kamaytirdim.
2. Arxitektura loyihalash va qatlamlarni ajratish: ikki marta loyiha tajribasi
Loyihalar tobora kengayib borar ekan, oddiy funktsiyalarning amalga oshirilishidan ko'ra texnik xizmat ko'rsatish va tuzilmaning barqarorligi ancha muhim bo'lib qoldi. Men ikki xil vaqtda o'tgan loyihalarda, frontend arxitekturasining dastur ishlab chiqarish samaradorligi va texnik xizmat ko'rsatishga ta'sirini bevosita his qilganimni ayta olaman.
Birinchi marta tajriba o'tgan loyihada View-Stub-State tuzilmasidan foydalanilishi kerak edi. Ushbu tuzilma bo'yicha funktsiya bo'yicha papkalarni ajratib, har bir qatlamning roli aniq belgilangan.
● Ko'rish: to'liq UI tasvirlash bo'yicha mas'ul
● Stub: API aloqasi va domen biznes mantiqi bo'yicha mas'ul
● Holat: Jami holat va biznes holatini boshqarish
Bunday tuzilmaning eng katta afzalligi "loyihaning oqimini tezda tushunish imkoniyatidir". Haqiqatan ham, men yangi ishlab chiqaruvchi sifatida loyihaga birinchi bor kiritilganda, ushbu aniq qatlam ajratilishi tufayli funktsiyaga oid tuzilmani osonlik bilan tushunib, onboarding vaqtini sezilarli darajada qisqartira oldim. Funktsional mustaqillik yuqori bo'lib, saqlash va kengayish jihatidan ham a'lo bo'ldi.
Shundan so'ng ikkinchi loyiha Container-Presenter shablonidan foydalangan. Ushbu shablon UI renderingini (Presenter) va biznes mantiqni (Container) ajratishning an'anaviy tuzilmalaridan biridir.
Ushbu tuzilmaning afzalliklari qiziqishlarni ajratish (Separation of Concerns) aniq bo'lishiga ega edi. Presenterni to'liq UI komponenti sifatida saqlab qolish imkoniyati, testlash va qayta ishlatish imkoniyatlarini yaxshilaydi. Ammo xizmatning hajmi oshib va murakkablashgan so'ng, eski View-Stub-State tuzilmasiga qaraganda cheklovlar ko'rinadigan bo'la boshladi.
● Papka tuzilishi murakkabligi oshishi
● Holat boshqaruvining tarqalishi
● Domen tuzilmalarining takrorlanishi va API tuzilmasini boshqarishdagi qiyinchiliklar
Natijada, ikkita arxitekturani ham boshdan kechirish orqali, uzoq muddatli faoliyat yuritadigan yirik loyihalar uchun domen tuzilmalarini va holatlarini yanada nozikroq ajratish, View-Stub-State shaklidagi funktsional modulizatsiya foydaliroq bo'lishi mumkinligi haqida tushuncha oldim.
3. Katta hajmli ma'lumotlarni qayta ishlashni optimallashtirish tajribasi
Katta hajmli ma'lumotlarni qayta ishlash, faqatgina ekran orqali ma'lumotlarni ko'rsatishdan boshqa muammo edi. Ayniqsa, allaqachon joriy etilgan Ag-Grid muhitida, renderlash samaradorligi va holatni boshqarish optimallashuvi juda muhim edi.
Dastlab, ma'lumotlar o'zgarganda butun Grid qayta chizilayotganda aylanish kechikishi, brauzer xotirasi oshishi kabi muammolar yuzaga kelardi. Buni hal qilish uchun bir nechta optimizatsiya strategiyalarini qo'lladik.
Eng birinchi qo'llanilgan narsa React.memo asosidagi chizish optimizasiyasidir. Cell Renderer va Row Component-ni xotiraga olish orqali keraksiz qayta chizishlarni kamaytirdik. Shuningdek, useMemo va useCallback'ni faol ravishda ishlatdik. Ayniqsa Ag-Grid'da ustun ta'rifi ob'ekti tez-tez qayta yaratilsa, Grid butunlay qayta boshlanadigan muammo mavjud bo'lganligi sababli, buni useMemo bilan yaxshilab mustahkamlab qo'ydik.
Bundan tashqari, tarmoq yukini va dastlabki yuklash vaqtini kamaytirish uchun server tomoni sahifalash tuzilmasini takomillashtirdik. Qidirish va saralash mantiqini mijozdan emas, balki serverdan ishlashga o'tkazganimizdan, brauzer yukini ancha kamaytirdik va haqiqiy ishlash muhitida o'n minglab ma'lumotlarni barqaror qayta ishlash tuzilmasini yakunladik.
4. Muammo hal qilish tajribasi: Ma'lumotlar to'g'riligi va asinxron hodisalarni boshqarish
Loyiha doirasida eng ko'p xal qilishga to'g'ri kelgan masalalardan biri - bu bildirishnoma xizmatining ma'lumot mosligi muammosi edi. Bitta metod ichida DB bildirishnoma yozuvlarini saqlash va tashqi API xabarlarini yuborish bir vaqtda amalga oshirildi.
Muammo tashqi API chaqirig'idan keyin istisno yuzaga kelganda va DB tranzaktsiyasi qaytarilganida sodir bo'ldi. Foydalanuvchi bildirishnomani oldi, ammo tizimda yozuv qoldirmasligi jiddiy moslik xatosini keltirib chiqardi. Tashqi API chaqirig'i asosan DB tranzaktsiyasi bilan bir xil atomlikni kafolatlay olmadi.
Natijada loyiha tadbirga asoslangan asinxron ishlov berish tuzilmalarini joriy etdi. Asosiy g'oya “DBni tasdiqlagandan so'nggina tashqi ishlarni bajarish” edi.
1. Asosiy biznes mantiq va DB saqlashni amalga oshirish
2. DB tranzaktsiya commit bajarilganda voqea chiqariladi
3. Alohida voqea ishlov beruvchi xabar yuborishni mustaqil ravishda qayta ishlaydi (asosiy tranzaktsiyadan ajratilgan)
Ushbu struktur orqali DB saqlash muvaffaqiyatsiz bo'lgan taqdirda xabar ham yuborilmaydi, tashqi API muvaffaqiyatsiz bo'lsa ham asosiy biznes mantiqiga ta'sir ko'rsatmaydi, mukammal tarzda izolyatsiya qilish imkonini berdi.
5. Hamkorlik va saqlash nuqtai nazaridan yaxshilanish samaralari
Frontend loyiha vaqt o'tishi bilan komponentlar va holat boshqaruv tuzilmasi tezda murakkablashishini anglatadi. Ikkita yirik loyiha orqali o'rganganimning eng katta foydasi - dastlabki arxitektura loyihalash va tiplarni belgilash, hamkasblar bilan hamkorlikka qanchalik katta ta'sir ko'rsatishini his qilishdir.
TypeScript orqali API javobini umumiy tipda boshqarish natijasida, backend bilan ma'lumot tuzilmasini tushunish ancha intuitiv bo'ldi. Shuningdek, View-Stub-State kabi aniq qatlamli arxitektura tajribasi orqali, ma'lum funktsiyani o'zgartirishda yon ta'sirlarni minimallashtirish usulini tushundim.
Kod tekshiru sifatlari tabiiy ravishda oshdi. Strukturasi bir xil bo'lgani sababli amalga oshirish uslubini tushunishga sarflanadigan vaqt qisqarib, biznes mantiqiga e'tibor qaratish mumkin bo'ldi.
6. Yakun
Ushbu loyihalar nafaqat React interfeysini amalga oshirishdan iborat edi, balki katta hajmdagi ma'lumotlar muhitida arxitektura dizayni va ishning barqarorligi qanchalik muhimligini chuqur his qilish imkonini beradigan vaqt bo'ldi.
Ag-Grid kabi ajoyib vosita allaqachon berilgan bo'lsa-da, buni loyiha talablariga mos ravishda sozlash va optimallashtirish jarayoni hech qachon oddiy bo'lmagan. Shuningdek, turli xil ikki xil frontend arxitekturani birma-bir tajriba qilib, jamoaning hajmi va xizmat xususiyatlariga mos struktura dizayni zarurligini o'rgandim.
Natijada, ushbu tajribalar oddiy funktsiyani amalga oshirishdan ko'ra ko'proq ma'noga ega bo'ldi va keyinchalik katta hajmdagi React asosidagi tizimlarni loyihalash va muammolarni hal qilishda barqaror mustahkam asos bo'ladi.
LEE DAVID