Architecting your React application. Thedevelopment and business perspective of what to beaware of

Roman Nguyen Follow

Jan 14, 2019 · 8 min read

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.

In

This article assumes that you already have some experience with creating at least small

React apps and you are about to make some bigger architecture decisions on your (first)

large scale application. React is a great tool to accomplish building something

extraordinary, however I often see developers trying to use React anywhere they can. If you

are about to build something small that doesn't require too many backend services, maybe a

presentation (landing pages) of your product, I totally recommend Webflow to save your

time with creating your intentions by designing with minimum coding and deployment

knowledge!

Table of contents

1. Before you start

2. Team Scalability

3. Choosing libraries for your stack

4. My picks

5. Summary

o, 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

S

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.

In my very first article, I wrote some thoughts about designing your application in terms of

UX, even though it's meant for designers, it's written from a perspective of a dev/product

guy. Even development needs good UX.

Team scalabilityI've set up many projects there is one thing to say. There is no worse beginning of a

project when your colleagues have to learn too many new things to start. Have you been

on boarded to a project in the middle of a development and it took eternity to

understand it? 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 clarity 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-app

Setting 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 Library

This 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 @janlosert, 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 our 15 precoded page previews and the

components here.

Update 26th March 2020: We've released core components on github and npm as a

library anyone can install!

State management — ReduxChoosing redux is a no brainer 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 summary

As 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!

. . .

📝 Read this story later in Journal.

🗞 Wake up every Sunday morning to the week’s most noteworthy Tech stories,

opinions, and news waiting in your inbox: Get the noteworthy newsletter >

React Redux Front End Development Programming JavaScript

About Help Legal

Get the Medium app