Recommended
More Related Content
What's hot
What's hot (20)
Similar to Building Microtrends With React
Similar to Building Microtrends With React (20)
Recently uploaded
Recently uploaded (20)
Building Microtrends With React
- 1. Building Microfrontends with React August 18, 2018
- 2. Nisheed Jagadish Sr Manager XT (Experience Technology) Quirks: JS’osaur, IoT/ Robotics, AR, Tech Enthusiast Who am I?
- 3. The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. Martin Flower – March 2014 Features
- 7. What is a Microservice Architecture??
- 9. 25050 lines of Fortran 25050 lines of Fortran 25050 lines of Fortran 25050 lines of Fortran 25050 lines of Fortran 25050 lines of Fortran 250 50 lines of Fortran
- 10. Building a Microservice Architecture is hard! - Most architects
- 14. CLOUD MINUTES SECONDS MILLISECONDS Amazon EC2 Containers AWS Lambda
- 16. It’s not just about Technology…
- 18. What’s happening in the Frontend World?
- 19. Single Page Apps (SPAs)
- 20. SinglePageApp STATE MANAGEMENT (REDUX) Actions Store Reducers Middleware ROUTING React Router REACT Stateful Components Stateless Functional Components Templates Styling Browser Bundles bundle.js chunk01.js vendor.js chunk02.js
- 21. Complexity as we Scale 0 20000 40000 60000 80000 100000 120000 10 20 30 40 50 60 LinesofCode No of Modules
- 22. Monoliths on top of Microservices Microservices API Gateway Single Page Apps (SPA)
- 24. Customers expect a Single Page Experience
- 25. Microfrontends: Bringing the Goodness of Microservices to the Experience Layer
- 26. CLOUD Assembler COMPONENTREGISTRY Team A Team C TemplateFolder Team B Routing Zuul
- 29. • Mono repo with multiple sub components • Each with own package.json and meta data • Each bundle built and deployed individually through configuration webpack or rollup • Builds are more complex and need to hook into webpack api • Multi repo each with own component • Built separately using webpack or rollup • More distributed • Easier to do builds
- 30. What about Bundle Size?
- 31. • UMD bundles • Vendor to have all library references • Externalize everything within components • Introduce dynamic imports in components using react-loadable or plain on ES6. • Tree shaking using named imports • A little bit of redundancy is OK
- 33. • Decouple routing • Components to act as micro SPA’s each having their own interpretation of the current route. • App shell model – PWA • Server based routing with edge caching and SW’s.
- 34. What about State Management?
- 41. 41 1. Form functional teams 2. Start deploying independently 3. Keep working on reducing complexity TAKEAWAYS
- 42. THANK YOU
Editor's Notes
- ---Teleprompter notes---- ---Narration --- One of the most important features and often the first one to miss is the ability to independently deploy your service or feature to production. Netflix is known to have just 1 developer working on a microservice who have root access to the server and build and deploy their service to production atleast once a day.
- ---Teleprompter notes---- - Speed and agility of deploying websites - ---Narration --- I started off working with a small team of web developers building static and dynamic sites using classic Wordprss and PHP, I totally loved the agility with which I could work we these languages, Make your changes in the file.. save it… drag and drop it on FileZilla and boom my code is in production. and if I now think back about it, in those days every web developer was a full stack developer. We wrote our own markup, our JavaScript & CSS and also our MySQL queries.
- ---Teleprompter notes---- larger complex projects more people agility to deploy reduced pushing to production felt like a big fat Indian wedding ---Narration --- Any software dev looks 10s or 100s or people. As technologies became more and more sophisticated, and projects grew in scale and complexity Going to production is starting to feel like a big fat Indian wedding. Planning and preparations start months in advance. Critical projects have a Release Manager, the equivalent of a wedding planner Few days and weeks before the wedding, everybody is worked-up, there is a lot of drama, tensions fly high unforeseen problems crop up. What’s interesting in both scenarios is inspite of all this drama, the marriage and our production launch does get done. Yes there would be a few heart burns, a lot of tired and exhausted people, and congratulatory messages going back and forth. Its not just about the initial launch, but every subsequent release feels like a mini wedding, code freeze happening weeks in advance and the usual song and dance which leads up to every release
- ---Teleprompter notes---- Microservices emerged on the scene promising speed and agility businesses jumped onto the microservice bandwagon.
- - breaking down a monolith based on domain models - loosely coupled services - Independently deployable services - fine grained services with a light weight protocol
- As it turns out there is a scientific reason behind why we are so paranoid on reducing complexity. Back in 1977 Marice Halstead came up with the notion of the Halstead Lengths. which is a unit to measure the amount of complexity a human brain can comprehend. His point of view was at any time the human brain can have a max of 7 chunks open. Most people have a chunk size of 250 which corresponds to 50 lines of Fortran code. so roughly 350 lines of Fortran is what most programmers can write at a time without introducing bugs. Very few programmers about 0.5% of the population had halstead lengths of about 65000
- ---Teleprompter notes---- ---Narration --- The reason this is because, although we start building on a microservice architecture we consuliously or sub consciously land up building a distributed monolith. In our endevour to follow software best practices like Re-usability and DRY, we land up extracting common pieces of code into shared libraries and import these into differ.rent modules. The moment we share a library between 2 or more teams we’ve sort of built a distributed monolith We’ve all heard about Amazon’s two pizza teams. A fundamental rule they followed was.. no teams can share their libraries or code with each other.. the only way one team can talk to another was via APIs.
- ---Teleprompter notes---- ---Narration --- In the era of monoliths and the tech stack decisions were done by people in suits sitting in boardrooms, because the tech stack decision during those days depended on a lot of other parameters other than technologies, and that’s also why you’d have people from finance and vendor relation in those decision processes. People who who were actually going to write code on the platform were quite far from the decision process. If you think of it.. its just like an Indian arranged wedding, where the people getting married basically have very little say in their own wedding.
- PWA with Angular 5 100% Cloud Native 2.5 million read ops 80+deployments 0 downtime
- Getting Software Development Right It‘s all about the team – this is was matters! Mature teams need to be enabled to make their own decisions.
- On the frontend we are all moving to building Single Page Apps. Because its performant, gives a much better user experience, and both of these translate into better conversations. I’ve been building and advocating SPAs since Sencha, EXtJS Backbone. and spending a lot of time trying to solve problems that arise due to the complexity of building SPAs
- ---Teleprompter notes---- ---Narration --- What I realize now, is SPAs are actually monoliths sitting on top of microservices which sort of breaks your microservice architecture. So now even if your backend microservice is ready and deployed, its not being used unless its frontend component is built and integrated into the SPA and deployed. From experience we’d all agree the frontend components undergo far more frequent changes than the backend.. and now having to build and deploy the entire SPA for a small change in say either the footer, or header component is now like a big fat wedding happening in the frontend space itself. Building monolith SPA on top of a microservices, completely nullifies the agility of the microservice architecture. From experience, the frontend undergoes far more frequent changes and the very thought of having to deploy the entire app bundle for even a small change in any one of the components, would trigger a full set of regression tests.
- Its quite ironic to see that the backend world moving from monoliths to microservices and the frontend which originally was sort of microservish is moving back into monoliths.
- I believe its important for us to start thinking about microfrontends, which brings all the core principals and benefits of the microservice architecture to the frontend. I believe a microfrontend architecture on top of a microservice architecture is the only way we will be able to ship new features out to end users in the shortest possible time.
- Apollo Link – talk a bit about it and how the state management would take place
- How it would work for these libraries