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 ...
For further actions, you may consider blocking this person and/or reporting abuse
Wow, great write-up! Thank you for going into so much detail and the graphics, they make things so much clearer.
Thanks for your nice comment!
Great post,
I love how you introduced the pattern without attaching it to a specific frontend framework.
Thanks!
Thanks! That was also one of my goals when starting this article. Good to see that it is also noticed
How scalable is one redux store for an entire application?
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:
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.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.
Good answer.
Great article, Kevin! I was wondering which tool did you use to create those schematics. They look clean and simply awesome!
Thanks! I created them myself in Figma
Hello! I agree: the schematics are awesome. I am trying to reproduce something similar with Figma. Where did you get the icons?
Pfoe, long time ago, but I believe I downloaded some .svg's from fontawesome, and played around with stokes instead of fills.
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
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
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
routertowards 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
UserDropdowncomponent 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.This is very useful. Thank you for explaining these concepts and good examples. Much appreciative.
pretty good
Great article ! Any demo project you would recommend to investigate the architecture design described ?
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!
Would you suggest VueJS for the application that is based on microservices?
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.
Great work, I look forward to working with you someday 😁
Awesome, love it.
Thank you :D
Excelente artículo amigo!
This is really interesting.
Thank you :D
You don't have a test folder? I will never trust you :D
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 theliband in some cases even nested one level further.I think the structure of app/ directory is wrong. indent is missing.
Thanks for your great title, how can i write my first architecture in frontend
or just i will use framework.
Nice article, though I will have to re-read it couple of times.
Do you still use this architecture?
Great work sir, it helped me a lot
excellent post! a nice demo if possible in vue that shows your concepts in action would be super great
Thanks for this article, used a similar structure for project but not as clean and well structure, would definitely be following this structure for better scale!
Awesome