DEV Community

Cover image for How to create a scalable and maintainable front-end architecture

How to create a scalable and maintainable front-end architecture

Kevin Pennekamp on August 26, 2019

Modern front-end frameworks and libraries make it easy to create reusable UI components. This is a step in a good direction to create maintainable ...
Collapse
ceceliacreates profile image
Cecelia Martinez

Wow, great write-up! Thank you for going into so much detail and the graphics, they make things so much clearer.

Collapse
crinklesio profile image
Kevin Pennekamp Author

Thanks for your nice comment!

Collapse
riccardomessineo profile image
Riccardo Messineo

Great post,
I love how you introduced the pattern without attaching it to a specific frontend framework.

Thanks!

Collapse
crinklesio profile image
Kevin Pennekamp Author

Thanks! That was also one of my goals when starting this article. Good to see that it is also noticed

Collapse
wbern profile image
William Bernting

How scalable is one redux store for an entire application?

Collapse
crinklesio profile image
Kevin Pennekamp Author

Hi William,

My first tip would be not to depend on only one thing. It was one of my own bigger mistakes made in the past. I choose a technology and tried to apply it as much as possible, making my own life even more difficult.

That aside, state management is difficult and many different solutions exists. I do not think there is one solution you can choose for a big front-end application. You should always question yourself: do I need this state on application level, or is it only required in a more scoped environment? Some examples you can use for state-management techniques, than can be combined are:

  • Redux for your application state, mainly for sharing data between different parts of your application. Here you can also manage errors and request states (e.g. loading) with a proper reducer design. You could for instance create a generic reducer setup for CRUD operations (only the name will be dynamic), making it more scalable;
  • Redux for application settings and configurations that only need to exist on the front-end;
  • React Context on an application level for maintain states around for instance small configurations, like language. Choosing only Context, you make it only dependent on React, making it more sharable between projects, but also within the project. Otherwise choosing a correct big store-design would become more difficult. And React Hooks made this a lot easier;
  • Use the cache from API clients, if available. Apollo Client for GraphQL is a great example of a client having this. This might be sufficient for your state management;
  • Use React Context for module state. Sometimes you just need state management within the pages of a module, and nowhere else. Maybe you have a complex page with a lot of nested components, all working on the same object (or objects related to each other). Or you need to maintain a state of requests you need to send when clicking save (e.g. creating and updating multiple objects), just to keep front-end and back-end consistent in data. In such a case, React Context might be the better way to go. Personally I often combine it with a reducer (using React.useReducer), which are similar to Redux reducers. So it is like lifting one reducer up into your application and apply it more scoped. The biggest advantage of React Context here, is that you can combine state with functions, both that can be used by any component living within the context.
  • Use a Reducer for individual API calls. I used to call every API through redux, as I could easily manage states of requests (e.g. loading, successful executed, or did we get back an error). But if this is the only goal for using Redux, than just create a generic function you can use for outgoing calls, that uses a small reducer. Robin Wieruch has a great article around this, using Hooks (robinwieruch.de/react-hooks-fetch-...).

In summary: yes, Redux can be used for application state and it can be scalable. You as a developer just has to make the decision where which part of the state needs to live, as not everything needs to be in the application store.

Collapse
wbern profile image
William Bernting

Good answer.

Collapse
alkafaiz profile image
Faiz Alkautsar

Good article! I pretty much understand the concept but still have one question; in what condition should we start separating the code into module? Thanks

Collapse
crinklesio profile image
Kevin Pennekamp Author

Imagine an application to manage public events, something like an enterprise version of meetup. Users are in this case those who create and manage the events. They can create programs, determine if the events are closed, configure website, etc. However, there is no Active Directory or anything available. So users and their authentication details are managed by the same backend as all other aspects of the application.

In the front-end, this is very good example of a contained module. We have to be able to create, edit, delete and read basic information of users. Handling of sending authentication emails etc. is being done by the backend. But why is this a good example of a module?

Lets assume we are building a front-end for a back-end by using standard fetch-requests, or use something like the library axios. We are also using a single application store is used for state management (e.g. redux). And for good times sake, it is a single-page application (SPA).

On the highest level, we are going to point our router towards the user module, the moment someone browses to /users/?…. At this point, our module can handle the nested routing for us, the application router does not have to do anything. In the module, we have an overview page on the index (e.g. showing a table of users for address /user), but we also have pages around create, edit, and maybe also for your own profile (as this might differ from a standard edit page).

