Architecting your React application.
The development and business perspective of what to be aware ofRoman NguyenBlockedUnblockFollowFollowingJan 14In these days where MVC feels like from the dinosaurs age.
Our APIs are serving multiple client apps and a lot of business logic moved to our client applications.
Front end development is much more than just nicely coded interface, it’s a lot of programming, sometimes the architecture can be tricky and even serving our web app might not be as straightforward as pushing things via FTP.
This article assumes that you already have some experience with creating at least small React apps and you are about to make some big architecture decisions on your (first) large scale application.
Table of contentsBefore you startTeam ScalabilityChoosing libraries for your stackMy picksSummarySo, you or your company has just decided to start a big(commercial, publicly available) project and you’ve decided to use React.
You’ve probably already done some research, otherwise you wouldn’t pick React, but there are still a lot of decisions to make what to use in your stack.
React is just a view library and there are many missing pieces.
State management, routing, localisation, styling and interface, deployment, … Do you need PWA, SSR?(Un)fortunately, there is a lot of freedom when it comes to architecting a React stack.
If you know what you are doing, you can set it up in less than a day.
Or you can struggle for a week until everything works smoothly.
Here I am going to talk about the ideal scenario since one article cannot cover all the gotchas and individual cases that might affect the decisions.
Before you start, analyse first and keep it simpleAnalysing the goals and needs should be the first thing you do anytime you start something.
Whether it’s something small or it’s a large project, write down the requirements and thoughts if you don’t have them.
Of course, requirements often change, maybe even the direction of the product, but that’s in the future and no one can predict it.
That is the reason why you shouldn’t try to predict it either.
To successfully release your very first version of the application (MVP), you should keep it simple, use only tools and libraries that are essential.
Adding more tools and libraries that might be useful in the future just adds up complexity and slows down your development.
Every developer is excited when trying something new, however I don't think that beginning of a large project is the right time to do so.
Team scalabilityI've set up many projects to say one thing.
There is no worst beginning of a project or during onboarding a new one when your colleagues habe to learn too many new things to start.
Surely, we want to project the best into the codebase, but everyone is a bit different and that applies to a thought process as well.
Javascript is a land of a madman and this is why common patterns and best practice are important.
In theory, it should help with the clearance of the code.
Surely nobody knows everything but keep in mind.
You are not writing the code for yourself exclusively.
Also… What do you think of a code you wrote a year ago?.I got headaches sometimes so I want to make sure that it will be as least painful as it can be for the others after reading my code!.Surely development tools such as eslint and flow (or if you like typescript) helps with maintaining the codebase within a large team.
Choosing the right libraries for your javascript project.
Which one is the best?It’s the library you and your team know the best and you are comfortable working with.
Seriously.
Do you know Redux well?.Then use Redux for the state management.
Do you like MobX?.Then use MobX.
A stack is only as good as the developer(s) working on it.
I am not saying that you shouldn’t use anything new, I like learning new things as you do, but personally for me, those new things belong to some internal or personal projects where mistakes and little knowledge are acceptable.
Learning a new library is not only about reading the documentation, sometimes these libraries use totally different approach and patterns and it always takes time to master.
Still feeling like you should use something you've heard about?.One or two new things are fine, but make sure that it won’t affect the quality of the project.
And like it or not, you will have to think about other people as well.
A good developer knows how to code.
A great developer knows how to work in a team.
And having a shared knowledge is much more powerful for your team and business.
Using common patterns and best practice was not made for fun, and the same applies when you are deciding about your architecture.
Common technology (not outdated!) can speed up your development rapidly when the team grows.
My choices of libraries when setting up a new projectI think you've might already guessed where I am heading.
For a large project, I don't like to experiment.
Quality, reliability and scalability should be one of those top priorities you should focus on.
Here are my favourite picks.
Dev stack and toolkits — razzle or create-react-appSetting up your project really from the ground with webpack and babel is surely great and challenging, but in the future, you don't want to spend extra hours on updating it for hours.
Luckily, there is a large and helpful community in the react ecosystem that has built great tools to start.
It's not a shame to take advantage of something that has been built.
It's proven and there are many answers for your questions.
If I need server, I currently use razzle (or after.
js) which I really enjoy using for it's simplicity, configurability and speed.
Alternatively, you can try next.
js, however for my needs it is somehow too strict or limited when it comes to asynchronous tasks.
If I know that I don't need server or server side rendering, I always go with create-react-app.
Beside the standard build tasks it also has nice features built in, such as PWA.
UI LibraryThis is a very tricky part where I don't have an answer.
There are tons of UI libraries, such as material-ui or ant design.
Many might add up some complexity, such as styling and theming and you will have to learn a bit about the library as well.
So what would I do?.You might find yourself and your team in a situation where you don't have an experienced UI/UX designer.
Now, If that would be me, I would already feel quite uncomfortable, because for me a good design, good UX and interactions are as important as any other thing.
In this case, I would probably use some library with a lot of research.
I would consider myself a near to expert when it comes to html & scss and I think a lot of people actually underestimate the power and how much knowledge and experience you should have with it.
And here I find many libraries hard to shape, style, reconfigure or it's just too complicated.
Then again, many people say that it is too expensive to develop your own UI library.
If you have a great designer, I would go with inhouse UI library, because learning and reshaping the selected library will take a lot of time as well, otherwise I would consider something with a good documentation.
For many reasons above, I decided to accept the challenge of my friend, who is also a great designer, and we released a Dashboard UI Kit, which also comes with more than 70 styled components.
You can check out 15 precoded page previews and the components here.
State management — ReduxChoosing redux is a nobrainer for me.
The thought behind it is simple and it aligns well with functional programming approach, which is straightforward and easy to understand.
Once you get the idea, you can try many plugins and middleware libraries, such as redux-thunk or it's enhanced clone redux-thunker or redux-promise-middleware.
Localisation — react-i18nextThis is probably more of a preference, but I like to use this library as it is fairly simple to setup and use in the project.
There are also many open source tools to localise your content with an admin dashboard.
Routing — react-routerThis is my favourite pick.
If you've ever built any web apps that were not based on react, then the concept of react-router might take some time to understand, but since it is based on react, it shouldn't be a problem!.I really enjoy the declarative way of routing as well as the components and their usability.
Choices summaryAs you can see, you've probably already heard of these before.
And these picks have a common reasoning.
They are well known among the community and most probably you will find many people in your team who knows it as well.
It's totally fine to use something that everybody does, because the truth is, the business always comes first.
And in terms of business, you need a reliable product and a team which can grow with your goals.
One huge advantage for the developers is also the fact that the community is so large that when you are struggling with a problem, most probably you will find an answer, whether it's stackoverflow or the github pages.
A good documentation is important for developing and that's where commonly known libraries shine.
Surely, this article cannot cover other choices and technology that will affect your overall architecture, such as GraphQL.
However it should answer you whether you should use them or not.
SummaryI love to experiment with new things and learning always pushes me forward.
Whether it is development, product or business, there is always room to push yourself few steps further.
As a developer, I am always excited about new technologies, however having a perspective as product owner, it is also important to understand the need of the business, the company/startup which you are part of.
With that said, I don't think you should experiment (too much) with important or critical applications.
The true skill of lead or senior developers is knowing which tool to use in certain situation and get most of it while keeping in mind possible risks for both development and the business.
Happy coding!.