Designing a ui for microservices
Download as PPTX, PDF0 likes201 views
The document discusses the design and architecture considerations for creating user interfaces for microservices, emphasizing the importance of service ownership, separation of concerns, and various caching strategies. It highlights a composition approach, where different services contribute to the overall view model, thereby enhancing flexibility and performance. The author, Mauro Servienti, shares insights on managing data flow, client-side interactions, and potential pitfalls in API design.
Designing a ui for microservices
- 1. @mauroservienti | #apiconf2018 Designing a UI for Microservices Mauro Servienti | @mauroservienti
- 2. @mauroservienti | #apiconf2018 100% remote
- 3. @mauroservienti | #apiconf2018 bike rider
- 4. @mauroservienti | #apiconf2018 bananas my favorite snack
- 5. @mauroservienti | #apiconf2018 What could possibly go wrong…
- 6. @mauroservienti | #apiconf2018 Let me buy a “banana holder”
- 7. @mauroservienti | #apiconf2018 Mauro Servienti Solution Architect @ Particular Software mauro.servienti@gmail.com @mauroservienti //milestone.topics.it
- 8. @mauroservienti | #apiconf2018 Does a page like that exist? Or put it in another way: does a “Product” class or aggregate exist?
- 9. @mauroservienti | #apiconf2018 “There is no spoon” Sales Warehouse Shipping Marketing
- 10. @mauroservienti | #apiconf2018 Domain Model Decomposition services owning their own piece of information. Single Responsibility Principle
- 11. @mauroservienti | #apiconf2018 How can we design something like that?
- 12. @mauroservienti | #apiconf2018 Denormalization Temptations… Marketing Sales Shipping Warehouse De-normalized API Client “Product”ViewModel… /products/1
- 13. @mauroservienti | #apiconf2018 <rant /> That’s a cache!
- 14. @mauroservienti | #apiconf2018 Oh…and by the way…
- 15. @mauroservienti | #apiconf2018 Whatchoo talkin' 'bout, Willis? a report not a cache
- 16. @mauroservienti | #apiconf2018 A report • We're crossing a “boundary” • Data flow out of each service to the user • Users are already pulling things on demand • let's benefit of that
- 17. @mauroservienti | #apiconf2018 ViewModel Composition Marketing Sales Shipping Warehouse Client /products/1 PK PK PK PK ViewModel…
- 18. @mauroservienti | #apiconf2018 Full vertical ownership Marketing Sales Shipping Warehouse
- 19. @mauroservienti | #apiconf2018 Full vertical ownership Marketing Sales Shipping Warehouse Doc DB + HTTP DB DB back-end back-end Web Proxy API API Proxy to 3° party API 1 month cache 24 hours cache No cache10 minutes cache front-end component front-end component front-end component front-end component client shell
- 20. @mauroservienti | #apiconf2018 View Model Appender
- 21. @mauroservienti | #apiconf2018 Request matching
- 23. @mauroservienti | #apiconf2018 Full vertical ownership Marketing Sales Shipping Warehouse Doc DB + HTTP DB DB back-end back-end Web Proxy API API Proxy to 3° party API front-end component front-end component front-end component front-end component client shell composition gateway Marketing Appender Sales Appender Shipping Appender Warehouse Appender
- 24. @mauroservienti | #apiconf2018 Composition Gateway
- 25. @mauroservienti | #apiconf2018 is all that glitters gold?
- 26. @mauroservienti | #apiconf2018 What about grids?
- 27. @mauroservienti | #apiconf2018 View model/products/1 ProductNameA € 20.00 cover image A Supplier A ProductNameB € 20.00 cover image B Supplier B ProductNameC € 20.00 cover image C Supplier C ProductNameD € 20.00 cover image D Supplier D
- 28. @mauroservienti | #apiconf2018 Component from product-catalog View model Component from product-catalog /products/1 ProductNameA € 20.00 cover image A Supplier A ProductNameB € 20.00 cover image B Supplier B ProductNameC € 20.00 cover image C Supplier C ProductNameD € 20.00 cover image D Supplier D load related products
- 29. @mauroservienti | #apiconf2018 client-side message broker Component from product-catalog Component from sales Component from marketing View model Component from product-catalog Component from sales Component from marketing ProductNameA € 20.00 cover image A Supplier A ProductNameB € 20.00 cover image B Supplier B ProductNameC € 20.00 cover image C Supplier C ProductNameD € 20.00 cover image D Supplier D publish `RelatedProductsFound` load related products receive event /products/1
- 30. @mauroservienti | #apiconf2018 Component from product-catalog Component from sales Component from marketing View model Component from product-catalog Component from sales Component from marketing ProductNameA € 20.00 cover image A Supplier A ProductNameB € 20.00 cover image B Supplier B ProductNameC € 20.00 cover image C Supplier C ProductNameD € 20.00 cover image D Supplier D load related products /products/1
- 34. @mauroservienti | #apiconf2018 Recap • Clearly defined ownership • SRP is respected • Different caching strategies • Business is much more flexible • Select N+1 is not a concern • # of requests will be “# of services”
Editor's Notes
- #10: While showing ownership in overlay....Lots of components, or in SOA lingo services, each one owing different data. Otherwise it's a clear violation of responsibilities.
- #13: It's very tempting to design a technical solution
- #14: no clear ownership no easy way to (partially) invalidate it the truth from the user perspective
- #18: It's very tempting to design a technical solution
- #19: It's very tempting to design a technical solution
- #20: It's very tempting to design a technical solution
- #24: It's very tempting to design a technical solution