To make these pages work, the module also handles all the CRUD requests towards the back-end, assuming they follow the same structure (e.g. they point towards the same endpoint group). This configuration of these fetch-requests, is also part of the module. But the responses of these requests are handled in the application state when applying optimistic UI. The module handles where and how this part of the application state looks.

Now assume we are in another part of the event-application. We want to change for instance the owner of an event. So we need a searcheable dropdown users. To fill this dropdown, we need to use atleast a get-request from the users end-point of the back-end. You could handle that in the page where it is located. But you can also create a UserDropdown component in the user module. This component can directly use the fetch-request already configured in the module. Furthermore, it can use the application state configured in the module. It can use existing users in the state to pre-populate the dropdown already. This way, all the logic and UI logic is handled inside the user module, and not scattered throughout your application and your code base.

Collapse
isotope2011 profile image
A. Tope Adekanbi

This is very useful. Thank you for explaining these concepts and good examples. Much appreciative.

Collapse
hermogenes profile image
Hermógenes Ferreira

Great article! I'm facing similar situation and, even though I usually follow this pattern, I'm interested to know if you already had experience making each module a separated repo. Something like micro-frontends as we have for backend

Collapse
nadeeminamdar profile image
nadeeminamdar • Edited on

Great article, Kevin! I was wondering which tool did you use to create those schematics. They look clean and simply awesome!

Collapse
crinklesio profile image
Kevin Pennekamp Author

Thanks! I created them myself in Figma

Collapse
fiammettas profile image
FiammettaS

Hello! I agree: the schematics are awesome. I am trying to reproduce something similar with Figma. Where did you get the icons?

Thread Thread
crinklesio profile image
Kevin Pennekamp Author

Pfoe, long time ago, but I believe I downloaded some .svg's from fontawesome, and played around with stokes instead of fills.

Collapse
dongyuhappy profile image
dongyu

pretty good

Collapse
atomtm profile image
Atomtm

Great article ! Any demo project you would recommend to investigate the architecture design described ?

Collapse
lorenzotrojan1 profile image
Lorenzo Trojan

This is great, thank you so much! Only thing that is missing here, is a small demo GitHub repo to really put things together, but otherwise amazing stuff!

Collapse
chirdeparag profile image
Parag Chirde

Would you suggest VueJS for the application that is based on microservices?

Collapse
crinklesio profile image
Kevin Pennekamp Author

If you mean that a microservices architecture for your back-end (e.g. running on a kubernetes cluster): yes. Any of the modern front-end frameworks can work. It is more importantly that you create a good API gateway on top of your microservices, to ensure your front-end talks to one service (the API gateway) only. This has different advantages, like: good user access control on API level, ensure certain services cannot be touched by the front-end, create API calls specifically for your front-end (e.g. Best-For-Front-end structure with GraphQL) just to name a few. With a good API gateway on top of your microservices, it should not matter if you use React, Vue, Svelte or any other framework.

I find the architecture I describe especially working well when used on top of big applications consisting of a solid front-end, a highly available API gateway, and a microservices application as a back-end.

Collapse
stnels profile image
Nelson Osazuwa

Great work, I look forward to working with you someday 😁

Collapse
khangprcvn profile image
khangprcvn

Awesome, love it.
Thank you :D

Collapse
luisestebanvera profile image
luisestebanvera

Excelente artículo amigo!

Collapse
anpos231 profile image
anpos231

This is really interesting.
Thank you :D

Collapse
jesuscrow profile image
Paulius Varna

You don't have a test folder? I will never trust you :D

Collapse
crinklesio profile image
Kevin Pennekamp Author

Ha you got me there! I found that everybody has their own way of ordering tests. My tests are almost never in a single folder, but are on that level that makes them shareable with the code across projects. As an example, I have a __tests__ inside the lib and in some cases even nested one level further.

Collapse
abdallahse profile image
Abdallah Mahmoud fahmy

Thanks for your great title, how can i write my first architecture in frontend
or just i will use framework.

Collapse
pomfrit123 profile image
***

Nice article, though I will have to re-read it couple of times.
Do you still use this architecture?

Collapse
yoginderkumar2510 profile image
abhishek sagar

Great work sir, it helped me a lot

Collapse
wffger profile image
wffger

I think the structure of app/ directory is wrong. indent is missing.

Collapse
slidenerd profile image
slidenerd

excellent post! a nice demo if possible in vue that shows your concepts in action would be super great

Collapse
becklin profile image
Beck Lin

Awesome