Ashish

So I'm having 8 years of experience in dot net technology. I have great exposure on dot net core, MVC SQL Server, and front end technologies like Angular. I worked on a couple of projects that involved dot net core, Web API, Angular, and SQL Server. The current project I'm working with uses dot net core Web API, version 2, and Angular with version 18. In the back end, they're using dot net core Web APIs and the Generate repository pattern to connect with the database. To send data to the front end, they're using services: when a request comes, it goes to a service, which calls different repositories as needed. The service evaluates all the results and sends the data through the service to a controller, and the controller sends the response to the client. I have worked on Web APIs for a long time. For around 5 to 6 years, I've been working with APIs, so I have a better idea of how to implement authentication and authorization. I know the concept of implementing JWT bearer tokens. I've also used the concept of refresh tokens, which allows you to create a new bearer token when the original one expires after a certain period, such as 1 hour. I've also worked on Web APIs that support rule-based authentications.

Yeah. For this, we can if you are using microservices, then in API gateway, we can put some strategy, like, if frequent calling is there, then we will avoid calling off frequent calls. Also, we can apply the caching technique. There are a couple of caching techniques, like we can use in-memory caching and out-of-memory caching.

Single design patterns, like, if you are using a service that you are injecting as a singleton in your IOC container, so what it will do, it will create a single instance throughout the whole life cycle of the application. And whatever object you will invoke, it will hold a single reference. All the values will be passed as a copy. Like, we cannot create different instances in our application. And suppose if your object is being used in a thread, then you have to make that object either thread-safe, otherwise, there will be a memory leak in your application. And due to that, the application may cause errors, it will collapse anytime. We have to use it accordingly.

Middlewares are the chain component. Like, it works like a chain. Whenever a request is coming to the context, the first middleware takes place to execute everything. Suppose you created one middleware to get your information from your header and validate your bearer token whether it is valid or not. To achieve this functionality, we will create one custom middleware for that. Inside that, we will use the invoke method to get our bearer token from the header, and we will evaluate it to see whether the timestamp is valid or not. Or if you are using rule-based authentication, if you are calling a specific method that should be accessible for specific kinds of rules, you can do it over there. And from the middleware, we will call the next middleware. It's a chain. Until the last middleware is executed, it will be there. We can also create custom middleware to get our exceptions. We can log our exceptions in the application also. If we want to log exceptions at the database level, we can do that from a custom exception model, where we have to inject it at the top of the configure service method to make the execution first. If the application causes any exceptions, they will go inside the custom exception model, and it will log them. Over there, we can get to know what kind of error it is, what kind of exception it is, and it will be easy to handle.

A sync method supports the concurrent or parallel execution. Whenever you use a sync async method, we have to use the await keyword. That await keyword is supposed to hold the resource until your execution is completed. And if there are any other methods or executions, they will take place, and all these processes will run concurrently, gathering all the information. Suppose you're getting data from a database, and that endpoint or any third-party API is taking much time, and there are separate codes that need to be executed. We can make our endpoint an async method and use the await keyword to achieve this functionality. The resource will wait for the response until it gets executed.

How would you manage the states in dotnetcore application in different environments. Just thinking about Suppose if your application is hosted in a different environment, then we can use the concept of caching over there. Like, we can use, Redis cache as well as we can use the concept of, SQL caching. From there, we can maintain the states into different environments as well. Yeah.

We would approach creating a high availability REST API using dotnetcore by utilizing microservices, implementing caching, and employing authentication and authorization. Our API gateway will act as a pinpoint for microservices. We can apply the caching technique to our web API to serve the most recent data instead of repeatedly fetching records from the database. The caching technique will contribute to making our REST API highly available. Additionally, we can use authentication and authorization in our web API to allow specific rules or authorized users to use it. At the hardware level, we will deploy our microservices on highly configured hardware resources to process data efficiently. A load balancer will be used to maintain availability based on the load for our web APIs.

To make our code as thread safe, we can use the locking techniques, like, we can make our object with a lock that will make our code as thread safe. Like, suppose we can suppose you are using a singleton class inside that to make it thread safe, so we will declare one property, like, we can use one object equal to a new object. And whenever we are calling it, we will use a lock key. We will check that object with the lock function whether your object is being used somewhere else or not. If it is being used, it will make it easy to make it accessible for that resources. Otherwise, it will create a new instance. Suppose this new instance is already there that is being used, so it will pass the same object to that calling methods. So this is the way that we can use thread-safe and also we can use thread-safe collections like we can use concurrent queue, concurrent stacks, concurrent bags, and there are many methods that we can use. And we can make our object immutable. And making our object immutable ensures the thread safety. And also we can use mutex. It's a synchronization primitive that can be used to manage access to resources across multiple threads even across multiple processes. And it is a more powerful but also slower than a lock as I told you.

New features added to our.NET Core application breaks existing functional data. So we're working through an approach for integrating this feature by ensuring backward compatibility. So we're using the open/closed principle via using this open for extension but closed for modification. Suppose if your class has certain features and if you are extending that class, so instead of modifying, we can extend that class. Suppose you are using it to process interest for different types of users in a banking system. Suppose you are processing interest for saving accounts, for FD accounts, for loan accounts. So in the future, there's a requirement to process different kinds of interest, like mutual funds. So instead of modifying your class, it will be easy to make that class extensible. We will create an interface and its implementing class to apply that functionality. We will create an interface to provide interest rates on different users for calculating their interest amounts. So we will create a separate interface for that, and we will implement that interface to that class so that it will be easy to calculate as per need and the requirements. We will create different concrete classes for mutual fund customers, for saving account customers, for FD customers. We will implement that interface to that class and provide the logic to calculate the interest rate on behalf of the customer type. If it's a type of mutual fund kind of customer or a saving customer, or you have the customer, it will be easy. This will be the best approach to ensure backward compatibility.

Public class ItemDeposit to private. So first, problem will arise if you are finding any items if it is null. So we have to check whether your existing item is null or not. So first, we will put a check whether we are accessing the existing item. If it is null, then we will return no item found or your exceptions. If it is not null, then we will apply the straightforward code. Like, we will apply the item into the existing item. And also, we will check whether the items have values or not. Suppose if the current items or list of items doesn't have any counts. So if it is 0, then we will return the value as it is, that no item found or whatever you want to return.

You need to optimize a critical selection of your code in molecular model. It has been identified as a performance bottleneck. To find the problems, we will apply the logger throughout the application with the time stamp, and we will thoroughly test all the endpoints or all the functions with proper unit testing. And, we will analyze first all these logs and identify the code portion. Suppose your XYZ function is taking much time as expected. So we will make a checklist of those functions or areas first. And, we will optimize them one by one. Suppose your first program's first function is calling a database. It's returning a record. And, then we will go to the database and check whether tables have indexes or not. If there is no index, we'll first apply those indexes to the table and check if the performance is increased or not. After that, if your table's having so many transactions, we will try to avoid the transaction and get the data. And also, if your next function is having a problem of low latency, and it's taking much time to evaluate all the results set. So instead of calling synchronous programming, we will try to apply asynchronous programming so that if your function or endpoint is consuming couple of parallel resources in a single sort of thought, instead of executing one by one. We can make our function or API to execute parallelly and get their results parallelly. And after evaluating everything, we will segregate the data and evaluate all results and send the data to the client. And, also, we can use caching techniques, and we can use proper dependency injections if you're standalone or where you want that function to be injected at one time, then we will use a singleton. Otherwise, we will