4. Why should I care?
More developers to touch frontend code
◦ Frontend is getting more complex
◦ Static -> Dynamic -> Ajax -> Responsive -> SPA -> Progressive
◦ More full-stack developers
More developers = less productivity
In this session:
◦ Generalized patterns & how they evolved due to the team size
◦ (Usual) Pros & Cons of each patterns
8. Cons
Tightly coupled
◦ “Backend is broken again, I have to work on last week’s commit”
◦ “Let’s create backend first”
Frontend development speed
◦ “I have to wait for 1 minutes to test 1 line of JavaScript change”
Unit testing
◦ “It takes me 5 times of coding to write tests”
Reusability
◦ “How can we get data from the new mobile app?”
Performance
◦ “We cannot utilize CDN much”
10. #2 Separated-Frontend Pattern
Characteristics:
◦ Frontend code is separated from Backend code
◦ Might live in a different repository
◦ (Mostly) Served as static resources
◦ Data passing via AJAX
13. Pros
Loose coupling
◦ “My frontend can run on mock API”
◦ “Let’s add a new mock response to test that error”
Frontend development speed
◦ “Livereload tool refreshes the page immediately”
Unit testing
◦ “I still hate writing unit tests, but still suffer less”
Reusability
◦ “Let’s check our existing API and see what we could tweak for mobile team”
Performance
◦ “Most of our resources are static. We can cache at CDN”
14. Design trade-off: Server-generated index
page?
Static
◦ (+) Frontend can live in a separate repository
◦ (+) (slightly) Less load on server
◦ (+) Easier to adopt Serverless approach
◦ (-) Extra Ajax call for initial data
Server-generated
◦ (+) Have all required initial data => no one extra Ajax call
◦ (+) Easier to A/B Testing
◦ (-) Not fully separated, people usually inject global variable
15. What about 10, 15, 20 developers?
Regression
◦ “Oops, I broke your feature again today. That was unintentional, really…”
Conflicts
◦ “Why do always we change the same file?”
Dependencies
◦ “Please don’t make any change in your code while I’m working on this”
16. 1. Continuous Integration
CI Server
CI Software
Version Control
Repository
(Git, SVN, etc.)
commit/push Trigger
• Build (Lint, concat, uglify)
• Unit test (+ coverage check)
• Integration test
• End to end test
17. What are the challenges when
you have a large team doing CI?
18. CI with many developer
~3 people commit in the same integration window
◦ The build fails…
◦ Who broke the integation?
19. Troubleshooting when Integration is
broken
CI Server
CI Software
Version Control
Repository
(Git, SVN, etc.)
commit/push Trigger
• Build (Lint, concat, uglify)
• Unit test (+ coverage check)
• Integration test
• End to end test
20. Troubleshooting when Integration is
broken
CI Server
CI Software
Version Control
Repository
(Git, SVN, etc.)
commit/push Trigger
• Build (Lint, concat, uglify)
• Unit test (+ coverage check)
• Integration test
• End to end test
21. Troubleshooting when Integration is
broken
CI Server
CI Software
Version Control
Repository
(Git, SVN, etc.)
commit/push Trigger
• Build (Lint, concat, uglify)
• Unit test (+ coverage check)
• Integration test
• End to end test
22. 2. Separate modules by repository
Result:
◦ Force developers to design clear interface between module (loose coupling)
◦ Each module has their own unit and partial integration test
◦ Each repository can become an NPM module which we could manage the version dependency
Problem:
◦ How are we going to integrate them into a single site?
25. MicroPages - Con
1. Handling duplication
◦ Duplicated features: Header (auth/login), Menu bar, Footer, CSRF, Ajax call, Data Model
2. Inconsistent UI and UX
◦ ex. Button, Modal, Date Picker, Page Layout, Alignment, Loader, etc.
3. Page refresh
◦ UX
◦ More resources to load (ex. Angular, React, jQuery)
4. Sharing data between modules
26. #4 Portal and Widgets Pattern
Characteristics:
◦ Each team own Widget(s)
◦ Portal handles common features
◦ Each widget passes data via
◦ Backend
◦ Portal
28. Portal and Widget - Pros
1. Centralized control
◦ Can force all widgets to use same library/convention (if not iframe)
2. Consistent UI/UX
3. Can use SPA
4. Easier to share data between modules
◦ Portal as a message broker (pub/sub)
29. Portal and Widget - Cons
1. Widgets depends on Portal feature, except:
◦ Mocked index page
◦ Iframe
2. Complicated integration
◦ Integration test on module level requires Portal
3. Requires careful control of libraries & modules’ versions
31. Bottom Lines
In practice, the multiple patterns are usually applied
◦ ex. Facebook
Design is a trade-off. I hope this will help you in your future project !!