HARDCODE

      When designing a system, you should not limit yourself with using only one type of databases. Some business needs might require having a more flexible sort of databases like NoSQL / Document databases.  One of these databases is Elasticsearch ,   which is a topic that I have talked about in a previous post that you should definitely check out. However, if you use more than one database for your system, making sure that all your databases are in sync is crucial . How It Started 🚩 As I said in my previous post . The other sort of problems that we have faced while working on the microservices project is data inconsistency. To explain this problem I have to tell you why the system needed an Elasticsearch index. In microservices projects you usually have more than one database, one for each service/domain. The client-side needed an aggregated document of the data from all the databases. Which in microservices is called The Aggregate Root ,   and that is ...

     People always want the newest things. The more trendy something is, the more it appeals to most people. Same applies to technology. Adding the word microservices to the CV can help it shine a little bit. These are some of the thoughts I was having while I was 2 hours deep into debugging an issue in a project that involved .Net, Kafka, SignalR, React js, Elasticsearch, ECS, MediatR and more. Beware of Microservices  ⚠️ What I'm about to share is a cautionary tale for people who are on the verge of shifting their solution into a microservices architecture. Before you start implementing such an architecture, please read carefully the decisions that others have made along with their consequences so that you can see for yourself the outcome of each design decision instead of falling for the same mistakes. Before anything : The case study that I’m about to discuss might have had its problems. However, the people who made the design decisions are very good software e...

  Exceptions are a big part of any software solution. They happen sometimes because something went wrong like out of memory exceptions and sometimes, they happen because of the domain or the business such as validation exceptions. Either way it is something that must be planned ahead in any system design. And by planning I definitely don't mean sprinkling try/catch blocks all over your code. In this post I will explain three different techniques that will help you to globally handle exceptions and turn the messy response that exceptions return by default to a much organized and concise response. However, note that this does not mean that you should not stop using try/catch blocks if you need them for specific exception handling for specific cases. Our main focus is to manage to run some sort of logic that runs each time an exception occurs so that it prevents the default behavior and instead logs the full exception stack trace and only returns concise readable information for t...

Hosting images on an IIS server seems to be pretty much a basic task.  I mean all you need is to create a virtual directory or even a website and just move the pictures to the physical path of this website and then you can access it through: server-hostname.com/virtual-directory/picture-name.jpg Well while this might be something that you can apply easily, following the same steps but instead of creating a new website you go for adding a virtual directory under an existing frontend website might yield the world famous 404 error . The Problem I was working on a project once where I needed to create an API that takes an image url as a parameter and downloads it on the same server where the UI of the application was hosted.  I will show you how to create such an API in an upcoming post but right now let's focus on creating a virtual path under your frontend website. After you open your IIS manager right click your frontend website click on Add Virtual Directory and select the phy...