મોડ્યુલ ફેડરેશન: માઇક્રો-ફ્રન્ટએન્ડ્સમાં રનટાઇમ મોડ્યુલ શેરિંગ માટેની નિર્ણાયક માર્ગદર્શિકા

વેબ ડેવલપમેન્ટના સતત વિકસતા ક્ષેત્રમાં, આપણે એક મહત્વપૂર્ણ આર્કિટેક્ચરલ પરિવર્તન જોયું છે. આપણે મોનોલિથિક આર્કિટેક્ચર્સથી બેકએન્ડ માઇક્રોસર્વિસ તરફ સફર કરી, જેમાં સ્કેલેબિલિટી અને ટીમની સ્વાયત્તતાની શોધ હતી. હવે, એ જ ક્રાંતિ ફ્રન્ટએન્ડમાં પરિવર્તન લાવી રહી છે. માઇક્રો-ફ્રન્ટએન્ડ્સનો યુગ આવી ગયો છે, અને તેના કેન્દ્રમાં એક શક્તિશાળી ટેકનોલોજી છે જે આ બધું વ્યવહારુ બનાવે છે: મોડ્યુલ ફેડરેશન.

માઇક્રો-ફ્રન્ટએન્ડ્સનો મુખ્ય પડકાર હંમેશા કહેવો સરળ રહ્યો છે પણ ઉકેલવો મુશ્કેલ છે: તમે બહુવિધ, સ્વતંત્ર રીતે ડિપ્લોય કરેલી એપ્લિકેશન્સમાંથી એક જ, સુસંગત વપરાશકર્તા અનુભવ કેવી રીતે બનાવી શકો છો, જેથી ધીમી, ભારે અને અપ્રબંધિત ગડબડ ન થાય? આપણે સામાન્ય કોડ, જેમ કે કમ્પોનન્ટ લાઇબ્રેરીઓ અથવા રિએક્ટ જેવા ફ્રેમવર્ક, વર્ઝનિંગની સમસ્યાઓ બનાવ્યા વિના અથવા સંકલિત રિલીઝ માટે દબાણ કર્યા વિના કેવી રીતે શેર કરી શકીએ?

આ એ સમસ્યા છે જેને મોડ્યુલ ફેડરેશન ખૂબ જ સુંદર રીતે હલ કરે છે. વેબપેક 5 માં રજૂ કરાયેલ, તે ફક્ત બીજું કોઈ ફીચર નથી; તે વેબ એપ્લિકેશન્સ બનાવવા અને ડિપ્લોય કરવા વિશેની આપણી વિચારસરણીમાં એક મોટો ફેરફાર છે. આ વ્યાપક માર્ગદર્શિકા મોડ્યુલ ફેડરેશન શું છે, શા માટે છે અને કેવી રીતે કામ કરે છે તે સમજાવશે, તેની સૌથી પરિવર્તનકારી ક્ષમતા પર ધ્યાન કેન્દ્રિત કરશે: રનટાઇમ મોડ્યુલ શેરિંગ.

એક ઝડપી રિકેપ: માઇક્રો-ફ્રન્ટએન્ડ્સ શું છે?

મોડ્યુલ ફેડરેશનની કાર્યપ્રણાલીમાં ઊંડા ઉતરતા પહેલાં, ચાલો આપણે માઇક્રો-ફ્રન્ટએન્ડ્સનો અર્થ સ્પષ્ટ કરી લઈએ. એક મોટી ઈ-કોમર્સ વેબસાઇટની કલ્પના કરો. મોનોલિથિક દુનિયામાં, આખો ફ્રન્ટએન્ડ — પ્રોડક્ટ સર્ચ, પ્રોડક્ટ વિગતો, શોપિંગ કાર્ટ અને ચેકઆઉટ — એક જ, મોટી એપ્લિકેશન છે. ચેકઆઉટ બટનમાં ફેરફાર કરવા માટે સમગ્ર એપ્લિકેશનનું પરીક્ષણ અને પુનઃ-ડિપ્લોયમેન્ટ કરવું પડી શકે છે.

માઇક્રો-ફ્રન્ટએન્ડ આર્કિટેક્ચર આ મોનોલિથને બિઝનેસ ડોમેન્સ મુજબ તોડે છે. તમારી પાસે આ મુજબ હોઈ શકે છે:

• એક સર્ચ ટીમ જે સર્ચ બાર અને પરિણામોના પેજની માલિક છે.
• એક પ્રોડક્ટ ટીમ જે પ્રોડક્ટ વિગતો અને ભલામણોની માલિક છે.
• એક ચેકઆઉટ ટીમ જે શોપિંગ કાર્ટ અને પેમેન્ટ પ્રક્રિયાની માલિક છે.

