“Micro Frontends”- You Keep Using That Word, I Don’t Think It Means What You Think It Means
•Télécharger en tant que PPTX, PDF•
1 j'aime•366 vues
"Micro Frontends" is the new buzzword in the Frontend world, but too many times people use it in the wrong context or with different things in mind. Micro Frontends can refer to different kinds of solutions that solve different types of problems - starting from using different UI frameworks on the same app or letting different teams work on separate parts of the code independently. In this session, we'll go over the different problems we have when building a big app and how different micro-frontends solutions can help with this.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (13)
Similaire à “Micro Frontends”- You Keep Using That Word, I Don’t Think It Means What You Think It Means
Similaire à “Micro Frontends”- You Keep Using That Word, I Don’t Think It Means What You Think It Means (20)
Plus de Shem Magnezi
Plus de Shem Magnezi (14)
Dernier
Dernier (20)
“Micro Frontends”- You Keep Using That Word, I Don’t Think It Means What You Think It Means
- 1. Micro Frontends You Keep Using That Word, I Don’t Think It Means What You Think It Means. Shem Magnezi | @shemag8
- 2. @shemag8 Once upon a time in WeWork, community managers needed a managing tool
- 3. @shemag8
- 4. @shemag8
- 5. @shemag8 Things started to get bigger
- 6. @shemag8
- 7. @shemag8 2017 1 Team ~5 Eng 1 PM 2019 ~10 Teams ~50 Eng >5 PMs
- 8. @shemag8 At this point we have 2 options
- 10. @shemag8
- 12. @shemag8
- 13. @shemag8 This is a common pattern
- 14. @shemag8 Let’s frame the problem
- 17. @shemag8 #3: Limited blast radius
- 19. @shemag8 #5: Presenting an API
- 21. @shemag8 Why microservices for front- end isn’t that simple?
- 22. @shemag8 #1: User should feel it’s a single app
- 23. @shemag8 #2: Keep bundle size small
- 24. @shemag8 #3: Responsive as fast as possible
- 25. @shemag8 #4: No standard API
- 26. @shemag8 But the concept is somehow similar
- 27. @shemag8 Framework (AKA stiching layer) Module 1 Module 2 Module 3 Module 4 Core library Communication between modules Update modules Notifications User’s session Shared components
- 28. @shemag8 Your mileage may vary
- 29. @shemag8 Questions you want to ask ● Do all teams work on same framework (and version)? ● Single deploy or independent deploy for each module? ● Modules should be shared between apps? ● Modules should be loaded dynamically? ● Do we need to support SSR? ● ...
- 30. @shemag8
- 31. @shemag8 Here we go: Same framework: 1. NPM Modules 2. Lerna Multiple frameworks: 3. Web Components 4. App per route 5. IFrames 6. Single SPA
- 32. @shemag8 NPM module1 NPM module2 App NPM Modules ● Develop each module in its own separate independent repo ● The main app is just wiring NPM modules packaged together
- 33. @shemag8 Package 1 Package 2 Main Package Lerna ● Managing versioning ● Managing dependencies ● Used by Babel, React, Angular, Jest
- 34. @shemag8 <Module 1> ● Technology Agnostic ● The DOM is the API ● Native support by most browsers ● No shared state <Module 2> Plain old HTML (and JS) Web Components
- 35. @shemag8 /package1 ● Support SSR ● Each package has its own dedicated page ● Can be divided into fragments and not full pages /package2 API Proxy App per route
- 36. @shemag8 Frame 1 ● No heavy lifting or dependency complexity ● Complete separation ● Very nostalgic ● Used by Spotify Frame 2 Main app IFrames
- 37. @shemag8 App 1 ● Use multiple frameworks on the same page ● No refresh ● Lazy load App 2 single-spa-config Single SPA
- 40. @shemag8 Option #2: Event based communication dispatchEvent EventEmitter
- 41. @shemag8
- 42. @shemag8
- 43. @shemag8 What's in it for me?
- 44. @shemag8 Breaking the monolith is inevitable
- 45. @shemag8 You have to plan ahead to scale fast
- 46. @shemag8 There isn't one solution
- 47. @shemag8 It’s all about your team and product
- 48. @shemag8
- 49. @shemag8 Thanks You can find me at blog.shem.dev
- 50. @shemag8 Resources ● Lerna- http://bit.ly/2VAelIc ● Web Components- http://bit.ly/2PyN5V1 ● Single SPA- http://bit.ly/2DB1f3a ● Project Mosaic- http://bit.ly/2ZEdzcu ● IFrames- http://bit.ly/2vse4IE ● Exploring micro-frontends- http://bit.ly/2ZIc8cX ● Micro Frontends - Think Smaller, Avoid the Monolith Love the Backend- http://bit.ly/2DzB39e
Notes de l'éditeur
- PxWe
- One possible solution- Fast forward months/ years: everyone frustrated, starting from scratch is inevitable.
- You start with a small app, it’s all nice The product is getting bigger and the single team working on the project is starting to form some structure and patterns The project gets even bigger, the single team that was responsible can’t keep up with the pace of change Code getting bigger exponentially, complexity is too big to manage, code is duplicated all around the place and developers velocity and happiness is low
- One of the engineers come up with an amazing idea (usually someone with a server side background): micro-services for front-end! =0
- The code is running on the client side, so all the frameworks overhead counts. The user should feel this is a single app The heavy lifting that you do on the server side can’t happen in the client side. Bundle size is an issue, so you want to “reuse” libraries between services, while keeping those isolated There’s no standard API to communicate between apps in the client side.
- There are actually a few, but each aims to solve different problems. Thus- before we pick one we need to understand what we want to solve and what are the prerequisites
- Do we know that all teams will use the same framework (and same version)? Do we want single deploy for all the app or independent deploy for each module? Do we want to be framework agnostic? Do we want to have modules that can be shared between different apps? Do we want to turn on and off modules? Should it be dynamic? Do we need to support SSR? Automatic tools (flow, CI, testing infra, redux patterns, utils, global apis) VS. Freedom (teams moving at their own speed, choosing their libraries, choosing their stacks, etc)