What’s Behind Your App’s .NET Requests?
Вставка
- Опубліковано 28 січ 2024
- Check out my courses on Dometrain: dometrain.com
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will show you a really simple and easy way to inspect and debug your .NET HTTP requests and responses.
Give Rin a star on GitHub: github.com/mayuki/Rin
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
I imagine the lack of updates to that project being due to the fact that it is largely superseded by open telemetry. While this is a pretty cool tool (or rather would've been in pre-OTEL days), there's quite a bit of config involved in order to get it running, and to configure it for dev only. Personally, I would recommend developers to get acquainted with open telemetry instead, and use the same tooling locally that they would use in production. Setting up jaeger in docker is quite trivial. As an added benefit, all developers will get familiar with that tooling in development environment already and if the production environment needs to be examined, they will already know how to do it and what to look for.
Also want to mention. Aspire is also built on OTEL and will be the .NET team's push for people to adopt OTEL. Even the Azure Application Insights team is pushing people to use OTEL.
How is Nuget and a few lines of code harder to set up than Jaeger in Docker?
@@coolY2k
1) most current projects I would assume are either already using or migrating to open telemetry, as it's the standard du jour. Every modern tool that I've used in the last couple of years supports it and provides either a UI or query language or both on top of it. Every developer that is trying to keep their skills up to date should know about open telemetry or at the very least have this technology high on their learning priorities. Learning a tool like this on the other hand is a dead end. Also, this same developer should at least know the very basics of docker already, like pulling down an image and instantiating a new container. Otherwise, same thing applies re the learning priorities.
2) Using this adds an external (unmaintained) dependency that is only going to be used during development, hence great care needs to be taken that none of it is enabled on production by accident (and will not get enabled by accident by another developer modifying the config or pipeline later). You are actually adding code to your application, which has maintenance cost associated with it, whereas you will have had most likely enabled OTEL already anyway.
3) Any external dependency, and especially an unmaintained one is an additional risk of providing potential attack vectors, and is a potential source of compatibility issues when migrating to newer versions of dotnet
4) using this tool when developing locally you are doing yourself a disservice, as you won't have this tool running on QA or production. What are you going to do when there is a problem in any of those environments? Where are you going to look, and what are you going to be looking for? Will you even have sufficient detail for diagnostics in those environments? The biggest advantage to using OTEL locally is that even during development, you will see what is being logged and in what detail, and what other information you need for diagnostics (and will most likely add custom spans around layers in your code where helpful).
TLDR: there is a lot more to it than just "adding a nuget" and just "adding a few lines of code", whereas you should have OTEL set up already. If you don't, do, you will get quite a lot of value out of it.
(edited for formatting)
@@pali1980my main reasoning is that I don't want to make the dev environment more complex or slower than it needs to be. I never think just adding additional docker is "quite trivial". I am not pro Rin, I am anti complex dev enviroments, and I think you are doing just that.
@@coolY2k fair enough, though I think (and according to my experience) that most recent projects use docker in some capacity already anyway, in lieu of locally installed dependencies. I think that changing actual code with an additional dependency for development only is more complex than adding one more container to the mix, but I guess we'll have to agree to disagree 🙂
Love it! Looked for something for my workers that fire requests all the time. Cloudwatch and CAP bring some sort of visibility, but not quite that when doing the development part.
Thank you, This remembered me the miniprofiler by stackoverflow, would be great to have sore of side by side comparison.
Looks very interessting, thanks a lot.
Do you know something similar but for WebSocket messages / SignalR?
It looks very interesting! Is all this information stored in memory? I’ll check the documentation to learn more about it. Thanks for sharing
That's very cool!
great video 🙏. Can you consider giving a tutorial on how to implement authentication and authorization the right way using something like Entra External Id as an api and how to get the access token programmatically using login endpoint in the api?
I used to use something similar, don't recall what it was called. But, it added the information to the bottom of your web pages, showed you all kinds of debugging information. How long request too, how long db requests too, etc. If only I could remember the name. :)
What about miniprofiler? Its the equivalent project which i used before
This is awesome! Such a great tool
This looks like glimpse, although it worked for a lot more things i think, but lost support when the two people working on it got snatched by MS :) (if i remember correct)
Is this Open Wheather api project in your Github? Wish try to clone but couldn't find it.
Nick I want you to create a video with a library showing workflows that also offer compensation functionality
Do you mean by workflows the drag and drop thing? Automation and so on?
In the old days, Glimpse had something. Not sure if they've ported anything to the .Net versions yet
It's a cool project, but I'd prefer "just" setting up OTel with a containerized grafana stack instead, at least it's reusable in production as-is
Would stick with prometheus & zipkin like tools, this kind of libraries kinda usefull but it might be hard to maintain over future, if you are not lazy and able to change then no reason to not use
Thanks, already adding to my BFF application ))
After watching this I gave this a try as I was having an issue I was trying to track down, unfortunately it doesn't capture HttpClient request/responses so it didn't help. Also concerned about the lack of updates.
Why would I need it if I have OpenTelemetry? I don't see that it shows information more than what Postman shows
Nice. Anything similar with SQL requests ?
ElmahCore can trace the whole pipeline of http request including sql queries
That looks cool. I would be very careful to not copy the dll to production though.
Copy the dll? Sorry for stupid question but when would you copy paste any dlls?
@@zhaltys I wasnt refering to manually copying a file via copy/paste. You wouldn't copy paste any files ideally, your deployment system would bundle and deploy any files.
My point is that, you wouldn't want the dll to be deployed to your live environment.
@@kelton5020 alrighty, I must have misread. But anyway why wouldn't you want it to be deployed to live, it's still the env variable in configuration that counts and Nick clearly put it under `dev` env. So even if it's live it would not be hit due to env, right?
@@zhaltys yeah this is true, but it is not the only scenario in which you could have a problem. It's not a good idea to have a bunch of dormant code in production. Any number of bugs or user errors could trigger this feature to be enabled. It increases your attack surface and increases deployment sizes.
My advice is that you should think of it like "when this accidentally gets enabled in production, how big of a problem would it be?", and act accordingly.
It would be nice if you could integrate Rin with the HttpClient and add logging of outgoing requests as well. Eg. to monitor what outgoing requests are triggered by an incoming request to my API.
Didn’t he just show that? Or did I not understand your question
"hello everybody I'm naked in this video"
There I ruined it!
Why not just use chrome (or other browser) Dev Tools?
Cool thing!
For sure Rin is usefull.
This is a nixe tool definitely, wuite easy to set up.
I still wonder wy wouldn't you already have OpentTelemetry and a container with Jaegger or similar.
There are more new courses on dometrain, right?
There are 10 more courses coming in the next 3 months or so
@@nickchapsasDo you plan anything on OpenTelemetry for .NET ?
it looks very nice, never the less, i would rather use external tool i like my dev env work same way as prod
How are the bots here alreasy
I would not recommend sharing any project that hasn't been updated in 3 years. First red flag.
It’s just for development stage, take it easy bro
Hi @Nick Chapsas, Thanks for sharing the library. I have tried to capture the request/request for an API which is internally making could of DAPR api call like state store and publishing messages. These are not logged in traces. I know these might be DAPR stuff & it's not captured by Rin trace. Do you have any suggestion around this?
`await _daprClient.SaveStateAsync(
Constants.StateStoreName,
order.UserName,
order);
await _daprClient.PublishEventAsync(
Constants.PubSubName,
Constants.OrderTopic,
order);`