You have two basic options.
- Create a 'wrapper' service for the UI that makes aggregated calls to each service it needs from and puts the data in the form the UI needs it.
- Create a service that always has the most up-to date information already stored in its own datastore for each resource you are interested in.
I have done #1 and it does not scale very well. Especially if you have to paginate data and have complicated search queries that needs to filter data that are stored in different micro services. If you strongly anticipate you may need such capabilities, I would not go down this rabbit hole.
We are starting to work more and more with #2 now. Based on my research there are lots of shops that follow this 'pattern'. It is called even driven data management. What this means is that each micro service may broadcast asynchronous events when their data changes and anyone can subscribe to these events and react by updating their datastore appropriately. In your case you may have a simple data store to house all the information necessary to serve the UI and ensure that you catch these events correctly and update the data.
This is one of the very serious drawbacks of using a micro service architecture. Data management is a lot harder due to bounded context. You go down the path of aggregating calls until you realize it won't suffice then you may have to start doing event driven data management that is just a lot of extra work to 'denormalize' your data into a single datastore for quick querying.