Services are just services, and you use them expose data to one or many applications. Which have access to the services typically by using authentication of some sort. You do not want to have views tied into the micro service. Because then you're just making an MVC type app and calling it a micro service, which is ok but not a micro service.
Think of services as having one main purpose to send and receive data, like a User service. Your front-end will call that service to get data about a user, update a user, create a user, etc. Each service is different, and one view can access many services.
See links for more details:
So you'll want to make your front-end with the framework/stach of choice, like Blazor/MVC 5/Vue/Angular/React/etc and have that front-end code call the services you're making via HTTP requests.
edit based on comments:
In the same vein you'll also want to make sure that your front-end application(s) follow a similar approach. You want to avoid a massive monolithic front-end by building an array of smaller and to-the-point applications.
For example, you could have a giant application that handles: meetings, calendars, appointments, trip planning, users, and customers. OR, you could take the micro service approach and build each feature out into its own independently deploy-able application. So you will have meetings app, a calendar app, a users app, etc. Each application is it's own entity but uses the services you have, so you get separation for loose coupling allowing for scalability, and the other pros that come along with micro service architecture, in your front-end.
see here for more details on a micro front-end.
