I have decided to describe here a solution that I managed to implement in regards to enriching the request data in gRPC in .NET.

What this means?

Imagine the following case. We have a gRPC service that accepts client-id as a metadata, so we will know which of our clients requested that resource and we can execute a certain logic based on that information. Normally, you would do that by getting the client-id as part of your function and request it from the database. So far, so good. What happens however, if you need that in multiple places?

In .NET we have middleware…

Up until a few months, I didn’t want to even hear about Mac. This has changed with the revolution that M1 did. So, I’ve decided to jump ahead and get a MacBook Pro with 16GB RAM. So far I do not regret my choice. It’s super fast and pleasant to work with.

I did not have any issues with running development apps so far (mainly .NET/Node JS/Frontend), until I had to work with a gRPC service inside of docker.. I will try to describe my journey and what worked for me at the end. …

This story is about going from localhost:8080 to app.local/.


Perhaps you, like me, were having some issues to remember which app is on which port, remembering not to run app on a specific port as it’s already taken or just because you are annoyed by the auto-complete in the browser, based on history. For App A, the URL structure will be different than App B, which is annoying.

End Result

After some digging in relation to a new project, I’ve managed to setup the following infrastructure:

Daniel Stoyanoff

Passionate about technology and architecture. #dotnet #react #typescript #grpc #microservices

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store