This document discusses different approaches to designing a user interface for a microservices architecture. It begins by proposing a domain model decomposition with individual services owning pieces of product data. However, this poses issues for users who need an aggregated view. An alternative presented is to have individual services cache normalized data and compose a view model at the edge. Later approaches incorporate client-side messaging, hosting the composition engine in MVC, and using view components to give services more ownership over vertical slices of the UI. The key takeaways are that the UI structure can be defined at the edge while still keeping domain responsibilities clear across services.

1. @mauroservienti
Designing a UI for
Microservices​​​​​
Mauro Servienti

2. @mauroservienti
All I want to do when I wake up in the
morning is...
(cit. Rosanna, Toto, Toto IV)

3. @mauroservienti
Buy a "Banana holder"

4. @mauroservienti
Does a page like that exist?
Or put it in another way, does a “Product” class or aggregate exist?

5. @mauroservienti
No, it doesn’t
Sales
Warehouse
Shipping
Publishing
Marketing

6. @mauroservienti
Domain Model Decomposition
(micro)services
owning their own
piece of information.
Single Responsibility Principle

7. @mauroservienti
Mauro Servienti
Solution Architect @ Particular Software
mauro.servienti @ particular.net
//milestone.topics.it
@mauroservienti

8. @mauroservienti
Hold on...
What about the poor user?
Solution mode is evil!

9. @mauroservienti
Denormalization
Marketing Sales Shipping Warehouse Publishing
De-normalized API
Client
“Product”

10. @mauroservienti
What's the deal?
• It's a cache
•with no clear ownership
•with infrastructure maintenance cost
•with no easy way to (partially) invalidate it
• It’s the truth from the user perspective
•When scaled out instances need to be kept in sync

11. @mauroservienti
How to fulfill it?
• Pushing is not a solution
•At read time data are always in an unknown state
• Pulling is not a solution either
•Batch jobs, that can fail
•Unknown state is still an issue at read time
•Multiple owners competing on a single resource

12. @mauroservienti
Oh…and by the way…

13. @mauroservienti
Oh…and by the way…

14. @mauroservienti
What is the real problem?
Back to the drawing board

15. @mauroservienti
It's a reporting and
integration issue.
That’s a bold statement ;-)

16. @mauroservienti
Reporting and integration
•We're crossing a “boundary”
•Data flow out of each service to the user
•User is already pulling things on demand
•let's benefit of that

17. @mauroservienti
ViewModel Composition
/products/
Marketing Sales Shipping Warehouse Publishing
Client
PKPKPKPKPK
1

18. @mauroservienti
Demo
ViewModel Composition
Single item gateway demo

19. @mauroservienti
Recap
•Responsibilities and ownership are clearly
defined
•Each service can cache using different strategies
•We can easily handle:
•Optional information
•Failures
•Sample is .NET Core: other options are available

20. @mauroservienti
What about grids?

21. @mauroservienti
What about grids?

22. @mauroservienti
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

23. @mauroservienti
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

24. @mauroservienti
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

25. @mauroservienti
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

26. @mauroservienti
Demo
ViewModel Composition
Grid/list gateway demo

27. @mauroservienti
Recap
•One service owns the “ID list”
•Select N+1 is not (anymore) a concern
•# of requests will be “# of services”
•Or in worst case “# of services + 1”
•For SPA or devices we’re done :-)
•Or any remote client

28. @mauroservienti
Hurry up, take a picture ;-)
http://go.particular.net/meetcast17
Apply systems design with microservices
Get free access to lessons about services boundaries
from the Advanced Distributed Systems Design course
by Udi Dahan

29. @mauroservienti
Please welcome Branding

30. @mauroservienti
Branding
•Defines the reporting/UI contract
•It's the technical authority owing the UI contract
•Services that want to display data must adhere

31. @mauroservienti
Demo
ViewModel Composition
MVC Hosting and Branding demo

32. @mauroservienti
Recap
•Composition engine MVC hosted
•UI structure is defined as a “monolith”
•Branding owns the UI structure
•the case when business drives all changes
•Interfaces can replace dynamic ViewModels

33. @mauroservienti
Branding is a tradeoff
What if we’re not an Amazon-like thing?

34. @mauroservienti
Demo
UI Composition
MVC ViewComponents demo

35. @mauroservienti
Recap
•Composition engine is still the same
•UI defines only high level structure
•Branding is less important
•The more “magic” the less Branding
•Services own the whole vertical slice

36. @mauroservienti
Thank you!
That’s all, folks.
Demos: //github.com/mauroservienti/designing-a-ui-for-microservices-demos