Manju

Greetings! In a previous article , I talked about redux architecture with reactjs a bit. In this article, I talk about handling side effects with redux-saga. The complete code for this article is here . What is redux-saga? Redux saga is a side effect manager using ES6 generators. Therefore it gives the added benefit of easy testability. What do we build? To demonstrate the architecture, let's create a simple GitHub user application where we fetch GitHub handle for a given username. For example, this gives my GitHub account information. https://api.github.com/users/slmanju Initialize the project create-react-app react-redux-saga-example cd react-redux-saga-example npm install redux react-redux reselect npm install redux-saga npm install axios Util to fetch actual data Let's create a little util for HTTP calls using axios. import axios from "axios"; const withError = (promise) => promise.then((data) => [null, data]).catch((err) => [err]); export const

Greetings! Redux is described as a predictable state container for JS Apps (in the docs) and a few more features. What we need to realize is that it gives a single source of truth for our JavaScript applications. Instead of saving our global states in multiple places, we manage them in a centralized location. That is it! Let's jump. Single source of truth Share data across multiple places The source code for this article can be found here . The redux architecture It is this redux architecture we need to understand. After that, it is how to accomplish it in reactjs way. view - any part of the user interface action - what sort of thing the user did in the user interface? reducer - this is where the data manipulation happens. It captures the action and acts upon that, updates the store store - this is where the all data is saved just like a database These are the main players we need to know, we need to understand. Next, we will use the react-redux

Greetings REST API designing and modeling is a beautiful art one can master. I was lucky to work in such an environment where we gave a lot of effort to design better APIs by following proper guidelines. Out of all the companies I worked for, it had the best guide on REST design. I thought to share my learning and some thoughts on REST API designing decisions one can take. The product domain is healthcare hence I am referring to the FHIR standard here as it is more generic and common for anyone. I choose the FHIR appointment as the discussion point. Challenges These are some of the challenges for any project that we will face. There is a lot of logic on the client and there are other structural problems after many years of development Complex logic and difficult to grasp Multiple modules are impacted Support new requirements while preserving the running system behavior Deliver on time Need to support multiple con

Greetings! In one of my projects, I got an opportunity to design the architecture for a scheduled report processor and sender. As this is a legacy system, we used existing internal tools, and frameworks hence I'm not able to share the complete architecture but the general idea. This was one of those stressful but fun work. Existing system It can be represented as 3 tier architecture that is common for most of the applications. Design considerations As most of these kinds of architectures have similarities among them, what is important here is the thinking process as we are dealing with an existing system. No impact on the running application Independent development Asynchronous data processing Deploy separately Design I had to tweak the database a little bit but that is not important here. What is important is to expose a separate API for the data loader (ETL). ETL is triggered by a Cron job which eventually inserts into the queue for interested parties to use. Final notes This is

Greetings! When you are a passionate developer, you will always try to do better things, and experiments with new things. In this article, I will explain how we achieved a complex code cleanup by creating a mini business rule engine. Why is it? There is business logic depends on each other due to business behavior, mainly due to years of development. The business knowledge of the behavior is missing. Problem statement This legacy module has been developed a long ago and new codes are also a copy of those codes. I see numerous issues there. Business knowledge is missing (Logic is hidden everywhere) Unmanageable codes due to years of development Complex logic The main APIs (multiple) depend on this Two domains are coupled New joiners cannot understand the domain Error-prone due to fragile codes How to approach As there are higher-priority tickets in the backlog, it is difficult to prioritize this kind of work as it