દરેક ટીમ એપ્લિકેશનના પોતાના ભાગને સ્વતંત્ર રીતે બનાવી, પરીક્ષણ કરી અને ડિપ્લોય કરી શકે છે. આનાથી ઘણા મુખ્ય ફાયદા થાય છે:

• સ્વાયત્ત ટીમો: ટીમો તેમના પોતાના સમયપત્રક પર કામ કરી શકે છે અને રિલીઝ કરી શકે છે, જે વિકાસને વેગ આપે છે.
• સ્વતંત્ર ડિપ્લોયમેન્ટ્સ: ભલામણ એન્જિનમાં બગ પેમેન્ટ ફ્લોમાંના કોઈ નિર્ણાયક અપડેટને અવરોધતું નથી.
• ટેકનોલોજીની સુગમતા: સર્ચ ટીમ Vue.js નો ઉપયોગ કરી શકે છે જ્યારે પ્રોડક્ટ ટીમ રિએક્ટનો ઉપયોગ કરે છે, જે ટીમોને તેમના ચોક્કસ ડોમેન માટે શ્રેષ્ઠ સાધન પસંદ કરવાની મંજૂરી આપે છે (જોકે આ માટે સાવચેતીપૂર્વક સંચાલન જરૂરી છે).

જોકે, આ અભિગમ પોતાની રીતે પડકારો ઉભા કરે છે, મુખ્યત્વે શેરિંગ અને સુસંગતતાની આસપાસ, જે આપણને જૂની પદ્ધતિઓ તરફ લઈ જાય છે.

કોડ શેર કરવાની જૂની પદ્ધતિઓ (અને તે શા માટે નિષ્ફળ જાય છે)

ઐતિહાસિક રીતે, ટીમોએ જુદી-જુદી ફ્રન્ટએન્ડ એપ્લિકેશન્સ વચ્ચે કોડ શેર કરવા માટે ઘણી પદ્ધતિઓ અજમાવી છે, જેમાં માઇક્રો-ફ્રન્ટએન્ડ સંદર્ભમાં પ્રત્યેકની નોંધપાત્ર ખામીઓ છે.

NPM પેકેજો

સૌથી સામાન્ય અભિગમ એ છે કે શેર કરેલા કમ્પોનન્ટ્સ અથવા યુટિલિટીઝને વર્ઝનવાળા NPM પેકેજ તરીકે પ્રકાશિત કરવું. એક શેર કરેલી કમ્પોનન્ટ લાઇબ્રેરી તેનું ઉત્તમ ઉદાહરણ છે.

• સમસ્યા: આ એક બિલ્ડ-ટાઇમ ડિપેન્ડન્સી છે. જો ટીમ A શેર કરેલા `Button` કમ્પોનન્ટને `my-ui-library` માં વર્ઝન 1.1 થી 1.2 માં અપડેટ કરે છે, તો ટીમ B અને ટીમ C ને તે અપડેટ ત્યાં સુધી નહીં મળે જ્યાં સુધી તેઓ જાતે તેમના `package.json` ને અપડેટ ન કરે, `npm install` ન ચલાવે, અને તેમના સંપૂર્ણ માઇક્રો-ફ્રન્ટએન્ડને ફરીથી ડિપ્લોય ન કરે. આ ચુસ્ત જોડાણ બનાવે છે અને સ્વતંત્ર ડિપ્લોયમેન્ટના હેતુને નિષ્ફળ બનાવે છે. તે બ્રાઉઝરમાં એક જ કમ્પોનન્ટના બહુવિધ વર્ઝન લોડ થવા તરફ પણ દોરી જાય છે, જે અંતિમ બંડલને મોટું બનાવે છે.

શેર કરેલા વર્કસ્પેસ સાથેના મોનોરેપોઝ

મોનોરેપોઝ (Lerna અથવા Yarn/NPM વર્કસ્પેસ જેવા સાધનોનો ઉપયોગ કરીને) બધા માઇક્રો-ફ્રન્ટએન્ડ્સને એક જ રિપોઝીટરીમાં રાખે છે. આ શેર કરેલા પેકેજોના સંચાલનને સરળ બનાવે છે.

• સમસ્યા: જ્યારે મોનોરેપોઝ ડેવલપરના અનુભવમાં મદદ કરે છે, ત્યારે તેઓ મુખ્ય રનટાઇમ સમસ્યાને હલ કરતા નથી. તમે હજી પણ બિલ્ડ-ટાઇમ ડિપેન્ડન્સી પર આધાર રાખો છો. શેર કરેલી લાઇબ્રેરીમાં ફેરફાર કરવા માટે હજી પણ બધી વપરાશકર્તા એપ્લિકેશન્સને ફેરફારને પ્રતિબિંબિત કરવા માટે પુનઃનિર્માણ અને પુનઃ-ડિપ્લોય કરવાની જરૂર છે.

`