Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Frontend architecture design for large(r) team final

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
Mvvm knockout vs angular
Mvvm knockout vs angular
Wird geladen in …3
×

Hier ansehen

1 von 31 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Frontend architecture design for large(r) team final (20)

Anzeige

Aktuellste (20)

Frontend architecture design for large(r) team final

  1. 1. Frontend Architecture Design for Large(r) team CHADCHAPOL VITTAVUTKARNVEJ (JEMMY)
  2. 2. Questions & Discussions Due to the time limit, let’s talk after the session
  3. 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. 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. 5. #1 Server-generated frontend Characteristics: ◦ Server generated JavaScript/HTML content ◦ Cannot build/run separately
  6. 6. Generated HTML Content
  7. 7. Generated JavaScript
  8. 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. 9. Pros? Yes, there are!!
  10. 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. 11. In practice…
  12. 12. Static Content server In action… Browser Backend CDN Index. html JS CSS Browser BackendProxy Index. html JS CSS
  13. 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. 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. 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. 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. 17. What are the challenges when you have a large team doing CI?
  18. 18. CI with many developer ~3 people commit in the same integration window ◦ The build fails… ◦ Who broke the integation?
  19. 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. 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. 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. 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. 23. #3 MicroPage Pattern Characteristics: ◦ Not SPA ◦ Each team own page(s) ◦ Each page passes data via ◦ Backend ◦ Cookies ◦ Get/Post params
  24. 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. 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. 26. #4 Portal and Widgets Pattern Characteristics: ◦ Each team own Widget(s) ◦ Portal handles common features ◦ Each widget passes data via ◦ Backend ◦ Portal
  27. 27. Visualize
  28. 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. 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. 30. Recap
  31. 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 !!

×