- માઇક્રોફ્રન્ટેન્ડ્સ બ્રાઉઝર UI પર માઇક્રોસર્વિસ સિદ્ધાંતો લાગુ કરે છે, મોટા ફ્રન્ટએન્ડ્સને ક્રોસ-ફંક્શનલ ટીમોની માલિકીના સ્વાયત્ત, ડોમેન-ઓરિએન્ટેડ સ્લાઇસેસમાં વિભાજીત કરે છે.
- એકીકરણ DOM, કસ્ટમ એલિમેન્ટ્સ, મોડ્યુલ ફેડરેશન અને એપ્લિકેશન શેલ પર આધાર રાખે છે જે રૂટીંગ, સુરક્ષા, રચના અને શેર્ડ લાઇબ્રેરીઓનું સંચાલન કરે છે.
- React, Angular અને Next.js જેવા ફ્રેમવર્ક, BFF, ઇવેન્ટ બસો અને લેઝી લોડિંગ જેવા પેટર્ન સાથે, સ્કેલેબલ, સ્થિતિસ્થાપક અને અવલોકનક્ષમ માઇક્રોફ્રન્ટેન્ડ સિસ્ટમ્સને સક્ષમ કરે છે.
- માઇક્રોફ્રન્ટેન્ડ્સ આર્કિટેક્ચરલ જટિલતા ઉમેરે છે પરંતુ મોટા, બહુ-ટીમ ઉત્પાદનોમાં ફળ આપે છે જ્યાં સ્વતંત્ર જમાવટ, ક્રમિક સ્થળાંતર અને વિભિન્ન સ્કેલિંગ મહત્વપૂર્ણ છે.

