Download to read offline
Uploaded byMauro Servienti
Designing a ui for microservices
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.
More Related Content
Similar to Designing a ui for microservices
More from Mauro Servienti
Designing a ui for microservices
- 1. @mauroservienti | #apiconf2018 Designinga UI for Microservices Mauro Servienti | @mauroservienti
- 2.
- 3.
- 4. @mauroservienti | #apiconf2018 bananas myfavorite snack
- 5. @mauroservienti | #apiconf2018 Whatcould possibly go wrong…
- 6. @mauroservienti | #apiconf2018 Letme buy a “banana holder”
- 7. @mauroservienti | #apiconf2018 MauroServienti Solution Architect @ Particular Software [email protected] @mauroservienti //milestone.topics.it
- 8. @mauroservienti | #apiconf2018 Doesa page like that exist? Or put it in another way: does a “Product” class or aggregate exist?
- 9. @mauroservienti | #apiconf2018 “Thereis no spoon” Sales Warehouse Shipping Marketing
- 10. @mauroservienti | #apiconf2018 DomainModel Decomposition services owning their own piece of information. Single Responsibility Principle
- 11. @mauroservienti | #apiconf2018 Howcan we design something like that?
- 12. @mauroservienti | #apiconf2018 DenormalizationTemptations… Marketing Sales Shipping Warehouse De-normalized API Client “Product”ViewModel… /products/1
- 13. @mauroservienti | #apiconf2018 <rant/> That’s a cache!
- 14. @mauroservienti | #apiconf2018 Oh…andby the way…
- 15. @mauroservienti | #apiconf2018 Whatchootalkin' 'bout, Willis? a report not a cache
- 16. @mauroservienti | #apiconf2018 Areport • 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 ViewModelComposition Marketing Sales Shipping Warehouse Client /products/1 PK PK PK PK ViewModel…
- 18. @mauroservienti | #apiconf2018 Fullvertical ownership Marketing Sales Shipping Warehouse
- 19. @mauroservienti | #apiconf2018 Fullvertical 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 ViewModel Appender
- 21.
- 22.
- 23. @mauroservienti | #apiconf2018 Fullvertical 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.
- 25. @mauroservienti | #apiconf2018 isall that glitters gold?
- 26. @mauroservienti | #apiconf2018 Whatabout 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 Componentfrom 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-sidemessage 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 Componentfrom 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
- 31.
- 32.
- 33.
- 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”
- 35.
- 36.
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