I have decided to describe here a solution that I managed to implement in regards to enriching the request data in gRPC in .NET.
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.
After some digging in relation to a new project, I’ve managed to setup the following infrastructure:
Passionate about technology and architecture. #dotnet #react #typescript #grpc #microservices