માઇક્રોફ્રન્ટેન્ડ્સ સૌથી વધુ ચર્ચિત ફ્રન્ટએન્ડ આર્કિટેક્ચર પેટર્નમાંનું એક બની ગયું છે. ક્લાસિક સિંગલ-પેજ મોનોલિથ કરતાં વધુ સારી ટીમો માટે. જ્યારે તમારી પાસે ડઝનબંધ ડેવલપર્સ સમાન કોડબેઝને સ્પર્શ કરતા હોય છે, ત્યારે રિલીઝ સાયકલ ધીમી પડી જાય છે, રીગ્રેશન બધે જ શરૂ થાય છે અને નાના UI ફેરફારોને અચાનક મોટા સંકલનની જરૂર પડે છે. માઇક્રોફ્રન્ટેન્ડ્સ UI ને સ્વતંત્ર રીતે બનાવેલા અને ઉપયોગમાં લેવાતા ટુકડાઓમાં કાપીને બરાબર તે સમસ્યા પર હુમલો કરે છે.
આ માર્ગદર્શિકામાં આપણે માઇક્રોફ્રન્ટેન્ડ્સ શું છે, તેઓ શા માટે દેખાયા, તેઓ માઇક્રોસર્વિસિસ સાથે કેવી રીતે સંબંધિત છે તે વિશે વાત કરીશું., ડિઝાઇન કરતી વખતે તમારે કયા મુખ્ય વિચારોનો આદર કરવો જોઈએ, અને React, Angular, Next.js, Web Components, Webpack Module Federation અને Single-SPA જેવી ટેકનોલોજીઓ સાથે વ્યવહારમાં તેઓ કેવી રીતે કાર્ય કરે છે તે વિશે. અમે વાસ્તવિક સ્થાપત્ય પેટર્ન, સારી પ્રથાઓ, સામાન્ય મુશ્કેલીઓ અને અલગ માઇક્રોફ્રન્ટેન્ડ તરીકે અમલમાં મૂકાયેલ ઉત્પાદન કેટલોગ અને કાર્ટ જેવા નક્કર ઉદાહરણોનો પણ અભ્યાસ કરીશું.
માઇક્રોફ્રન્ટેન્ડ્સ શું છે અને તે શા માટે દેખાયા?
"માઈક્રો ફ્રન્ટએન્ડ્સ" શબ્દ 2016 ની આસપાસ થોટવર્ક્સ ટેકનોલોજી રડારમાં લોકપ્રિય થયો હતો. એક ખૂબ જ નક્કર વલણના જવાબ તરીકે: બેકએન્ડ આર્કિટેક્ચર્સ માઇક્રોસર્વિસિસ તરફ આગળ વધી રહ્યા હતા, પરંતુ બ્રાઉઝર બાજુ એક જ ટીમની માલિકીની મોટી, બરડ મોનોલિથ રહી. સમય જતાં તે "ફેટ ક્લાયન્ટ" SPA વિકસિત થવું મુશ્કેલ બને છે, ભલે બેકએન્ડ નાની સેવાઓમાં સારી રીતે વિભાજિત હોય.
માઇક્રોફ્રન્ટેન્ડ એ મૂળભૂત રીતે બ્રાઉઝર UI પર લાગુ કરાયેલ માઇક્રોસર્વિસ વિચાર છે.: એક મોટા ફ્રન્ટએન્ડ રિપોઝીટરીને બદલે, તમે બહુવિધ નાના, સ્વ-સમાયેલ એપ્લિકેશનોમાંથી યુઝર ઇન્ટરફેસ કંપોઝ કરો છો. દરેક પાસે એક સ્પષ્ટ વ્યવસાય ડોમેન છે (ઉદાહરણ તરીકે, "ચેકઆઉટ", "પ્રોડક્ટ શોધ", "વિદ્યાર્થી પ્રોફાઇલ્સ") અને તેને તેના પોતાના કેડન્સ પર બનાવી, પરીક્ષણ અને જમાવી શકાય છે.
જેમ માઇક્રોસર્વિસિસ બેકએન્ડ લોજીકને અલગ ડિપ્લોયેબલ યુનિટ્સમાં વિભાજીત કરે છે, તેમ માઇક્રોફ્રન્ટેન્ડ્સ ફ્રન્ટએન્ડને વર્ટિકલ સ્લાઇસેસમાં વિભાજીત કરે છે. જે ડેટાબેઝ અથવા API થી લઈને બેકએન્ડ સુધી, યુઝર ઇન્ટરફેસ સુધી ફેલાયેલા હોય છે. એક ક્રોસ-ફંક્શનલ ટીમ ડેટા સ્કીમાથી લઈને UI ઘટકો સુધી, તે વર્ટિકલ સ્લાઇસ એન્ડ-ટુ-એન્ડની માલિકી ધરાવે છે.
આ "ઊભી સંસ્થા" સ્તરો દ્વારા આડી વિભાજન સાથે વિરોધાભાસી છે. (UI માટે એક ટીમ, API માટે બીજી ટીમ, ડેટાબેઝ માટે બીજી ટીમ). વર્ટિકલ ટીમો ઝડપથી શિપિંગ કરે છે કારણ કે તેમને અડધા કંપનીમાં દરેક નાના ફેરફારનું સંકલન કરવાની જરૂર નથી.
એપ્લિકેશનના દૃષ્ટિકોણથી, માઇક્રોફ્રન્ટેન્ડ એક સ્વાયત્ત વેબ એપ્લિકેશન છે જે એક મોટા અનુભવમાં સમાવિષ્ટ થઈ શકે છે: જ્યાં સુધી તે બાકીની સિસ્ટમ (URL, ઇવેન્ટ્સ, API, શેર્ડ લાઇબ્રેરીઓ, વગેરે) સાથે કરારોના સમૂહનું પાલન કરે ત્યાં સુધી તેની પોતાની રૂટીંગ, સ્ટેટ મેનેજમેન્ટ, ડિઝાઇન સિસ્ટમ અને ડિપ્લોયમેન્ટ પાઇપલાઇન હોઈ શકે છે.
માઇક્રોફ્રન્ટેન્ડ્સ પાછળના મુખ્ય વિચારો અને સિદ્ધાંતો
સફળ માઇક્રોફ્રન્ટેન્ડ આર્કિટેક્ચરમાં ઘણા પુનરાવર્તિત સિદ્ધાંતો દેખાય છે.; તે કડક નિયમો નથી પણ જો તમે તેનો ઉપયોગ રેલિંગ તરીકે કરશો તો તે તમને ઘણી પીડાથી બચાવશે.
ટેકનોલોજી અજ્ઞેયવાદ સૌથી પ્રખ્યાત સિદ્ધાંતોમાંનો એક છે: દરેક ટીમ બીજા બધા સાથે સિંક્રનાઇઝ કર્યા વિના તેના ટેક સ્ટેકને પસંદ કરવા અને અપગ્રેડ કરવા સક્ષમ હોવી જોઈએ. કદાચ એક માઇક્રોફ્રન્ટેન્ડ React પર હોય, બીજો Angular માં હોય અને લેગસી Vue માં હોય. કસ્ટમ એલિમેન્ટ્સ (વેબ કમ્પોનન્ટ્સ) જેવા બ્રાઉઝર-નેટિવ એબ્સ્ટ્રેક્શન્સ પ્રમાણભૂત DOM API પાછળ તે તફાવતોને છુપાવવામાં મદદ કરે છે.
ટીમ કોડબેઝ વચ્ચે મજબૂત અલગતા એ બીજો મુખ્ય ધ્યેય છે. આદર્શરીતે, માઇક્રોફ્રન્ટેન્ડ્સ જાવાસ્ક્રિપ્ટ રનટાઇમ અથવા ગ્લોબલ ચલોને શેર કરતા નથી. દરેક બંડલ સ્વયં-સમાયેલ છે, તેની પોતાની નિર્ભરતા લોડ કરે છે અને અન્ય લોકોથી છુપાયેલી સ્થિતિ પર આધાર રાખતો નથી. તે આકસ્મિક જોડાણ ઘટાડે છે અને સ્વતંત્ર જમાવટને વધુ વાસ્તવિક બનાવે છે.
નામકરણના વિરોધાભાસ ટાળવા માટે, ટીમો ઘણીવાર સ્પષ્ટ નામસ્થળો પર સંમત થાય છે CSS વર્ગો, DOM ઇવેન્ટ્સ, લોકલ સ્ટોરેજ કી, કૂકીઝ અથવા કસ્ટમ એલિમેન્ટ ટેગ નામો માટે. ઉદાહરણ તરીકે, ચેકઆઉટ ટીમ વસ્તુઓને chk- અથવા જેવા ટેગનો ઉપયોગ કરો <blue-buy>, જ્યારે ભલામણ ટીમ ઉપયોગ કરે છે rec- or <green-recos>. એક નજરમાં, DOM તમને જણાવે છે કે કયો ભાગ કોની માલિકીનો છે.
બીજો સિદ્ધાંત એ છે કે કસ્ટમ ગ્લોબલ API કરતાં મૂળ બ્રાઉઝર ક્ષમતાઓને પ્રાધાન્ય આપવું.. સર્વ-હેતુક પબસબ સિસ્ટમ શોધવાને બદલે, તમે માનક DOM ઇવેન્ટ્સ પર આધાર રાખી શકો છો, CustomEvent, રૂટીંગ માટે ઇતિહાસ API અથવા ઇન્ટિગ્રેશન લેયર તરીકે DOM પોતે. જ્યારે પણ તમને ખરેખર શેર કરેલ API ની જરૂર હોય, ત્યારે તેને શક્ય તેટલું નાનું અને સ્થિર રાખો.
છેલ્લે, સ્થિતિસ્થાપકતા પહેલા દિવસથી જ ડિઝાઇનનો ભાગ હોવી જોઈએ. જ્યારે જાવાસ્ક્રિપ્ટ ધીમી હોય, નિષ્ફળ જાય અથવા અવરોધિત હોય ત્યારે પણ દરેક માઇક્રોફ્રન્ટેન્ડ થોડું મૂલ્ય પૂરું પાડશે. સર્વર-સાઇડ રેન્ડરિંગ, પ્રગતિશીલ ઉન્નતીકરણ અને સ્કેલેટન સ્ક્રીન જેવી તકનીકો નબળી નેટવર્ક પરિસ્થિતિઓમાં પણ ઉચ્ચ પ્રદર્શન જાળવવામાં મદદ કરે છે.
આ સંદર્ભમાં "આધુનિક વેબ એપ્લિકેશન" શું છે?
દરેક વેબસાઇટને માઇક્રોફ્રન્ટેન્ડ્સ અથવા જટિલ બ્રાઉઝર ઇન્ટિગ્રેશન વ્યૂહરચનાની જરૂર હોતી નથી.. એક સારું માનસિક મોડેલ "દસ્તાવેજો-થી-એપ્લિકેશન્સ સાતત્ય" માંથી આવે છે: ડાબી બાજુ તમારી પાસે મોટાભાગે સ્થિર દસ્તાવેજો એકબીજા સાથે જોડાયેલા છે; જમણી બાજુ તમારી પાસે ઑનલાઇન ફોટો એડિટર જેવી સંપૂર્ણપણે ઇન્ટરેક્ટિવ એપ્લિકેશનો છે.
જો તમારો પ્રોજેક્ટ સ્ટેટિક દસ્તાવેજોની નજીક હોય, તો એક સરળ સર્વર-રેન્ડર કરેલી રચના ઘણીવાર પૂરતી હોય છે.. સર્વર વિવિધ સ્ત્રોતોમાંથી HTML ટુકડાઓ એકત્રિત કરે છે, તેમને એકસાથે જોડે છે અને બ્રાઉઝર પર મોકલે છે. અપડેટ્સ સંપૂર્ણ પૃષ્ઠ લોડ અથવા નાના Ajax ઇન્જેક્શન દ્વારા થાય છે, અને તે સંપૂર્ણપણે ઠીક છે.
જ્યારે તમે વધુ ગતિશીલ, એપ્લિકેશન જેવા અનુભવો તરફ આગળ વધો છો—ત્વરિત પ્રતિસાદ, ઑફલાઇન કાર્ય, આશાવાદી UI અપડેટ્સ — શુદ્ધ સર્વર-સાઇડ એકીકરણ પૂરતું નથી. તમારે ક્લાયંટ-સાઇડ કમ્પોઝિશન, સ્ટેટ મેનેજમેન્ટ અને રૂટીંગની જરૂર છે. આ તે જગ્યા છે જ્યાં માઇક્રોફ્રન્ટેન્ડ્સ રસપ્રદ બને છે: તેઓ તમને ઘણી ટીમોમાં તે જટિલતાને સ્કેલ કરવાનો માર્ગ આપે છે.
ઊભી સંસ્થા અને ડોમેન-આધારિત સ્લાઇસેસ
એક સામાન્ય ભલામણ એ છે કે ટેકનિકલ સ્તરોને બદલે માઇક્રોફ્રન્ટેન્ડ્સને બિઝનેસ ડોમેન્સ સાથે ગોઠવો.. વપરાશકર્તા મુસાફરીના સંદર્ભમાં વિચારો: “કાર્ટ”, “ઉત્પાદન વિગતો”, “એડમિન વપરાશકર્તાઓ”, “કોર્સ શેડ્યૂલ”, “વિદ્યાર્થી રેકોર્ડ”, “ઇન્વોઇસ”, વગેરે.
આ દરેક ડોમેન સારી રીતે વ્યાખ્યાયિત જવાબદારી સાથે પોતાનું માઇક્રોફ્રન્ટએન્ડ બની શકે છે.. યુનિવર્સિટી સિસ્ટમમાં, એક એપ્લિકેશન વિદ્યાર્થી પ્રોફાઇલ્સ, બીજી સ્ટાફ પ્રોફાઇલ્સ, ત્રીજી એપ્લિકેશન કોર્સ સમયપત્રક અને બીજી પરીક્ષાના પરિણામો UI મેનેજ કરી શકે છે. તેઓ એક શેલ અને કદાચ કેટલીક સ્ટાઇલિંગ શેર કરે છે, પરંતુ દરેક ડિપ્લોયમેન્ટ દ્રષ્ટિકોણથી એક સ્વતંત્ર એપ્લિકેશન છે.
સારી સ્લાઇસિંગ તમારી બેકએન્ડ માઇક્રોસર્વિસિસના બાઉન્ડેડ સંદર્ભોને પણ ધ્યાનમાં લે છે.. આદર્શરીતે, "બિલિંગ" માટેનો માઇક્રોફ્રન્ટએન્ડ મુખ્યત્વે બિલિંગ માઇક્રોસર્વિસિસ સાથે વાત કરે છે, "કેટલોગ" ફ્રન્ટએન્ડ કેટલોગ સેવાઓ સાથે વાત કરે છે, વગેરે. તે દરેક વર્ટિકલ સ્લાઇસને સુસંગત રાખે છે અને ક્રોસ-ટીમ ડિપેન્ડન્સી ઘટાડે છે.
ટેકનિકલ એકીકરણ: API અને વેબ ઘટકો તરીકે DOM
બ્રાઉઝર-સાઇડ માઇક્રોફ્રન્ટેન્ડ આર્કિટેક્ચરમાં, DOM પોતે ઘણીવાર પ્રાથમિક એકીકરણ API તરીકે કાર્ય કરે છે.. એકબીજાના જાવાસ્ક્રિપ્ટને સીધા બોલાવવાને બદલે, ટીમો HTML તત્વો, વિશેષતાઓ અને ઇવેન્ટ્સ દ્વારા કાર્યક્ષમતાનો ખુલાસો કરે છે.
કસ્ટમ એલિમેન્ટ્સ (વેબ ઘટકોનો ભાગ) આ માટે એક શક્તિશાળી પ્રિમિટિવ છે. એક ટીમ ઇચ્છે તે ફ્રેમવર્કનો ઉપયોગ કરીને સુવિધા બનાવી શકે છે અને પછી તેને કસ્ટમ ટેગ તરીકે લપેટી શકે છે, ઉદાહરણ તરીકે <order-minicart></order-minicart>. તે ઘટકનો જાહેર કરાર તેના ટેગ નામ, વિશેષતાઓ અને ઉત્સર્જિત ઘટનાઓ દ્વારા વ્યાખ્યાયિત થાય છે, તેના આંતરિક અમલીકરણ દ્વારા નહીં.
કસ્ટમ એલિમેન્ટ્સ v1 માટે બ્રાઉઝર સપોર્ટ હવે બધા મુખ્ય બ્રાઉઝર્સમાં મજબૂત છે., જેનો અર્થ એ છે કે તમને ભાગ્યે જ પોલીફિલ્સની જરૂર પડે છે. મોટાભાગના મુખ્ય પ્રવાહના ફ્રેમવર્ક - React, Vue, Angular, Svelte, Preact - કસ્ટમ તત્વોને નિયમિત HTML ટૅગ્સની જેમ રેન્ડર અથવા એમ્બેડ કરી શકે છે, અને તેમાંના ઘણાને કસ્ટમ ઘટકમાં પણ કમ્પાઇલ કરી શકાય છે.
એકીકરણ પેટર્ન કંઈક આના જેવું દેખાય છે: "પ્રોડક્ટ પેજ" માઇક્રોફ્રન્ટેન્ડ નક્કી કરે છે કે પેજ પર કઈ સુવિધાઓ દેખાય છે (પસંદગીકારો, ખરીદી બટનો, મીની-કાર્ટ, ભલામણો). તે કસ્ટમ તત્વોને ઇન્જેક્ટ કરે છે જેમ કે <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>. તે સુવિધાઓ ધરાવતી ટીમો તેમના તત્વોની નોંધણી કરે છે customElements.define અને જીવનચક્ર કોલબેકનો અમલ કરો જેમ કે connectedCallback or attributeChangedCallback.
જ્યારે કોઈ પ્રોડક્ટ વેરિઅન્ટ બદલાય છે, ત્યારે પેજ કાં તો એલિમેન્ટ ફરીથી બનાવી શકે છે અથવા ફક્ત તેના લક્ષણો અપડેટ કરી શકે છે.. જો ઘટક સંબંધિત વિશેષતાઓનું અવલોકન કરે છે, તો તે પોતાને ફરીથી રેન્ડર કરી શકે છે. આંતરિક રીતે, ઘટક ટેમ્પલેટ સ્ટ્રિંગ્સ, React, Vue, અથવા કોઈપણ રેન્ડરિંગ એન્જિનનો ઉપયોગ કરી શકે છે; ઇન્ટિગ્રેટરને કાળજી લેવાની જરૂર નથી.
ક્લાયન્ટ-સાઇડ કમ્યુનિકેશન: ઇવેન્ટ્સ અને DOM સંબંધો
પાસિંગ એટ્રીબ્યુટ્સ એક-માર્ગી "ડેટા ઇન" દૃશ્યો માટે સારી રીતે કાર્ય કરે છે., પરંતુ ઘણી વાસ્તવિક ક્રિયાપ્રતિક્રિયાઓ માટે ઘટકોને તેમના પર્યાવરણ અથવા ભાઈ-બહેનો સાથે વાત કરવાની જરૂર પડે છે. એક લાક્ષણિક ઉદાહરણ "ખરીદો" બટન છે જે કોઈ વસ્તુ ઉમેરવામાં આવે ત્યારે મીની-કાર્ટને સૂચિત કરવું જોઈએ.
કસ્ટમ ગ્લોબલ ઇવેન્ટ બસ બનાવવાને બદલે, તમે બ્રાઉઝર ઇવેન્ટ્સ પર આધાર રાખી શકો છો. ઘટકોનું વિતરણ CustomEvent DOM ટ્રી દ્વારા બબલ થતા ઉદાહરણો. એક પેરેન્ટ એલિમેન્ટ અથવા તો window તે ઘટનાઓ સાંભળી શકે છે અને પ્રતિભાવો ગોઠવી શકે છે.
ઉદાહરણ તરીકે, બાય બટન આવી ઘટના ઉત્સર્જિત કરી શકે છે blue:basket:changed વર્તમાન કાર્ટ પેલોડ સાથે. મીની-કાર્ટ તે ઇવેન્ટમાં સબ્સ્ક્રાઇબ કરે છે window અથવા શેર કરેલા કન્ટેનર એલિમેન્ટ પર અને જ્યારે પણ તે ફાયર થાય છે ત્યારે તેની આંતરિક સ્થિતિને તાજું કરે છે.
આ અભિગમ ઘટકોને સ્વતંત્ર રાખે છે: બાય બટનને ખબર નથી હોતી કે તેની ઘટનાઓ કોણ સાંભળે છે, જો કોઈ હોય તો. તે ફક્ત તેના કરારને પૂર્ણ કરે છે. અને મીની-કાર્ટ ફક્ત ઘટનાના અર્થશાસ્ત્ર પર આધાર રાખે છે, અન્ય ટુકડાઓના અમલીકરણ વિગતો પર નહીં.
સર્વર-સાઇડ રેન્ડરિંગ અને યુનિવર્સલ ઘટકો
જો તમને ફર્સ્ટ-પેઇન્ટ પર્ફોર્મન્સ, SEO અથવા જાવાસ્ક્રિપ્ટ નિષ્ફળ જાય ત્યારે સ્થિતિસ્થાપકતાની ચિંતા હોય, તો સર્વર-સાઇડ રેન્ડરિંગ (SSR) આવશ્યક છે.. શુદ્ધ ક્લાયંટ-સાઇડ વેબ ઘટકો ફક્ત JS બંડલ ડાઉનલોડ અને રન થયા પછી જ દેખાય છે, જેનો અર્થ ધીમા નેટવર્ક્સ પર સફેદ સ્ક્રીન હોઈ શકે છે.
એક વ્યવહારિક ઉકેલ એ છે કે કસ્ટમ એલિમેન્ટ્સને સર્વર-સાઇડ ઇન્ક્લુઝ (SSI/ESI) સાથે જોડવામાં આવે.. દરેક માઇક્રોફ્રન્ટેન્ડ એક HTTP એન્ડપોઇન્ટ દર્શાવે છે જે તેના ફ્રેગમેન્ટ માટે HTML પરત કરે છે, ઉદાહરણ તરીકે /blue-buy?sku=t_porsche. શેલ અથવા હોસ્ટ એપ્લિકેશન દ્વારા રેન્ડર કરાયેલ મુખ્ય પૃષ્ઠમાં પ્લેસહોલ્ડર્સનો સમાવેશ થાય છે જેમ કે <!--#include virtual="/blue-buy?sku=t_porsche" --> જે વેબ સર્વર (ઘણીવાર nginx) બ્રાઉઝરને પ્રતિભાવ મોકલતા પહેલા વિસ્તૃત થાય છે.
બ્રાઉઝરમાં રનટાઇમ વખતે, તે જ કસ્ટમ ઘટક હાઇડ્રેટેડ અથવા ફરીથી શરૂ થાય છે. એકવાર તેનું JS બંડલ લોડ થઈ જાય. તે તમને "યુનિવર્સલ" ઘટક આપે છે: તે ગતિ અને SEO માટે સર્વર પર રેન્ડર કરી શકે છે, પછી ક્લાયંટ પર સંપૂર્ણપણે ઇન્ટરેક્ટિવ કસ્ટમ ઘટક તરીકે વર્તે છે.
સમાવેશ સાથે SSR નો એક ગેરલાભ એ છે કે સૌથી ધીમો ટુકડો કુલ પ્રતિભાવ સમય નક્કી કરે છે. ફ્રેગમેન્ટ લેવલ પર કેશીંગ લગભગ ફરજિયાત છે. ખર્ચાળ, ખૂબ જ વ્યક્તિગત ટુકડાઓ (જેમ કે ભલામણો) માટે તમે સર્વર-સાઇડ રેન્ડરિંગ છોડી શકો છો અને તેમને ક્લાયંટ પર અસુમેળ રીતે લોડ કરી શકો છો.
લેઆઉટમાં થતા ફેરફારોને ટાળવા માટે સ્કેલેટન સ્ક્રીન એક સારું સમાધાન છે.. એક ટુકડો સર્વર-રેન્ડર કરી શકે છે જેમાં ગ્રે-આઉટ પ્લેસહોલ્ડર લગભગ અંતિમ સામગ્રી જેટલું જ કદ ધરાવે છે. જ્યારે વાસ્તવિક ડેટા ક્લાયંટ-સાઇડ પર આવે છે, ત્યારે મોટા રિફ્લો વિના હાડપિંજર સ્વેપ આઉટ થઈ જાય છે.
ડેટા લોડિંગ અને માનવામાં આવેલ કામગીરી
માઇક્રોફ્રન્ટએન્ડ વિશ્વમાં તમારે ડેટા ક્યાં અને ક્યારે મેળવવામાં આવે છે તે વિશે કાળજીપૂર્વક વિચારવું પડશે.. તમે સર્વર-સાઇડ, ક્લાયંટ-સાઇડ બધું મેળવી શકો છો, અથવા હાઇબ્રિડનો ઉપયોગ કરી શકો છો. દરેક પસંદગી કેશીંગ વ્યૂહરચનાઓ, સમય-થી-ઇન્ટરેક્ટિવ અને કથિત ગતિને અસર કરે છે.
સર્વર-સાઇડમાં કુદરતી રીતે દરેક ટુકડા માટે સર્વર-સાઇડ ફેચને પ્રોત્સાહન આપવાનો સમાવેશ થાય છે. દરેક માઇક્રોફ્રન્ટેન્ડ "તેની" બેકએન્ડ સેવાઓ સાથે વાત કરે છે, HTML રેન્ડર કરે છે અને તેને શેલમાં પરત કરે છે. તે HTML ને અન્ય ટુકડાઓથી સ્વતંત્ર રીતે કેશ કરી શકાય છે, જે લોગિન અથવા પ્રોડક્ટ લિસ્ટિંગ જેવા ઉચ્ચ ટ્રાફિક ભાગોને સ્કેલ કરવામાં મદદ કરે છે.
ક્લાયન્ટ પર ડેટા લોડ કરતી વખતે તમારે પ્રગતિશીલ રાજ્યો માટે બજેટ બનાવવું જોઈએ: પ્રારંભિક સ્કેલેટન, જ્યારે વિશેષતાઓ બદલાય છે ત્યારે ઝડપી અપડેટ્સ, અને API ધીમા હોય ત્યારે ફોલબેક વર્તણૂક. કેટલીકવાર નવો ડેટા આવે ત્યાં સુધી જૂના ડેટાને સ્થાને રાખવો એ દરેક નાના ફેરફાર માટે સ્કેલેટનને ફ્લેશ કરવા કરતાં દૃષ્ટિની રીતે ઓછું અસ્પષ્ટ હોય છે.
React સાથે માઇક્રોફ્રન્ટેન્ડ્સ
રિએક્ટ તેના ઇકોસિસ્ટમ અને રેન્ડરિંગ ઑપ્ટિમાઇઝેશનને કારણે માઇક્રોફ્રન્ટેન્ડ્સને અમલમાં મૂકવા માટે ખૂબ જ લોકપ્રિય પસંદગી છે.. વર્ચ્યુઅલ DOM અને ડિફિંગ પ્રોપ ફેરફારો અથવા વૈશ્વિક સ્થિતિના આધારે UI ના નાના ભાગોને અપડેટ કરવાનું સરળ બનાવે છે, અને તમે React એપ્સને સ્ટેન્ડઅલોન SPA અથવા કસ્ટમ એલિમેન્ટ્સ તરીકે બંડલ કરી શકો છો.
રિએક્ટ વર્ઝન વચ્ચે સ્થળાંતર વધવાનું અને પ્રમાણમાં પીડારહિત હોય છે. કેટલાક અન્ય ફ્રેમવર્કની તુલનામાં, જે ઘણી સ્વતંત્ર ટીમો અલગ માઇક્રોફ્રન્ટેન્ડ જાળવી રાખે છે ત્યારે મદદરૂપ થાય છે. તમારે એક જ સમયે એક મુખ્ય સંસ્કરણથી બીજા સંસ્કરણ પર જવા માટે બધા ટુકડાઓની જરૂર નથી.
બીજી બાજુ એ છે કે વિકેન્દ્રિત React માઇક્રોફ્રન્ટેન્ડ્સ સંસાધન ફેલાવો બનાવી શકે છે.: બહુવિધ ટીમો, બહુવિધ CI/CD પાઇપલાઇન્સ, ઘણા બંડલ્સ, ઘણા નાના રિપોઝ. બિલ્ડ, પ્રોવિઝનિંગ અને અવલોકનક્ષમતા માટે પૂરતા ઓટોમેશન વિના, તે ઓવરહેડનું સંચાલન કરવું મુશ્કેલ બની જાય છે.
બીજો વ્યવહારુ મુદ્દો બંડલનું કદ છે. જો દરેક માઇક્રોફ્રન્ટેન્ડ પોતાની React અને શેર્ડ લાઇબ્રેરીઓની નકલ મોકલે છે, તો કુલ ડાઉનલોડ કદ વિસ્ફોટ થઈ શકે છે, ખાસ કરીને જ્યારે પૃષ્ઠને રેન્ડર કરવા માટે ઘણા ટુકડાઓની જરૂર હોય. મોડ્યુલ ફેડરેશન (રનટાઇમ પર ડિપેન્ડન્સી શેર કરવા માટે) અથવા ટીમોમાં મજબૂત રીતે ગોઠવાયેલ સ્ટેક જેવા ઉકેલો આને ઘટાડી શકે છે.
કોણીય સાથે માઇક્રોફ્રન્ટેન્ડ્સ
કોણીય વધુ અભિપ્રાય ધરાવતા માઇક્રોફ્રન્ટેન્ડ સેટઅપ્સ માટે સરસ રીતે કામ કરે છે., ખાસ કરીને જ્યારે તમે મોનોરેપો અને તેમની આસપાસના ટૂલિંગ (જેમ કે Nx) નો ઉપયોગ કરો છો. કોણીય વર્કસ્પેસ પ્રોજેક્ટ્સ અને લાઇબ્રેરીઓમાં ગોઠવાયેલા હોય છે, જે મોટા સોલ્યુશનને બહુવિધ એપ્લિકેશનો અને શેર કરેલી લાઇબ્રેરીઓમાં વિભાજીત કરવાનું સ્વાભાવિક બનાવે છે.
એંગ્યુલર 12 અને વેબપેક 5 થી, મોડ્યુલ ફેડરેશન પ્રથમ-વર્ગનું નાગરિક બન્યું છે.. એક કોણીય પ્રોજેક્ટને સ્કીમેટિક આદેશોનો ઉપયોગ કરીને હોસ્ટ અથવા રિમોટ તરીકે ગોઠવી શકાય છે, જરૂરી વાયરિંગ અપ કરી શકાય છે webpack.config.js અને તમારા માટે બુટસ્ટ્રેપ લોજિક.
આ મોડેલમાં, "હોસ્ટ" એંગ્યુલર એપ્લિકેશન શેલ તરીકે કાર્ય કરે છે જે નેવિગેશન, શેર્ડ સ્ટેટ અને ડિપેન્ડન્સી શેરિંગનું આયોજન કરે છે. વ્યક્તિગત કોણીય માઇક્રોફ્રન્ટેન્ડ્સ (રિમોટ્સ) કોણીય મોડ્યુલ્સને ખુલ્લા પાડે છે જેને હોસ્ટ મોડ્યુલ ફેડરેશન દ્વારા ગતિશીલ રીતે લેઝી-લોડ કરી શકે છે.
સામાન્ય કોણીય રૂટીંગ પ્રિમિટિવ્સ હજુ પણ લાગુ પડે છે. માઇક્રોફ્રન્ટેન્ડની અંદર, તમે ઉપયોગ કરો છો RouterModule.forChild ચાઇલ્ડ રૂટ વ્યાખ્યાઓ માટે જેથી હોસ્ટ એકમાત્ર ઉપયોગ કરનાર હોય forRootઆ રીતે, બહુવિધ કોણીય એપ્લિકેશનો રાઉટર વિરોધાભાસ વિના એકીકૃત URL જગ્યા હેઠળ સહઅસ્તિત્વ કરી શકે છે.
વ્યવહારમાં મોડ્યુલ ફેડરેશન (કોણીય ઉદાહરણ)
વેબપેક મોડ્યુલ ફેડરેશન એ વેબપેક 5 સુવિધા છે જે રનટાઇમ પર બહુવિધ બિલ્ડ્સને કોડ શેર કરવાની મંજૂરી આપે છે.. એક બિલ્ડ (હોસ્ટ) ગતિશીલ રીતે અન્ય બિલ્ડ્સ (રિમોટ્સ) દ્વારા ખુલ્લા મોડ્યુલોને એક નાની મેનિફેસ્ટ ફાઇલ દ્વારા લોડ કરે છે, જેને સામાન્ય રીતે નામ આપવામાં આવે છે remoteEntry.js.
એંગ્યુલરમાં તમે આને ખૂબ જ ઝડપથી સ્કેફોલ્ડ કરી શકો છો. ઉદાહરણ તરીકે, તમે હોસ્ટ એપ્લિકેશન બનાવી શકો છો (host-app) અને પછી એક યોજનાકીય ચલાવો જેમ કે ng add @angular-architects/module-federation --project host-app --port 4200. આ ModuleFederationPlugin રૂપરેખાંકન, બુટસ્ટ્રેપિંગ ફાઇલો અને રનટાઇમ લોજિક સેટ કરે છે.
પછી તમે બે રિમોટ એંગ્યુલર એપ્સ બનાવો: એક પ્રોડક્ટ કેટેલોગ માટે અને એક શોપિંગ કાર્ટ માટે. દરેક એપને પોતાનો પોર્ટ મળે છે (દા.ત. 4201 માટે products-app, 4202 માટે cart-app) અને તેનું પોતાનું મોડ્યુલ ફેડરેશન રૂપરેખા. માં webpack.config.js તમે ઉપયોગ કરો છો તે દરેક રિમોટનો exposes કી હેઠળ મોડ્યુલ (સામાન્ય રીતે મુખ્ય એપ્લિકેશન મોડ્યુલ) પ્રકાશિત કરવા માટે ./ProductsModule or ./CartModule.
હોસ્ટ શેલ પછી એવા રૂટ વ્યાખ્યાયિત કરે છે જે આળસથી તે રિમોટ મોડ્યુલો લોડ કરે છે. દ્વારા loadRemoteModule થી @angular-architects/module-federation. ઉદાહરણ તરીકે, નેવિગેટ કરીને /products થી ગતિશીલ આયાત શરૂ કરે છે http://localhost:4201/remoteEntry.js અને લોડ થાય છે ProductsModule; /cart કાર્ટ રિમોટ સાથે પણ આવું જ કરે છે.
કેટલોગ માઇક્રોફ્રન્ટેન્ડની અંદર તમારી પાસે એક હોઈ શકે છે ProductsComponent જે વસ્તુઓનું કોષ્ટક રજૂ કરે છે, a માંથી ડેટા વાંચન PRODUCTS_CATALOG સતત અને "કાર્ટમાં ઉમેરો" બટન ઓફર કરે છે. ક્લિક કરવા પર, તે વસ્તુને અંદર રાખે છે localStorage "કાર્ટ" કી હેઠળ, જ્યારે ઉત્પાદન પહેલાથી જ અસ્તિત્વમાં હોય ત્યારે જથ્થામાં વધારો.
પછી કાર્ટ માઇક્રોફ્રન્ટેન્ડ એ જમાંથી વાંચે છે localStorage કી, ઉત્પાદનનું નામ, કિંમત, જથ્થો અને કુલ સાથે એક કોષ્ટક દર્શાવે છે, અને "ક્લિયર કાર્ટ" બટન આપે છે જે સ્ટોરેજ સાફ કરે છે અને તેની આંતરિક સ્થિતિ ફરીથી સેટ કરે છે. ચુસ્ત જોડાણ વિના બે સ્વતંત્ર એપ્લિકેશનો પર સ્થિતિ શેર કરવાની આ એક સરળ પણ દૃષ્ટાંતરૂપ રીત છે.
હોસ્ટ શેલ બનાવવું: લેઆઉટ, હોમ અને નેવિગેશન
માઇક્રોફ્રન્ટેન્ડ્સમાં સારા વપરાશકર્તા અનુભવ માટે એક મજબૂત હોસ્ટ શેલ મહત્વપૂર્ણ છે.. તે સામાન્ય રીતે ગ્લોબલ લેઆઉટ (હેડર, ફૂટર, સાઇડબાર), ટોપ-લેવલ રૂટીંગ અને ક્યારેક ગ્લોબલ સ્ટેટ જેમ કે ઓથેન્ટિકેશન અથવા ફીચર ફ્લેગ્સ ધરાવે છે.
કોણીય ઉદાહરણમાં, હોસ્ટ a ને વ્યાખ્યાયિત કરે છે LayoutComponent જે હેડર અને નેસ્ટેડ રેન્ડર કરે છે router-outlet. હેડર પોતાનામાં રહે છે HeaderModule અને એન્ગ્યુલર દ્વારા હોમ પેજ, પ્રોડક્ટ લિસ્ટિંગ અને કાર્ટ પર નેવિગેશન લિંક્સ પ્રદર્શિત કરે છે routerLink. રૂટ પાથને enum જેવા કેન્દ્રિયકૃત કરી શકાય છે RoutesPath જાદુઈ તાંતણાઓથી બચવા માટે.
લેઆઉટ રૂટીંગ મોડ્યુલ એક પેરેન્ટ રૂટ સેટ કરે છે જેની સાથે LayoutComponent તેના ઘટક તરીકે અને બાળ માર્ગો વ્યાખ્યાયિત કરે છે /home, /products અને /cart. આ /home પાથ લોકલ લોડ કરે છે HomeModule; બીજા ઉપયોગ કરે છે loadRemoteModule રન ટાઈમ પર એન્ગ્યુલર માઇક્રોફ્રન્ટેન્ડ્સ ખેંચવા માટે.
યજમાનની અંદર, એક SharedModule ફરીથી વાપરી શકાય તેવા બિલ્ડિંગ બ્લોક્સ ભેગા કરી શકે છે જેમ કે હેડર, લેઆઉટ, સામાન્ય નિર્દેશો અને સ્થિરાંકો. આ મોડ્યુલ રૂટમાં આયાત કરી શકાય છે AppModule ની સાથે AppRoutingModule, જે લેઆઉટ રૂટીંગ રૂપરેખાંકન માટે ખાલી પાથ નિર્દેશ કરે છે.
Next.js અને માઇક્રોફ્રન્ટેન્ડ્સ
Next.js, પ્રોડક્શન-ગ્રેડ રિએક્ટ ફ્રેમવર્ક તરીકે, માઇક્રોફ્રન્ટેન્ડ અભિગમ સાથે પણ સારી રીતે કાર્ય કરે છે., ખાસ કરીને કારણ કે તેણે વેબપેક 5 અપનાવ્યું હતું અને તેથી મોડ્યુલ ફેડરેશન સપોર્ટ. SSR, ઇન્ક્રીમેન્ટલ સ્ટેટિક રિજનરેશન અને રૂટીંગ પર તેનું ધ્યાન તેને શેલ, વ્યક્તિગત માઇક્રોફ્રન્ટેન્ડ્સ અથવા બંને માટે સારો ઉમેદવાર બનાવે છે.
Next.js માં માઇક્રોફ્રન્ટેન્ડ્સ લાગુ કરવા માટે તમે સામાન્ય રીતે વેબપેક સ્તરે મોડ્યુલ ફેડરેશનને ગોઠવો છો., ચોક્કસ પૃષ્ઠો અથવા ઘટકોને રિમોટ તરીકે ખુલ્લા પાડવું અને હોસ્ટમાંથી તેનો ઉપયોગ કરવો. ભલે મોડ્યુલ ફેડરેશન "માત્ર" એક જાવાસ્ક્રિપ્ટ બંડલર સુવિધા છે, તમે તેને એક આર્કિટેક્ચરલ પેટર્ન તરીકે વિચારી શકો છો: તે તમને સમય પહેલાં બધું એકસાથે બંડલ કર્યા વિના વિવિધ ટીમોની માલિકીના કોડને ગતિશીલ રીતે લોડ કરવા દે છે.
વેબપેક 5 વગરના લેગસી Next.js વર્ઝન માટે તમારે બાહ્ય એડેપ્ટરની જરૂર પડશે. ફેડરેશન સપોર્ટને સક્ષમ કરવા માટે. આગામી 10.2 થી, વેબપેક 5 સપોર્ટ બિલ્ટ-ઇન છે, જે સેટઅપને નાટકીય રીતે સરળ બનાવે છે.
સિંગલ-એસપીએ અને અન્ય માઇક્રોફ્રન્ટેન્ડ ફ્રેમવર્ક
સિંગલ-એસપીએ એ માઇક્રોફ્રન્ટેન્ડ્સ માટેનો બીજો જાણીતો ઉકેલ છે, ખાસ કરીને રિએક્ટ ઇકોસિસ્ટમ્સમાં.. તે એક જ પેજ પર બહુવિધ સ્વતંત્ર એપ્લિકેશનોને ગોઠવવા પર ધ્યાન કેન્દ્રિત કરે છે, દરેક વર્તમાન રૂટના આધારે તેના પોતાના DOM નોડમાં માઉન્ટ થયેલ છે.
સિંગલ-એસપીએ સાથે તમારી પાસે અનેક રિએક્ટ એપ્લિકેશનો (અથવા રિએક્ટ, વ્યુ, એંગ્યુલરનું મિશ્રણ) સહઅસ્તિત્વમાં હોઈ શકે છે.. ફ્રેમવર્ક વપરાશકર્તા નેવિગેટ કરે ત્યારે દરેક માઇક્રોફ્રન્ટેન્ડને ક્યારે બુટસ્ટ્રેપ, માઉન્ટ અથવા અનમાઉન્ટ કરવું તે સંભાળે છે, અને તમે તેને તમારી રૂટીંગ વ્યૂહરચનામાં વાયર કરો છો (ઉદાહરણ તરીકે, દરેક ટુકડામાં રિએક્ટ રાઉટર સાથે).
સિંગલ-એસપીએ અને મોડ્યુલ ફેડરેશન વચ્ચે પસંદગી કરતી વખતે, ટીમો ઘણીવાર તેમની બંડલર/ટૂલિંગ પસંદગીઓને ધ્યાનમાં લે છે. મોડ્યુલ ફેડરેશન વેબપેક સાથે ઊંડાણપૂર્વક સંકલિત થાય છે (અને, વધુને વધુ, Rspack અથવા રોલઅપ જેવા વિકલ્પો સાથે કારણ કે તેઓ સપોર્ટ ઉમેરે છે). બીજી બાજુ, સિંગલ-એસપીએ, બંડલ શેરિંગ કરતાં રનટાઇમ ઓર્કેસ્ટ્રેશન વિશે વધુ છે, તેથી તમે કોડ શેરિંગને અન્ય રીતે હેન્ડલ કરતી વખતે વિવિધ બિલ્ડ ટૂલ્સ સાથે તેનો ઉપયોગ કરી શકો છો.
માઇક્રોફ્રન્ટેન્ડ્સના ઉદ્દેશ્યો, સુવિધાઓ અને ફાયદા
માઇક્રોફ્રન્ટેન્ડ્સનો મુખ્ય ઉદ્દેશ્ય ઘણી ટીમોમાં કોઓર્ડિનેશન ઓવરહેડ હેઠળ તૂટી પડ્યા વિના ફ્રન્ટએન્ડ ડેવલપમેન્ટને સ્કેલ કરવાનો છે.. સિંક્રનાઇઝ્ડ રીલીઝ સાથે એક વિશાળ કોડબેઝને બદલે, તમને નાના સ્વતંત્ર રીતે ડિપ્લોયેબલ યુનિટ્સ મળે છે.
મુખ્ય ઉદ્દેશ્યોમાં સામાન્ય રીતે સમાવેશ થાય છે બહુવિધ ટીમોને સમાંતર રીતે કામ કરવા સક્ષમ બનાવવું, UI ના વિવિધ ભાગો માટે સ્વતંત્ર જમાવટને ટેકો આપવો, વિવિધ તકનીકોનો ઉપયોગ કરવા માટે સુગમતા જાળવી રાખવી જ્યાં તે અર્થપૂર્ણ બને અને દરેક કોડબેઝનું કદ અને જટિલતા ઘટાડીને જાળવણીક્ષમતામાં સુધારો કરવો.
આવા આર્કિટેક્ચરની લાક્ષણિક લાક્ષણિકતાઓ શેર્ડ લાઇબ્રેરીઓ દ્વારા ઘટકોનો પુનઃઉપયોગ છે., એપ્લિકેશન શેલ દ્વારા મોડ્યુલર એકીકરણ, માઇક્રોફ્રન્ટેન્ડ દીઠ સ્વતંત્ર પાઇપલાઇન્સ, CDN અને કેશીંગ દ્વારા પ્રદર્શન ઑપ્ટિમાઇઝેશન, કેન્દ્રિય સુરક્ષા હેન્ડલિંગ અને મજબૂત અવલોકનક્ષમતા.
વ્યવસાયિક દ્રષ્ટિકોણથી, ફાયદા નોંધપાત્ર છે: વધુ ટીમો સાથે વિકાસ વધુ સારી રીતે આગળ વધે છે, નિષ્ફળતાઓને વધુ સારી રીતે અલગ કરી શકાય છે, દરેક ડોમેન દીઠ સુવિધાઓ રોલઆઉટ અથવા રોલબેક કરી શકાય છે, અને લેગસી ફ્રન્ટએન્ડ સ્ટેક્સને સમગ્ર એપ્લિકેશનને ફરીથી લખવાને બદલે એક સમયે એક સ્લાઇસ બદલીને ધીમે ધીમે સ્થાનાંતરિત કરી શકાય છે.
માઇક્રોફ્રન્ટેન્ડ આર્કિટેક્ચરમાં મુખ્ય ઘટકો
જ્યારે અમલીકરણો અલગ અલગ હોય છે, મોટાભાગના માઇક્રોફ્રન્ટેન્ડ આર્કિટેક્ચર્સ થોડા માળખાકીય ઘટકો શેર કરે છે જે બધું સુસંગત રાખે છે.
એપ્લિકેશન શેલ (અથવા કન્ટેનર) એ કરોડરજ્જુ છે. તે બાહ્ય લેઆઉટ, વૈશ્વિક નેવિગેશન, પ્રમાણીકરણ, ક્યારેક વૈશ્વિક સ્થિતિ અને માઇક્રોફ્રન્ટેન્ડ્સ લોડ અથવા અનલોડ કરવા માટેના તર્કનું માલિક છે. બ્રાઉઝર-આધારિત સેટઅપ્સમાં, તે પૃષ્ઠ છે જે અન્ય તમામ બંડલ્સને ખેંચે છે.
દરેક માઇક્રોફ્રન્ટેન્ડ એક સ્વયં-સમાયેલ મોડ્યુલ છે જે ચોક્કસ ક્ષમતાનો અમલ કરે છે, જેમ કે પ્રોડક્ટ કેટલોગ, શોપિંગ કાર્ટ, યુઝર પ્રોફાઇલ અથવા એડમિન પેનલ. તે એકીકરણ સપાટી (રૂટ્સ, કસ્ટમ એલિમેન્ટ્સ, મોડ્યુલ ફેડરેશન રિમોટ્સ) ને ખુલ્લી પાડે છે અને બાકીની સિસ્ટમથી આંતરિક વિગતો છુપાવે છે.
ક્રોસ-માઈક્રોફ્રન્ટેન્ડ કોમ્યુનિકેશન માટે ઘણીવાર ઇવેન્ટ બસ અથવા મેસેજ સિસ્ટમ હાજર હોય છે.. આ DOM ઇવેન્ટ્સ, સેન્ટ્રલાઇઝ્ડ રેડક્સ સ્ટોર અથવા કસ્ટમ મેસેજ બ્રોકર પર એક સરળ એબ્સ્ટ્રેક્શન હોઈ શકે છે. ધ્યેય પ્રકાશિત/સબ્સ્ક્રાઇબ સિમેન્ટિક્સને અલગ કરવાનો છે: માઇક્રોફ્રન્ટેન્ડ ઇવેન્ટ્સને કોણ હેન્ડલ કરે છે તે જાણ્યા વિના બહાર કાઢે છે.
શેર્ડ લાઇબ્રેરીઓ ફરીથી વાપરી શકાય તેવા UI ઘટકો, ઉપયોગિતાઓ, ડિઝાઇન ટોકન્સ અને સામાન્ય ક્લાયન્ટ્સને હોસ્ટ કરે છે.. મોનોરેપો સેટઅપ્સમાં Nx જેવા ટૂલ્સ અહીં ચમકે છે, જે તમને બહુવિધ એપ્લિકેશનો દ્વારા ઉપયોગમાં લેવાતા શેર કરેલા પેકેજોને લાગુ સીમાઓ અને સુસંગત સંસ્કરણો સાથે વ્યાખ્યાયિત કરવાની મંજૂરી આપે છે.
અવલોકનક્ષમતા સંગ્રહકો અને ટૂલિંગ (ઉદાહરણ તરીકે ઓપનટેલિમેટ્રીનો ઉપયોગ કરીને) બધા માઇક્રોફ્રન્ટેન્ડ્સમાંથી લોગ, મેટ્રિક્સ અને ટ્રેસનું એકત્રીકરણ, બહુવિધ ટુકડાઓ અથવા સેવાઓને આવરી લેતી સમસ્યાઓનું નિદાન કરવાનું શક્ય બનાવે છે.
ડિલિવરી બાજુ પર CDN ચિત્ર પૂર્ણ કરે છે., JS બંડલ્સ, CSS અને વપરાશકર્તાઓની નજીકની છબીઓ જેવી સ્થિર સંપત્તિઓને કેશીંગ કરે છે, લેટન્સી ઘટાડે છે અને મૂળ સર્વર્સને ઓફલોડ કરે છે. માઇક્રોફ્રન્ટેન્ડ સેટઅપ્સમાં, તમે ઘણીવાર દરેક ટુકડાની સંપત્તિઓને સ્વતંત્ર કેશીંગ અને રોલઆઉટ માટે તેના પોતાના CDN પાથ પર હોસ્ટ કરો છો.
માઇક્રોફ્રન્ટેન્ડ્સ માટે આર્કિટેક્ચર અને ડિઝાઇન પેટર્ન
માઇક્રોફ્રન્ટેન્ડ્સ પર ખાસ લાગુ પડતા પેટર્નનો એક સમૃદ્ધ કેટલોગ છે., સામાન્ય રીતે તમે તેમને કેવી રીતે કંપોઝ કરો છો, ડિપ્લોય કરો છો અને કનેક્ટ કરો છો તેના દ્વારા વ્યાખ્યાયિત થાય છે.
ઘટક-આધારિત રચનાનો અર્થ છે વેબ ઘટકો અથવા સમાન પ્રિમિટિવ્સમાંથી UI બનાવવું. દરેક ઘટકની એક જ જવાબદારી હોય છે, સ્પષ્ટ ઇનપુટ અને આઉટપુટ, અને તેનું અલગથી પરીક્ષણ કરી શકાય છે. ઉચ્ચ-સ્તરનું કમ્પોઝિશન લેયર (જેમ કે શેલ અથવા ઓર્કેસ્ટ્રેશન ફ્રેમવર્ક) તે ઘટકોને સંપૂર્ણ પૃષ્ઠોમાં ગોઠવે છે.
ફેડરેશન પેટર્ન સંપૂર્ણ એપ્લિકેશન સ્વાયત્તતા પર ભાર મૂકે છે. દરેક માઇક્રોફ્રન્ટેન્ડ એક સ્વતંત્ર એપ્લિકેશન છે જેની પોતાની જીવનચક્ર અને ટીમ છે; શેલ અથવા API ગેટવે ફક્ત વિનંતીઓ/ડેટાને યોગ્ય ટુકડા તરફ રૂટ કરે છે. વાતચીત સારી રીતે વ્યાખ્યાયિત REST API અથવા ઇવેન્ટ્સ દ્વારા થાય છે.
એપ્લિકેશન શેલ પેટર્ન અસરકારક રીતે "હોસ્ટ" અભિગમ છે.. શેલ માઇક્રોફ્રન્ટેન્ડ્સ લોડ કરે છે, નેવિગેશન અને સુરક્ષા જેવી ક્રોસ-કટીંગ ચિંતાઓને હેન્ડલ કરે છે અને સુસંગત દેખાવ અને અનુભૂતિની ખાતરી કરે છે. મોડ્યુલ ફેડરેશન અથવા સિંગલ-એસપીએ આધારિત સેટઅપ્સ સાથે આ ખૂબ જ સામાન્ય છે.
API ગેટવે અને બેકએન્ડ-ફોર-ફ્રન્ટેન્ડ (BFF) પેટર્ન સર્વર બાજુ પર ધ્યાન કેન્દ્રિત કરે છે.. API ગેટવે ઘણી બેકએન્ડ સેવાઓ, રૂટીંગ વિનંતીઓ અને સુરક્ષા લાગુ કરવાની સામે બેસે છે. એક BFF આગળ વધે છે: દરેક ફ્રન્ટએન્ડ (વેબ, મોબાઇલ, IoT) તેની જરૂરિયાતોને અનુરૂપ પોતાનો સમર્પિત બેકએન્ડ મેળવી શકે છે.
વિતરિત ડેટા સ્ટોરેજ પેટર્ન સ્વીકારે છે કે વિવિધ માઇક્રોફ્રન્ટેન્ડ્સ તેમના પોતાના ડેટા સ્ત્રોતોનું સંચાલન કરી શકે છે. અથવા કેશ. બ્રાઉઝરમાં આનો અર્થ ઘણીવાર અલગ લોકલ સ્ટોરેજ કી, ઇન્ડેક્સ્ડડીબી ડેટાબેઝ અથવા ઇન-મેમરી સ્ટોર્સનો ઉપયોગ થાય છે, જ્યારે બેકએન્ડ પર તેનો અર્થ માઇક્રોસર્વિસ દીઠ અલગ ડેટાબેઝનો થાય છે.
અવલોકનક્ષમતા, સ્વતંત્ર જમાવટ, આડી માપનીયતા અને સુરક્ષા પેટર્ન ઓપરેશનલ ચિંતાઓને સંબોધિત કરવી: દરેક ટુકડાનું નિરીક્ષણ કેવી રીતે કરવું, વૈશ્વિક આઉટેજ વિના તેમને કેવી રીતે જમાવવું, તેમને લોડ હેઠળ કેવી રીતે સ્કેલ કરવું અને પ્રમાણીકરણ/અધિકૃતતાને સતત કેવી રીતે લાગુ કરવી.
રૂટીંગ કમ્પોઝિશન અને લેઝી લોડિંગ પેટર્ન UX અને પ્રદર્શન માટે કેન્દ્રિય છે.. માસ્ટર રાઉટર નક્કી કરે છે કે કયો માઇક્રોફ્રન્ટેન્ડ કયા પાથને હેન્ડલ કરે છે, અને દરેક માઇક્રોફ્રન્ટેન્ડનું પોતાનું આંતરિક રાઉટર હોય છે. આળસુ લોડિંગ ખાતરી કરે છે કે તમે ફક્ત વર્તમાન રૂટ માટે ખરેખર જરૂરી ટુકડાઓ માટે કોડ ડાઉનલોડ કરો છો.
છેલ્લે, ઘટના-આધારિત સંદેશાવ્યવહાર પેટર્ન ખાતરી કરે છે કે છૂટક રીતે જોડાયેલા માઇક્રોફ્રન્ટેન્ડ્સ હજુ પણ સંકલન કરી શકે છે ડોમેન ઇવેન્ટ્સ દ્વારા, સીધી નિર્ભરતા રજૂ કર્યા વિના જે મોડ્યુલરિટીના મુદ્દાને હરાવી શકે.
માઇક્રોફ્રન્ટેન્ડ્સનો ઉપયોગ ક્યારે કરવો (અને ક્યારે નહીં)
માઇક્રોફ્રન્ટેન્ડ્સ સારી રીતે વ્યાખ્યાયિત કાર્યાત્મક ડોમેન્સ સાથે મોટા, જટિલ એપ્લિકેશનોમાં ચમકે છે.. ઈ-કોમર્સ પ્લેટફોર્મ, એન્ટરપ્રાઇઝ મેનેજમેન્ટ સિસ્ટમ્સ, મ્યુનિસિપલ પોર્ટલ, શિક્ષણ પ્લેટફોર્મ, મોટા આરોગ્ય પોર્ટલ અથવા કોઈપણ ઉત્પાદનનો વિચાર કરો જેમાં ઘણી ટીમો અલગ કાર્યાત્મક ક્ષેત્રો પર કામ કરતી હોય.
જ્યારે તમારી પાસે સમાંતર રીતે કામ કરતી બહુવિધ ટીમો હોય ત્યારે તે ખાસ કરીને ઉપયોગી છે. જેને ટેક પસંદગીઓ, પ્રકાશન ચક્ર અને પ્રાથમિકતાઓમાં સ્વાયત્તતાની જરૂર હોય છે, અથવા જ્યારે તમે ધીમે ધીમે લેગસી ફ્રન્ટએન્ડનું આધુનિકીકરણ કરી રહ્યા હોવ અને સંપૂર્ણ પુનર્લેખન પરવડી શકતા નથી. તમે એક સમયે એક ક્ષેત્રને નવા માઇક્રોફ્રન્ટએન્ડમાં કોતરીને તેને જૂના શેલ સાથે એકીકૃત કરી શકો છો.
જ્યારે એપ્લિકેશનના વિવિધ ભાગોને અલગ રીતે સ્કેલ કરવાની જરૂર હોય ત્યારે પણ તેઓ મદદ કરે છે.. લોગિન અથવા ચેકઆઉટ પેજ એડમિન કન્ફિગરેશન સ્ક્રીન કરતાં ઘણો વધુ ટ્રાફિક મેળવી શકે છે; તે સ્લાઇસેસને સ્વતંત્ર રીતે સ્કેલ કરવાથી ઇન્ફ્રાસ્ટ્રક્ચર ખર્ચમાં ઘણો બચાવ થઈ શકે છે.
જોકે, માઇક્રોફ્રન્ટેન્ડ્સ મફત લંચ નથી. તેઓ આર્કિટેક્ચરલ જટિલતા ઉમેરે છે, UX અને શેર કરેલા કરારો પર મજબૂત સંકલનની જરૂર પડે છે, અને નવા નિષ્ફળતા મોડ્સ રજૂ કરે છે (ઉદાહરણ તરીકે, એક ટુકડો લોડ થતો નથી). એક જ ટીમ સાથે નાના અથવા મધ્યમ એપ્લિકેશનો માટે, સારી રીતે સંરચિત મોનોલિથ ઘણીવાર સરળ અને વધુ ખર્ચ-અસરકારક હોય છે.
ટીમોએ "ફ્રેમવર્ક અરાજકતા" થી પણ સાવધ રહેવું જોઈએ.. જ્યારે દરેક માઇક્રોફ્રન્ટેન્ડ માટે સંપૂર્ણપણે અલગ સ્ટેકનો ઉપયોગ કરવાનું તકનીકી રીતે શક્ય છે, ત્યારે ફ્રેમવર્કનું અનિયંત્રિત મિશ્રણ ભરતી, ટૂલિંગ અને કોડ શેરિંગને વધુ મુશ્કેલ બનાવે છે. સંરેખણનું વાજબી સ્તર (ઉદાહરણ તરીકે, "અમે રિએક્ટ-ફર્સ્ટ શોપ છીએ, પરંતુ અમે ચોક્કસ ડોમેન્સ માટે એન્ગ્યુલરને મંજૂરી આપીએ છીએ") સામાન્ય રીતે લાંબા ગાળે વધુ સારી રીતે કાર્ય કરે છે.
માઇક્રોફ્રન્ટેન્ડ્સ બ્રાઉઝરમાં માઇક્રોસર્વિસિસ માનસિકતાનો વિસ્તાર કરે છે, ટીમોને મોટા ફ્રન્ટએન્ડ્સને સ્વાયત્ત, ડોમેન-લક્ષી ટુકડાઓમાં વિભાજીત કરવાની રીત આપે છે જે એપ્લિકેશન શેલ, શેર્ડ લાઇબ્રેરીઓ, મોડ્યુલ ફેડરેશન, વેબ ઘટકો અથવા સિંગલ-એસપીએ જેવા ઓર્કેસ્ટ્રેશન ફ્રેમવર્ક દ્વારા જોડવામાં આવે ત્યારે એક સુસંગત વપરાશકર્તા અનુભવ બનાવતી વખતે સ્વતંત્ર રીતે વિકસિત, જમાવટ અને સ્કેલ કરી શકે છે.