Girish Naik

I faced a few challenges while publishing my application(Front end on Angular 13, Backend is .NET CORE 6) to IIS on AWS EC2 instance using Custom Identity. So I thought of sharing this post which will help you to fix the issue quickly. It is a straight forward process to publish an application to IIS without using custom identity and many are already aware of this process. When we create an Application Pool by default it uses Application Pool Identity. In many cases we can not use Application Pool Identity. For example if your application is accessing web share or network share then your application needs to have required permission to access these shares. In this case you will have to create a Service Account and provide necessary permission to your Service Account to access these shares. Then you need to use this Service Account as Identity instead of Application Pool Identity to set up your application. However if you want to use another identity then we have to make sure your new i

Handle errors in ASP.NET Core web APIs Exception handling is one of the critical areas in modern web application development. If exceptions are not handled properly, the whole app can be terminated, causing severe issues for users and developers. Try-catch blocks are widely used in apps to handle exceptions. They are the most basic way of handling exceptions. ​ The above example is a typical case where we use try-catch block to handle the exception. The try-catch block method is ideal for novice developers, and it is something that every developer should be aware of. However, this technique has a disadvantage when working with massive projects with complex architectures. In such cases we have to use Exception Handling Middleware to handle the exceptions. Exception handler In Program.cs, call UseExceptionHandler to add the Exception Handling Middleware: ​ Configure a controller action to respond to the /error route: ​ Add [ApiExplorerSettings] attribute and set its IgnoreApi property t

Before moving into Micro frontend lets understand the evolution of software architecture. Software usually contains 3 layers. frontend, backend and storage (DB). Front end will be in the form of a user interface, And the backend will normally have your main business logic. Storage is where the data is stored.   Earlier we used to have a monolithic application where your front and backend used to be bundled in one application. They used to reside in a single code repository. This entire application used to be maintained by 1 large team. For changing anything in the application you need to test the entire application because even a small change can break any part of the application that is unrelated to the change. Industry soon realized the need to split the front end and back-end part of the code. This enabled a specialized team for frontend and backend.  Later backend services started using Microservices to decouple the code and improve scaling. Microservices architecture resolved m

AngularJS $watch() , $digest() and $apply() When you create a data binding in your view to a variable on the $scope object, AngularJS creates a "watch" internally. A watch means that AngularJS watches changes in the variable on the $scope object. These watches are created using the $scope.$watch() function. When you register a watch you pass two functions as parameters to the $watch() function: * A value function * A listener function Example : $scope.$watch(function() {}, function() {} ); The value function should return the value which is being watched. AngularJS can then check the value returned(current value) against the last calculated value. That way AngularJS can determine if the value has changed. If yes, then the corresponding listener function executes. Example 1: $scope.$watch(function(scope) { return scope.data.myVar }, function() {} ); Example 2: $scope.$watch(function(scope) { return scope.da