Slides for Frontend meetup Amsterdam presentation

1. Frontend Architecture
Design for Large(r) team
CHADCHAPOL VITTAVUTKARNVEJ (JEMMY)

2. Questions & Discussions
Due to the time limit, let’s talk after the session

3. Self Introduction
Chadchapol Vittavutkarnvej (Jemmy)
◦ Siberian Husky fan
◦ Software engineer
◦ Occasional technical speaker & writer
Contact
◦ https://www.linkedin.com/in/chadchapol/
◦ https://twitter.com/ijemmy

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

5. #1 Server-generated frontend
Characteristics:
◦ Server generated JavaScript/HTML content
◦ Cannot build/run separately

6. Generated HTML Content

7. Generated JavaScript

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”

9. Pros?
Yes, there are!!

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

11. In practice…

12. Static
Content
server
In action…
Browser Backend
CDN
Index.
html
JS
CSS
Browser BackendProxy
Index.
html
JS
CSS

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?

23. #3 MicroPage Pattern
Characteristics:
◦ Not SPA
◦ Each team own page(s)
◦ Each page passes data via
◦ Backend
◦ Cookies
◦ Get/Post params

24. MicroPages - Pros
1. Full autonomy
◦ Technology
◦ Module1 uses React, Module2 uses Angular2, Module3 uses jQuery + Bootstrap
◦ Building/Testing
2. Less communication b/w page = Loose coupling
3. Simple module integration
4. Microservice soulmate

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

27. Visualize

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

30. Recap

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