React architecture for a huge business application

Question

So we\'ve recently picked up React in our company as the front-end technology to build our huge business web application. By saying recently, I mean we don\'t have any previous

Answer 1

We started a large scale business application using Reactjs as frontend technology. We have over 30 people in the team and we have over 15 modules in our product.

My approach is to the project is developing a common react project that handles only the Authentication, authorization and routing of the application and all other components developed as separate npm react libraries.

To develop the libraries I used https://www.npmjs.com/package/create-react-hook

This library generates the template with an example app which can use to test our library.

Following is the structure of the project

--Library 1 ( Developed using create-react-hook )

--Library 2 ( Developed using create-react-hook )

...

--Library n

--Common Container App (Developed using create react app and have used all above libraries using npm install)

The main advantage of this approach is developers can focus only on their npm packages and they can develop and test relevant component(s) separately. The deployment also becomes very easy because we can just update npm package of tested version and rebuild the container app and do the deployment without affecting any other part of the application.

We are using this for several months and running the project with a large team without any issue. I think this may be helpful to anyone else too.

Answer 2

Getting started writing more complex apps in React can really be a struggle, I know exactly how it feels!

As you say, React is a UI lib and not an event framework. That's why you typically need a library to handle events, for example Redux. You clearly state that you decided not to use Redux (you even used capital letters for not :) ). I would take a step back if I were you and reconsider that decision. You say the reason for not using Redux is that your cannot keep your components easily pluggable and reusable when using Redux. I would argue that is not true. Redux is totally decoupled from your React components. Redux only handles receiving events, and managing state. From the React components point of view, it just receives data in props and sends events by calling regular functions. It's possible to still unit-tests, reuse, etc.

I would suggest you take another look at Redux with this in consideration. Happy to help if you have more questions!

Answer 3

So this is just to share my experience working on an enterprise react application that is in production for years in several banks. yes, you heard me right. Now you can imagine how huge the application will be if it's related to fintech (I know it's not always the case). we have huge modules (70+) with a complex logic that pretty much handles a lot of the work that a bank needs. Modules are both isolated and re-useable. I am going to give an example of only one module so you can imagine the size of each module.

• Card Production Module

1. Bulk Card Generation
2. Bulk Card Export
3. Bulk Card Request
4. Card Operations
5. Card Operations Approvals
6. Card Printing
7. New Card Requests
8. Pin Generation
9. Pin Printing

This application is a product, not a project and as a product it is configurable. Even the UI is configurable. I have been working on this application as a full-stack developer. Since it's pretty old the state management library that we are using is flux. With state management, the development speed is a little slow but the tradeoffs are better with us not being worried about state management. By far the application has been able to handle huge changes and things which seemed unachievable. Stability has also been a key element throughout this period.

On the back-end, we have Restful services build using Dot Net which supports both MSSQL Server or Oracle depending on the client's needs/feasibility.

Answer 4

There is absolutely no question that React/Redux can (and is widely) used to develop the kind of applications that you describe. Nothing in your description makes what you are building so unique that it excludes React as a platform for building it. We are actively working with a large enterprise customer who is building their entire front end - with 100 + SPA (Single page applications) in React. This is a team of over 100 developers over a 2-3 year project.

The way we structured this has been crucial -

First, you want to choose a UI component library. A few examples below :

• MaterialUI - https://github.com/callemall/material-ui
• React Strap - https://github.com/reactstrap/reactstrap
• React Bootstrap -https://github.com/react-bootstrap/react-bootstrap
• Khan Academy React Components https://github.com/Khan/react-components
• https://github.com/elementalui/elemental

We basically took one of these and built a component library off of them, because our components are very custom styled.

Second, we created a modular architecture, where each module (SPA) is an npm package with a main container component and redux store.

Finally, we have a central server package, where each of the modules is registered. The server package is responsible for authentication, authorization, logging, routing, etc.

The essence of this answer is not to advise on how to structure a large React application, but to let you know that React can be (and is being) used to develop applications similar to what you are describing.

Answer 5

Completely understand your feelings when you start with React and Redux. We were in the same situation when we started with React in our company. At first React has different approach than other frameworks. Yes of course it's not framework, it's just library. You have to start thinking in React way and that is: React components just render state (It's like you render scene on your graphic card at first you have to prepare scene then you are able render), all what component can do is dispatch actions, or better call just action creators.

You need some smart way how to store state in that point I will suggest use Redux.

We also use TypeScript with combination React, Redux. you have to write more code than pure JS but static type control is priceless when you work on large project.

Separating components logic is native approach of react ... you have to separate logic write "Dummy components" and then reuse this with connect. Or passing values as props.

We are using Thunk middleware as action creators it's good because connected component will call just method and logic is in action creators. You have access there to whole state of app then you can fetch something and base on result you can dispatch different actions.

What I like on react/ redux is how to implement async calls etc. First design component to map all states

1) like I have no data 2) data loading 3) loading done 4) loading error

For that you need only one semaphore in you state and a few checks in render method. Then one action creator that will load data and base on progress dispatch action that describing progress.

What is also cool that in react/redux app you have single data flow it's good when new dev jump into project.

For UI we are using Material UI, yes this framework has some problems but nothing what you will not able to deal with.

We are using also Router for navigating in app.

In the beginning I will avoid server side rendering because it will much easier for you start just with client side rendering and with initial state.

When we start for us was useful this template where everything works in one project JavaScriptServices

Then off course great Abramov tutorials.

For design components very useful Storybook

We can write why use or not React for long time ... but What I can say ... for us it was good choice, with some pain in begging but now we have good payback.

Answer 6

You nailed the issue in your question- react is a view library, not an application framework. The real question is whether React+Redux(or other state management system) is appropriate for a large LOB app.

I will share some insights from our team’s experience in this realm. Large LOB apps have been developed using the MVC/MVP/MVVM design patterns for decades. These are tried and true patterns that ship software. Couple that with dependency injection and you have a modularized, testable, maintainable application. AngularJS (2.0+) is founded on these principles and leverages them deeply. For this reason we use AngularJS for all of our enterprise line of business apps.

React on the other hand is a lightweight, spritely view render that is awesome for smaller applications and client facing pieces (for example taking a dynamic survey or a simple dashboard). We often turn to React and VueJS here because the full AngularJS stack is way overkill and too heavy.