The document discusses the architecture of modern frontend applications, emphasizing the importance of structured designs like layered architecture, smart and dumb components, and various organizational approaches such as fractal architecture and atomic design. It highlights benefits like enhanced testability, scalability, and risk management, while also noting challenges such as reusability and predictability in rendering speed. Additionally, it covers how to effectively organize data stores, advocating for normalization to optimize performance and minimize redundancy.

1. Architecture of
modern frontend
applications
Yuriy
Dobryanskyy
Summer. Sea. JavaScript.

2. ● Why do we need this
● How did we get here: MV*
● Approaches to organization of smart
components
● Fractal architecture
● Atomic design
● Ducks
● How to organize store(s)
Plan

3. Architecture gives
the ability to
communicate about
design decisions
before the system
is implemented,
when they are still relatively easy to adapt. It helps in
risk management. Software architecture helps to reduce
risks and chance of failure. It enables cost reduction.(c)
Why do we need this

4. Benefits of layered
architecture:
● Separation of
business logic and
user interface
● Better testability
● Better scalability
How did we get here: MV*

5. Controller
1
* InputView
Model
Presenter
1
1 InputView
Model
How did we get here: MV*
Update
*
*
InputView
Model
View Model
1
*
InputView
Model
Backbone
Ember.js
Angular.js
Backbone
Google Web
Toolkit
Riot.js
KnockoutJS
Kendo MVVM
Knockback.js
Elm
Redux

6. Approaches to organization of smart
components
Smart components
(focus on how things
work):
● Manipulate Data
● Call Redux, Lifecycle
methods, APIs,
Libraries, etc
● Manage state
● Rarely includes styling
Dumb components
(focus on how things
look):
● Focus on the UI
● Accept props
● Require no app
dependencies
● Rarely include state

7. Pros:
● Predictable backend
requests
● No duplication of
backend requests
● Clear guidelines for
creating components
● More predictable
rendering speed
Smart page components
Cons:
● Harder reusability
● Passthrough props

8. Pros:
● Simpler reusability
● No need to pass
props very deep
● Each part of
component tree can
be self-sufficient
Smart granular components
Cons:
● Hardly predictable
back-end requests
● Possible duplication
of backend requests
● Vage criterias of the
component being
smart or dumb
● Less predictable
rendering speed

9. Rules:
● Application is a tree of components of the same
API.
● Each component is able to contain (use) other
components.
● Top component does not differ from other
components.
● Glue and application lay apart from each other.
Fractal architecture
Fractal is an unidirectional
user interface architecture
that is fractal ©

10. Pros:
● Each component can be easily
reused and understood
● Easy copy-pasting from one
repo to another
● Easy separation of subteams
Cons:
● Dependencies cause
duplication
Fractal architecture

11. Ducks
Function-first Feature-first

12. Ducks module
must:
● export default reducer
● export action creators as functions
● have action types as
npm-module-or-app/reducer/ACTION_TYPE
may:
● export action types as UPPER_SNAKE_CASE
Ducks after redux === REDUX === ducks

13. Atomic design
“A methodology for
thinking of our UIs as
thoughtful hierarchies”©

14. Pros:
● clear methodology
● ability to traverse from abstract to concrete
● assembling rather than deconstructing
Cons:
● None. This is NOT an architectural pattern. It is a
logical way of segregating components.
Atomic design

15. Major ways of
organization of data
inside store:
● Normalized
● Denormalized
How to organize store(s)

16. Data from backend should come denormalized. This
guarantees:
● Less communication round trips
● Faster page load
Denormalized data should not be stored in the
store. Because of:
● Hard to update the same data in multiple places
● Complex, ugly reducers
● Unrelated components re-render
Denormalized data

17. Store normalization concepts:
● Each data type has own part of store’s tree(“data
table”)
● Data table structure: {[id1]: item1,
[id2]: item2, …}
● References to other data tables stored as ids
● Arrays of ids used to indicate ordering
Normalization

18. Denormalized Normalized

19. ● Presentational data(ordering, paging, filter, etc.)
should be denormalized
● Business domain data should be normalized
● Compatible with atomic, ducks, fractal, etc
● Normalization should be done automatically -
use normalizr(or similar)
To normalize or not to normalize

20. Conclusion

21. Questions?

22. Contacts
https://github.com/yuriydobryanskyyempeek
https://www.linkedin.com/in/yuriydobryanskyy
yuriy.dobryanskyy@empeek.com
Phone number: +38 097 177 26 15