Hey Nick, I discovered your channel recently and binge watched everything (almost). Are you considering making more videos about Elasticsearch with .NET ? Keep it up!
Elasticsearch is a technology I use daily on a huge scale so I do wanna talk about it definitely just because of how interesting I find it. I have more topics I wanna talk about than time to make videos 😂
@@nickchapsas I can imagine that 😂Well I'm even more looking forward to see more about it 🔥Elasticsearch is easy to get started with, but hard to master and manage at scale ..
Great video on a very interesting topic. You recommended using bidirectional for shorter lived use-cases. The current thing I am developing uses a longer lived bidirectional streaming which can spend a lot of time idle, simply awaiting for messages on both sides. Is there anything I should be concerned about? If any side fails or times out (don't know what the default behavior is) that would be propagated through the cancellation token anyways, no? Then, reconnecting is trivial with some hosted/background service.
For long lived streams that can co stale you need to keep sending keep alive pings on a specific interval and make sure you have proxy specific keep alive headers so that the proxy provides doesn’t simply kill your connection.
Hi Nick, thank you for this great video. Because this is a basic example, and we don't have some complex business logic here. I wonder which type of architecture you recommend. For example, REST API usually lays on Domain Driven Design. Do you recommend the same architecture on grpc?
Why shouldn't you use string interpolation in logging statements? You said something about memory leaks. Do you have a source for it or a video about it?
It’s due to how Serilog is working behind the scenes. It’s using the message as a message template so if you use string interpretation then each log message will be kept in memory as an message template for each which will never be garbage collected. Here is a good explanation under Templates vs Messages: benfoster.io/blog/serilog-best-practices/#message-template-recommendations
@@easylite376 The notion of "Don't use string interpolation" does yeah, but I don't think you will have a leak. You will just lose the parameters name so your structured logging will be gone. You can see that message refers to the message template docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.loggerextensions.loginformation
Hey Nick! Thank you for the video. We are still waiting for your video of building the grpc client. :(
Popcorns are ready. Master Nick uploads a new video. Perfect Combo.
Awesome video as always. If people want to test Grpc on Postman, now then can do it.
Hi Nick, I can't find your video of building grpc client. Is there any? Thank you a lot!!!
Hey Nick, I discovered your channel recently and binge watched everything (almost).
Are you considering making more videos about Elasticsearch with .NET ?
Keep it up!
Elasticsearch is a technology I use daily on a huge scale so I do wanna talk about it definitely just because of how interesting I find it. I have more topics I wanna talk about than time to make videos 😂
@@nickchapsas I can imagine that 😂Well I'm even more looking forward to see more about it 🔥Elasticsearch is easy to get started with, but hard to master and manage at scale ..
Thank you Nick
Great video on a very interesting topic. You recommended using bidirectional for shorter lived use-cases. The current thing I am developing uses a longer lived bidirectional streaming which can spend a lot of time idle, simply awaiting for messages on both sides. Is there anything I should be concerned about? If any side fails or times out (don't know what the default behavior is) that would be propagated through the cancellation token anyways, no? Then, reconnecting is trivial with some hosted/background service.
For long lived streams that can co stale you need to keep sending keep alive pings on a specific interval and make sure you have proxy specific keep alive headers so that the proxy provides doesn’t simply kill your connection.
@@nickchapsas Thanks. I need to research that. But if the connection is killed I already have a reconnection logic. I don't see that as a problem.
Great topic choice!
Hi Nick, thank you for this great video. Because this is a basic example, and we don't have some complex business logic here. I wonder which type of architecture you recommend. For example, REST API usually lays on Domain Driven Design. Do you recommend the same architecture on grpc?
Why not write to the response within in the request loop?
Why shouldn't you use string interpolation in logging statements? You said something about memory leaks. Do you have a source for it or a video about it?
It’s due to how Serilog is working behind the scenes. It’s using the message as a message template so if you use string interpretation then each log message will be kept in memory as an message template for each which will never be garbage collected. Here is a good explanation under Templates vs Messages: benfoster.io/blog/serilog-best-practices/#message-template-recommendations
@@nickchapsas Ah thanks :) But this doesn't apply to all loggers like the standard .net core/.NET 5 logger also, doesn't it?
@@easylite376 The notion of "Don't use string interpolation" does yeah, but I don't think you will have a leak. You will just lose the parameters name so your structured logging will be gone. You can see that message refers to the message template docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.loggerextensions.loginformation
So.......... Where's the big client tutorial?
1:25 And I'm gonna paste those things because I'm an engineer, that's all I'm doing. 🤣