Enterprise Frontend Application Architecture
(medium.com)-
कोडबेस का बड़ा होना = उसे समझना भी कठिन, और उसमें बदलाव करना भी कठिन
-
समाधान क्या है? कोडबेस को छोटा बनाए रखें.
-
डोमेन के आधार पर कोडबेस को अलग करना & micro frontend मदद के लिए!
-
monorepo के भीतर लाइब्रेरी dependency relation सेट करना & dependencies की जाँच जैसी ज़रूरतों को Nx अपनाकर हल किया गया
-
कोड को application और library में अलग करना
-
application की भूमिका dependency और configuration injection की है
-
अधिकांश functionality लाइब्रेरी में implement की जाती है
- लाइब्रेरी में न सिर्फ सामान्य रूप से उपयोग किए जा सकने वाले design system, internationalization, third-party modules, बल्कि home page का hero banner, product detail page, order history जैसे non-reusable code भी लिखे जाते हैं.
Feature लाइब्रेरी
-
मूल रूप से, किसी एक page में उपयोग होने वाले सभी components उसी नाम की Feature लाइब्रेरी में लिखे जाते हैं
- उदाहरण)
accountडोमेन केSignInPageपेज के सभी componentsaccount/feature-sign-inलाइब्रेरी में लिखे जाते हैं
- उदाहरण)
-
एक ही डोमेन के दो या अधिक pages में साझा होने वाले components को उसी डोमेन के भीतर अलग feature में विभाजित किया जाता है
- उदाहरण) अगर
accountडोमेन केSignInPageऔरSignUpPageमेंKakaoLoginButtoncomponent कॉमन रूप से उपयोग होता है, तो वह componentaccount/feature-social-loginलाइब्रेरी में लिखा जाता है
- उदाहरण) अगर
-
अलग-अलग डोमेनों के pages में साझा होने वाले components को shared डोमेन के भीतर अलग feature में विभाजित किया जाता है
- उदाहरण)
landingडोमेन केHomePageऔरclassroomडोमेन केLecturePageमें साझा होने वालाGlobalNavigationcomponentshared/feature-navigationलाइब्रेरी में लिखा जाता है
- उदाहरण)
Shell लाइब्रेरी
-
Feature, UI लाइब्रेरी के components को संयोजित करके pages बनाए जाते हैं
- उदाहरण)
SignInPagecomponent account/shell-kr-web लाइब्रेरी का component है. इसमेंSignUpPage,PhoneVerificationPageआदि शामिल हैं.
- उदाहरण)
-
Shell लाइब्रेरी application को दिए जाने वाले किसी विशेष डोमेन का entry point है
-
हर application के लिए अलग entry point दिया जा सकता है
-
उदाहरण के लिए..
-
HomePagecomponent में उपयोग होने वाले componentslanding/feature-homeलाइब्रेरी में लिखे गए हैं. -
लेकिन वही
HomePageभी इस पर निर्भर करते हुए अलग हो सकता है कि वह US site काHomePageहै, Japan site काHomePageहै, या Korea site काHomePageहै. -
इसलिए
landingडोमेन तक पहुँचने वाले हर application के लिए अलगshellलाइब्रेरी बनाई जा सकती है. (shell-us-web,shell-jp-web,shell-kr-web)
-
Provider लाइब्रेरी
-
ऐसी लाइब्रेरी जो दो या अधिक Feature लाइब्रेरी के बीच साझा state को manage करती है
- उदाहरण) login state को manage करने वाला
shared/provider-auth-state
- उदाहरण) login state को manage करने वाला
UI लाइब्रेरी
- दो या अधिक लाइब्रेरी में साझा होने वाले presentational components का संग्रह.
Utility लाइब्रेरी
-
वे सभी modules जो ऊपर की 4 श्रेणियों में नहीं आते
-
इन्हें CLASS101 के domain model से असंबंधित, और test व deploy किए जा सकने लायक स्वतंत्र functionality देनी चाहिए.
- उदाहरण)
shared/utils-apollo-client,shared/utils-i18n
- उदाहरण)
Application
- यह केवल configuration और dependency management की भूमिका निभाता है = application का code लगभग नहीं के बराबर होता है
अभी कोई टिप्पणी नहीं है.