Here you are: kzbin.info/www/bejne/mqqziZScpdR4oLM There are a lot more videos arranged in different playlists so maybe you can find something useful as well. Regards.

Thanks a lot. It is great to hear that.

Hi. This video was recorded before the auth one, so I didn't link it in the description. But you can find both in the same playlist: kzbin.info/aero/PLkOmPTFOxKBrtoebJJIiPVuCFIWuTLBvr That said, I will add the link to that video in the description now.

As you could've seen in the book if you have repository classes inside the repository manager, you only need to register the RepositoryManager class as it will initialize other repositories in a lazy manner (only when you need them). But there will be cases where you want to have some repository classes out of the manager class (in big applications all the situations may arise) and in that case, you will want to register that repository with the service collection in DI.

You're welcome! Thank you for watching this one.

This really depends on where you want to apply caching. Is it your controllers or maybe the methods inside the service layer. Based on that decision, you can implement a redis cache service either inside the service layer or inside the Infrastructure/Persistence layer with the cahce service interface inside the Domain layer. Again, nothing is carved into stone here, and you have to adopt your solution to your needs.

@@CodeMaze tks alot

What link are we talking about?

3:48@@CodeMaze

Yeah, I am so sorry. Forgot to add it. I will add it soon, but you can search my videos for "send emails with attachments" and you will find it for sure.

The link is added now. Thank you for the suggestion.

Thankyou 😍

Glad it was helpful! Thank you for watching this one.

Is it possible for you to share the code as well? Didn't see any GitHub link

The source code is part of the patreon membership. With it you get an additional discounts on my courses as well. You can find the link in the description section of the video.

Glad you enjoyed it

Most welcome! Thanks for watching this one.

You are very welcome. That depends on a developer whether they want to handle it on a server or a client side. In my case, I would usually on the client side check if the token is valid before attaching it to the HttpClient. I would use some sort of client app's interceptors and if it is invalid, I would send a request to refresh a token and then attach it to the HttpClient. In my Blazor WASM course this is exactly what I do using the Interceptor class. But it can be done with the DelegatingHandler as well, as you saw in the video.

Well, you should create a normal C# logic to work with that file and then use Hangfire to trigger that job when you need it.

Hi. The source code is available for the patreon members. Also, the dto is a simple class with a few properties and the DtContext is a simple db context class. Nothing too special there related to RabbitMq.

Thanks a lot. Glad you like it.

Thank you, glad you like them.

Well, I would need a lot of diagrams for that :) I thought having the step by step code implementation would be enough to understand the process.

I've finally figured it out! The issue was that I mapped the DTO to the model first and then executed the CreateAsync method. Then, before I sent the email confirmation, I did the mapping again, which caused the user model that created the token was different.

I am glad you resolved the issue. You can always use the source code, if you are patreon member. It can help greatly.

Hi. Thanks for watching the video and your suggestion. I already have a video on Hangfire, and I will see about the other suggestions. They sound great.

No. To be honest, nothing is necessary, and you can organize your solution the way you want it. Just, I am great supporter of having the repository layer for the part of the application that communicates with the DB. And yes, I know that famous sentence: "EF Core has its own abstraction", but for me again, it is not a valid reason to use it inside the service layer or God forbed inside the controller. But of course, this is the part of some other conversation.

You are very welcome. Thank you too for watchng the video and sharing your comment.

Hi, thank you for watching it. Well, whatever fits your needs better. If it fits the implementation, I see no reason not to use it.

I am glad to hear that. Thank you for watching the video. There is also one regarding authentication with Ocelot if you want to give it a try. Feedback is always appreciated.

Hi. Thank you for watching the video. I hope the whole list will be helpful. Regarding your question, when you say command/query inside another command/query, I belive you mean in a handler. For me, it is the same as when you call another service from your current service. So, I can't say whether it is good or bad practice, but you will probably have to do it sometimes.

@@CodeMaze Thank you for the response ✌️Yes I meant that👍

Thanks for watching the video. I'm glad you liked it.

Great to hear that! Yeah, it is a great library and easy to use.

Hi Totti. 1) You are not tied only to ASP.NET Core apps. If you check their documentation, you will see they are using a regular, I would say, console app example. 2) Yes. Of course, if you think about recurring jobs. Again, I just looked at their documentation and there is an example here, it is pretty simple. 3) I believe you think if the job is scheduled for example every 5 minutes but for some reason, it takes more than 5 min to finish. Maybe there is a way, but I am not sure. Again, I think the best way would be to check their documentation about this. I looked for a bit but didn't find anything about it.

You are very welcome. Glad to hear that.

Hi. I think this one will explain the differences better: code-maze.com/dotnet-differences-between-onion-architecture-and-clean-architecture/

I would really like to hear why. I completely understand, we all had some sort of similar experience with different patterns, but for me, this one is pretty straight forward and maybe easiest to implement, so it is a bit strange to hear something like that.

Hi. You are very welcome, and thank you for watching the video. You can always add new claims inside JWT and extract those values inside the client app. Or, you can simply return the needed information as part of the response DTO with the Token itself. Just be careful which data you share between the server and the client apps.

Hi, thank you. From one of the online articles: IHostedService conveniently handles short-running tasks using the StartAsync and StopAsync methods. It functions well for tasks like listening to queue messages and invalidating or clearing caches. BackgroundService, on the other hand, runs long-running IHostedService tasks with a single method - ExecuteAsync. So, I think this pretty much explains the difference, but if you want to dive even dipper into the topic, there are a few articles/videos that can help you investigate even further.

Thank you. It will be in my plans for sure.

Hi. The source code is part of the patreon support package with some additional benefits for our products (best price).

Hi. I am sorry, but I will have to reply on English as I had to use translator tool to understand your message. Anyway, there are a few more videos from this searies if you didn't watch them - they are all in the same playlist. I will do my best to record a few more design patterns videos because I think those are pretty useful for developers.

You're so welcome! Thank you for watching the video.

Hi. Well, that's the real service name that Event Viewer sees. For example, you can use the sc.exe command to create this service (from the video) but using a different name in the command window. That new name will be displayed as a service name in the Service Manager window. But, once you start or stop that service, you will see the name from the configuration in the Event Viewer because that's the real service name. That's why it is the best to create the service with sc.exe command using the same name you configured in the service configuration.

Hi. Yes there is a way. Please check the: "Modifying Lifespan of the Email Token" section of my article: code-maze.com/email-confirmation-aspnet-core-identity/

@@CodeMaze Thanks man you are the best!! x)

You are welcome! Glad you like it.

Thanks a lot.

Thanks a lot. Glad you like it.

You are very welcome.

Thank you. This is a good suggestion and I will do my best to create such a video.

It is the part of the Email Service project. Just properties like (To, Subject, Content...) and some other stuff. Nothing too related to the confirm/verify implementation.

Hi. No, I am not encrypting a refresh token. I am using that mentioned class to generate one. Refresh token isn't the same as the access token, so you don't need another JWT. You don't need claims and other stuff JWT has inside.

@@CodeMaze So i want to publish a api and every api developer is doing like this way.So you say it is secure to publish it like that we don't need to encrypt the refresh token

You can do it this way. If you have a client app that consumes your API and stores the tokens in local or session storage, you can encrypt the access token inside the client app first, and then store it in the storage. Of course, everytime you send that token with a request, you need to decript it first.

@@CodeMaze Thank you !!😇