Audit Trail Implementation in ASP.NET Core Web API

[@CodeMaze]

Thank you all for watching and for your support. ►► If you want to master Web API development using best practices, check out our Web API book: bit.ly/3x75ZMM ►► Also, to build great full-stack apps with Blazor, check out our course: bit.ly/3Pw3Y33

[@seldomseen_78]

Great stuff, as usual. We have a nearly identical implementation except for the part where, instead of the changes column, we save entity JSON, so if something needs to be compared, simply compare the JSON objects to see what changed. Also, you can retrieve a deleted object.

[@CodeMaze]

Thanks for the kind words. Yeah, that sounds great as well. This can serve as a base idea for everyone and then, we all can modify it per our needs.

[@10Totti]

Great tutorial, I've been using this technique for a long time.

[@CodeMaze]

Thank you. Yeah, it is a great approach, and easy to implement.

[@khaledmerzougui-ko7nu]

Good job.thanks a lot

[@CodeMaze]

Glad you liked it! Thank you for watching the video.

[@Miraziz-dotnet]

Great tutorial as always.

[@CodeMaze]

Thanks a lot. Glad you like it.

[@duongchinhngu2407]

Great tutorial! thank you!

[@CodeMaze]

You're very welcome! Thanks for watching.

[@lexNwimue]

Really great stuff, man. Thank you very much!

[@CodeMaze]

You are most welcome. Thank you for watching.

[@cissemy]

Thanks

[@CodeMaze]

You are most welcome.

[@FearGod123]

Great video. Thank you very much

[@CodeMaze]

You are welcome! Thanks for watching it.

[@pieceofcode_]

great tutorial. Can you tell me considering high performance what database we should use? PostgreSQL or ELK?

[@CodeMaze]

Thank you. Sorry, but I can't. I didn't work with PostgreSQL at all. Did some work with Elastic search but again, nothing too major.

[@pieceofcode_]

Hello@@CodeMaze thank you for your response, so my query was regarding to go with relational DB or ELK? We have huge number of logs; every action of user is getting logged in our system.

[@CodeMaze]

@@pieceofcode_ The general rule of thumb is to go with Relational when you have structured logs or if you expect to have complex joins in the future. On the other hand ELK is perfect for unstructured logs or when the log volume is huge. That said, you can pick whatever DB you're familiar with, because there are great options out there. Use case is what matters.

[@andresbeltran5779]

Good afternoon, always happy to learn new things with your videos. Based on your experience, should some migration or backup be implemented from time to time to prevent this table from becoming huge? I understand that everything is relative but to at least have an idea

[@CodeMaze]

Hi. Thank you for watching the videos, it is great if you can learn something new from those. Regarding your question, definitely. Depending on the ferquency of the logs the ferquency of backups should be decided, but again, I am pretty sure, as we all log a lot, the tables will become large pretty soon, so some sort of backup should be advised. Now it is up to the team to decide wether they want to do the entire db backup or just this table, but again, it should be done.

[@GustavoAdolfoRodríguezBeteta]

How can I use this approach with a service layer or with unit of work?

[@CodeMaze]

You don't have to worry about that. You are overriding the SaveChanges method that you have to call if you are using EF Core to make the changes to the database. You can use any architecture or any pattern you want, this still doesn't affect the logic from the video.

[@GustavoAdolfoRodríguezBeteta]

@@CodeMaze thanks

[@venky76v]

Hi, Do you have the source code on GitHub? Please, if you can share it??

[@10Totti]

Patreon.

[@CodeMaze]

Hi, no we don't have a public GitHub repo for the source code. It is part of the patreon membership with some other privileges.

[@marklnz]

So this is a bit of an "old school" way to do this. There are better options, in my opinion. The biggest issue I have with this approach is that it only supports add/update/delete actions. Most real world audit requirements involve logging read access also. Further, you're using the HTTPClient directly in the data access layer - it would definitely be a more "pure" approach to avoid that and pull the user information from the ThreadPrincipal, for example, instead.

[@CodeMaze]

Hi. First of all thanks for watching the video and for the comment. I definitely didn't invent this approach :) I've been using it for years now, so we certainly can't say it is the newest approach out there, but it works great and people will use it for sure. Regarding the second thing - yes this approach can't be used for GET requests and to be honest I never use Audit logs for GET requests only for the requests that make changes to my database, I simply use regular logs if I need any info about the GET flow in my app. I am not using HtppClient, I am just accessing the HttpContext here, and yes, you can definitely move that logic to any service and then inject that service here, I just didn't want to go into that in this video and make the video any longer. For me using the HttpContext.User property is the standard way of getting users' information so I just used it here, but I am sure everyone can adapt the solution to their needs.