In the , we I've shared my knowledge and experience about the and how it affects our . previous part components React app architecture Today we will dive deep into architectural approaches, microservices, and microfront-ends. code-splitting: Architectural approaches Every modern web-app uses due to its open-source community, standards, applicability, tools and many other things which make JavaScript stand out from the crowd. In bunch of projects it leads to an increase in complexity, development time, testing time, release cycle and entry level for developers. Most often have such problems as they are large apps. JavaScript monoliths is an architectural approach which blends the main app logic and server-related code so that application consists of a of different components. Monolithic architecture one-layer combination I have an extensive experience in developing and I found out several of handling them: monoliths cons significant amount of legacy code a lot of logic is mixed through the whole app different components have similar naming easy to brake something down a bunch of duplicated code Using , instead of , we divvy up our app into a set of small, reusable modules that interact with each other on their own layers. One of the main advantages of a micro-services is that your apps becomes flexible and you can easily use oppropriate tech stack for every single task. micro-service architecture approach monoliths Moreover, with micro-services you can reduce testing and deployment time, app complexity, use modular approach and do different tasks in parallel. In case of UI development this approach is named as . microfront-ends Microfront-end is an architectural approach during which independent applications are . It makes it possible to mix different widgets or pages written by different teams using different frameworks in one application (see the figure below). collected into one large application Relying on my professional experience I can list the of the microfront-end approach: main advantages use pages and widgets as completely independent applications easily test isolated parts of functionality parallel deployments Speaking about cons, I can mention the following: application complexity increases huge difference in the JS bundle size in comparison with monolithic application issues with caching and versioning (use lerna!) On the one hand, using this approach in small projects can be . On the other hand, large projects with distributed teams could find more profitable building microfront-end apps. This is the reason why today the microfront-end architecture is widely used by many large companies in their web applications. not reasonable Code splitting Multiple Apps Here we have - with our own webpack, some states, routes, and components that we share between them. several independent applications For example, : you are authorized in one application and remain authorized between all applications of the platform and technically you are on the same website. But you lose the state and cannot share the state in this case, because these are different domains, different websites, but they have common components and they look the same: single sign-on Single Apps We can setup one mega-website and call it a , in which we can create more mini-applications due to chunks, by splitting code into pieces. It all looks like a : we have one level (authorization), work with data is another level, analytics, admin panel... they're nested: Single App graph And how it works : under the hood We have a kind of common ( ) . This app knows how to work with permissions and redirects, handles state, cookies, and auth errors by redirecting you to the auth page. By the way, auth can also be a separate application that lives independently, which has its own modules, state, routes, and its own localization. shared application Just imagine that the website has 1000+ pages and you have 1000+ localizations and your localization file size more than the entire website size. Fortunately, it is well handled by and chunks so as you haven't download unnecessary things: Webpack ( ) ( )
...
import( ) import /* webpackChunkName: "sign-in" */ './features/SignIn' import /* webpackChunkName: "localize" */ './utils/Localize' /* webpackChunkName: "chunkName" */ './path' State managing Nowadays, there are a bunch of like , , , , etc.. The main advantage is that you can use dev tools and watch the state change in a time-lapse: state managers Redux MobX Flux Rx.js In the real life, everything can be resolved with the or or some other library or approach. Context GraphQL The typical looks like this: Redux data flow Let's say there is some kind of data flow, we need to make a request to the server. We have some kind of choice of (web-rtc protocol, http, sockets), there is a kind of above the API that handles api-requests, that map data into a normalized structure. There can be an , , , Then we pass this data in props to the component. data streams abstract layer adapters action store reducer selectors. Well, all this can be : easily split Here we have an app and we can easily so that each will have its own. As I said before, we should represent it like a to avoid building a kind of and website. share the state module graph plain architecture For example, in we have a that shares the state to the whole app: Redux provider React ReactDOM { Provider } { App } createStore store = createStore()

ReactDOM.render( <App /> , .getElementById( )
) import from 'react' import from 'react-dom' import from 'react-redux' import from './App' import from './createReduxStore' const < = > Provider store {store} </ > Provider document 'root' Conclusion Web-development, as well as architectural approaches and tools, is growing every day. , like any other architecture approach, has it's own pros and cons. You should design app architecture according to your team, project and app needs. Anyway, it's better to keep this in mind and be preprapared for any circumstances and projects. Microfront-end architecture In the next part, we will cover the and develop our own from the old application. So and have a nice hacking! frontend metrics migration plan stay tuned

Flow

BUNCH

React Application Architecture: Components [Part 1]

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

React Application Architecture: Code splitting [Part 2]

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

React Application Architecture: Components [Part 1]

A Deep Dive Into The Architecture of React: Structure and Dependencies (feat. Eunice)

React Application Architecture: Components [Part 1]

3 Things You Will Love About Micro Frontends

A Method That Will Help You Clone Netflix With Micro Frontends The Right Way

React Application Architecture: Components [Part 1]

A Deep Dive Into The Architecture of React: Structure and Dependencies (feat. Eunice)

React Application Architecture: Components [Part 1]

3 Things You Will Love About Micro Frontends

A Method That Will Help You Clone Netflix With Micro Frontends The Right Way

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps