DEV Community: Yogesh Galav

Repository vs Service Pattern

Yogesh Galav — Tue, 30 Dec 2025 16:32:08 +0000

Hello Developers!!

There's a long outstanding debate between Repository Pattern and Service Pattern. What should we use and where?
Take a look at below given idea, Nobody is being talking about it but ever since I implemented it in enterprise grade application, the things become easy to implement especially in Laravel.

Repository Pattern

Business logic
Database queries
Model abstraction
Keeps controllers thin
No inheritance, just direct static method calls

Service Pattern

Third-party integrations
SMS, Email, Payment gateway
External APIs
Infrastructure logic
Interface or abstract class necessary for changing service in future

Please Like and Share if you found this insightful.
Thanks and Regards!
Yogesh Galav

Please Like and Share if you found this insightful

Ideal Testing framework app

Yogesh Galav — Thu, 04 Dec 2025 07:01:51 +0000

Hello friends!!

Hope you are doing well, This post is mainly for QA guys who writes E2E testing code in playwright or puppeteer or any other framework. Before moving any further let's start with problems or motivation that occur while writing these tests.

Long running Tests.
Complicated test flows.
Duplicate Code.
No track of regression or future tests.

These all problems can be shorted with simple architecture adaptions in the code. I will explain in points.

Keep Index file or entry file which declares all tests in one place.
Keep tests in order Insertion, Updation then Deletion.
Write regressions or future tests in same file as commented code or ToDo.

Thanks and Have a Nice Day.

Why I fed up with Inertia?

Yogesh Galav — Sat, 23 Aug 2025 06:10:54 +0000

In recent times while working as Tech lead, I was very much obssesed with optimizing loading time of website and our product website literally took 10-15 secs to load.
That's a good reason of frustration right?
Our Team had done many efforts to resolve the same but all in wain.
We purchased CDN, optimized queries, defer loaded resources, but nothing decreased that FCP time. BTW each optimization has it's own benifit and other then FCP they really bring calculative changes.

But from user perspective we have done nothing for months😔

Hence it was the time to remove the culprit we always avoided, because it was love of otwell and people always defended it including me😅
You guessed it right, the culprit was inertia itself. and it's drawback which can never be cured is server call before every page load.

Suppose I'm sitting in India and server is located in USA, then here's what will happen.

First the DNS will resolve then our server code from usa will run and return html result to India.
After loading Html your browser will know, Ohh! it uses Inertia I need to again request to server if I can open this route or is there any prop I need to load before loading and executing anything else.
Then our holy grail inertia request goes to USA and fetch little props and check conditions which most of the time is not present on get routes.
After this long awaited time in which we can do nothing, Now our browser in India will start loading css,js files mentioned in html from USA or CDN.
Now the time comes when our js will execute and render the page to user.

You can understand better if you use inertia and look in network tab.

Inertia lovers will suggest solutions to problems generated by inertia itself but I will argue with them one by one.

First as I mention all the solutions are to coverup drawbacks of inertia which were never present in first place.
From Inertia 2 there are solution like load resources on hover of link or load before user's intention. It will always work if you have rich pocket, but what if server is already busy with loading resources and pages of 100 other users at the same time and with php you know the condition, right?
If you use api's only atleast you can load and execute frontend and show loaders.
If you want to save effort of writing routes 2 times, with packages like uplugin-vue, you wouldn't have to write your url even once and at the same time you can maintain folder structure for frontend with file based routing.
Last but not the least, if you need roles and permission on every route, or need some initial data as alternative to HandleInertia, You can do that via window variable.

Every technology has it's own pros and cons but I think every B2C product has heavy traffic or busy server and want to save costs, hence take your decisions accordingly. A single inertia request before page load wouldn't cost you but thousands and millions will.

I hope you enjoyed reading this,
Thanks and have a nice day.

How to manage large env files?

Yogesh Galav — Tue, 06 May 2025 08:57:43 +0000

Hello friends,

I'm Yogesh Galav and currently working as Technical Product Manager at InstaWP, Recently I came across a problem of manually managing env file for multiple environments so I tried to came up with cost effective solution to it, I hope you read it with open mind.
The topic of this blog could also be:

How I managed to decrease the size of env with 400+ keys to just 40 keys.

Like most of you at first I faced hurdle from my team mates of opposing dynamism or quick change culture, but after application was still running smoothly in develop/staging env I was able to gain their trust, hence looking forward to gain yours too.

Some of you might have heard of solution to this problem like Infisical, Vault, AWS Parameter Store, Google Secret Manager but they involves cost in some form like money or work or maintenance.
Hence I tried to came up with solution which involves one time change of one person. It was like setting up a new culture. I know setting into a new culture is hard but Software development is all about it.

Let's now move directly to the point. Pros and Cons of ENV file management

Pros:
Env file is not shared with version control like git.
Cons:
Manual management is too much risky and keys sharing is still needed.

Pros:
Env keys are kept as secret.
Cons:
Developers add keys which are not even a secret like urls.

Pros:
Env allows to make quick change like Christmas discount.
Cons:
Quick change sometime can break things in unknown way.

If you only sees pros mentioned above and not the cons then you may purchase solutions in market. No hard feelings.

But if you also understand the cons mentioned above then your brain might be searching for solution and strategy to implement it.
Here's what I did in step by step manner.

First of all you need intermediate files like const.js/const.php which will provide all the keys to your application as destination and also will have fallback value if not present in source env file. If you are using framework like laravel it already provide config files which can use env keys and fallbacks.

export const DISCOUNT = env.DISCOUNT || '5%'

Replace env values with const values imported from intermediate file. You can transfer some of the logic to that file as well. Most values in this file will be decided by app environment i.e. local, staging, production etc

import { DISCOUNT } from 'const.js'
let userDiscount = DISCOUNT

Categorize ENV keys, with help of your team you can categorize your ENV keys into Unused/depreciated, Unique values, Same value for all env, different value only for prod. I personally used slack canvas for it.
Delete Unused/depreciated ENV keys.
Delete ENV keys which holds insensitive values like urls or text. And hardcode it in intermediate file. In most of the cases this values will never change neither they are sensitive which abuse dev can make use of,
hence it's better to reduce load.

export const TERM_URL = '/term'

If you are using same values for local and prod, how is that a secret?
Hence you can hardcode that in intermediate file as well.
Last remaining items will be Unique values. Your local env will be smallest then dev or stage, Prod env will still hold much key values because they are secrets which can't be shared.

By reaching here, you and your team has removed lot of pain by reducing ENV size and changing the culture.

BTW If you depend on too much services, It might increase your cost so try to reduce those services as well.

Thanks for the read,
Yogesh Galav

Husky pre-commit for Laravel & Vuejs.

Yogesh Galav — Sun, 09 Feb 2025 14:40:55 +0000

This configuration will help you maintain ideal code quality in Laravel and Vuejs application. The best part is this configuration will help you better the code quality day by day by each developer so you don't have to do code freeze for months just to improve code quality.

1. First let's start by adding "Duster" package to Laravel

composer require tightenco/duster --dev

2. Now let's also add PHPstan and Larastan for laravel

composer require --dev phpstan/phpstan
composer require --dev "larastan/larastan:^3.0"

Now add configuration file for phpstan with name of "phpstan.neon"

includes:
    - vendor/larastan/larastan/extension.neon
    - vendor/nesbot/carbon/extension.neon

parameters:

    paths:
        - app/

    # Level 10 is the highest level
    level: 5

#    ignoreErrors:
#        - '#PHPDoc tag @var#'
#
#    excludePaths:
#        - ./*/*/FileToBeExcluded.php

3. For Frontend eslint is enough so let's add that

npm install --save-dev husky eslint eslint-plugin-vue

Add the following lines to package.json

"scripts": {
    "lint": "eslint . --fix --ignore-pattern .gitignore",
    "prepare": "husky"
},
"lint-staged": {
    "*.{vue,js}": "eslint --fix"
}

Now let's add eslint configuration for Vue in latest format
create a file on root with name "eslint.config.js"

import globals from "globals";
import pluginJs from "@eslint/js";
import pluginVue from "eslint-plugin-vue";


export default [
    { files: ["**/*.{js,mjs,cjs,vue}"] },
    { languageOptions: { globals: globals.browser } },
    pluginJs.configs.recommended,
    ...pluginVue.configs["flat/recommended"],
    {
        rules: {
            'vue/html-indent': ['error', 2, {
                attribute: 1,
                baseIndent: 1,
                closeBracket: 0,
                alignAttributesVertically: false,
            }],
            "vue/html-closing-bracket-newline": ["error", {
                "singleline": "never",
                "multiline": "always"
            }],
            // override/add rules settings here, such as:
            //   'vue/no-unused-vars': 0,
        },
    }
];

4. Finally let's configure Husky

The husky pre-commit file will only run above linting tools on staged files and will not stop commit if these command fails with errors.
If you want to fail commit if any error occurs then just remove "|| true" part.

npx husky init

# .husky/pre-commit
./vendor/bin/duster fix --dirty || true
npx lint-staged || true

# Get list of staged PHP files
STAGED_FILES=$(git diff --cached --name-only --diff-filter=AM | grep '\.php$' | tr '\n' ' ')

if [ -n "$STAGED_FILES" ]; then
  # Run PHPStan only on staged PHP files
  composer phpstan $STAGED_FILES  || true
else
  echo "No PHP files to analyze."
fi

Husky pre-commit configuration for Laravel Vuejs.

Yogesh Galav — Sun, 09 Feb 2025 14:36:58 +0000

How to optimize Vite app?

Yogesh Galav — Sat, 07 Dec 2024 06:48:43 +0000

Hello guys!!

Currently as a tech lead I got task of optimizing Vite App which was also using vue and inertia. I read many blogs but they all were either made for webpack or didn't made reasonable output,
After lot of research I had implemented some solutions which you must use.
Vite is awesome tool for bundling which already implements multiple strategies like chunking, versioning, compression for optimizing you app, so we can save some hard work.
Hence, if you are not using Vite you must look forward for new technology.
In my case the project was already big enough so the code written by different developers wasn't implementing ways to decrease load of app.

So for summary here's what I'm going to implement

Common bundle for legacy packages.
API defer.
Third party script async and defer.
Lazy load Modals and charts.
Use ES6 modules.
Vite plugins.

Let's discuss them in detail

1. Common bundle for legacy packages.

Vite already separates pages and components into different bundles which you can see in network tab but some of those bundles are still size heavy, hence take much time.
Vite also implements versioning so each time you release new version users have to download those heavy bundles again.
Also they have to download images again. All this effort can be saved with browser cache.
Only thing is you must know what to put in browser cache and what not.
For suggestion, you may choose all images to not included in versioning.
And for packages which you may choose legacy packages like moment and package you will not update in coming years.
Although it's not suggested to use legacy packages but in reality for large or legacy project it's not an easy job.
You can also identify big chunks or packages from visualizer plugin of Vite, link given below.
Here's the code you can attach in vite.config.js for having more control over versioning.

 build: {
        rollupOptions: {
            output: {
                entryFileNames: `assets/[name]-[hash].js`,
                assetFileNames: (assetInfo) => {
                    // Get the name from the array of names (usually the first/only entry)
                    const fileName = assetInfo.names?.[0] ?? '';

                    if (/\.(png|jpg|jpeg|gif|svg|webp)$/.test(fileName)) {
                        return `images/[name][extname]`;
                    }
                    return `css/[name]-[hash][extname]`;
                },
                chunkFileNames: (chunkInfo) => {
                    const is_manual_chunk = ['core', 'chart', 'quill', 'datepicker', 'moment', 'jsoneditor'].some(el => chunkInfo.name.startsWith(el));
                    if (is_manual_chunk) {
                        return `js/[name].js`;
                    }
                    return `js/[name]-[hash].js`;
                },
                manualChunks: {
                    core: ['vue', '@inertiajs/vue3', '@sentry/vue'],
                    chart: ['@j-t-mcc/vue3-chartjs', 'chart.js'],
                    quill: ['@vueup/vue-quill'],
                    datepicker: ['@vuepic/vue-datepicker'],
                    jsoneditor: ['@json-editor/json-editor'],
                    moment: ['moment', 'moment-timezone', 'moment-duration-format']
                },
            },
        },
    },

2. API defer.

This second step looks so easy but brings a great difference to app load. All you have to do load important API's first and non-important API's at last.
For the API's which you wanna load first, call them from created hook or setup initial lines in vue3 of layout file.
A bad approach would be to call it from entry-file because it blocks app mounting, but you may use it if necessary.
The API's which you wanna load in last, keep them in defineAsyncComponent in vue. For react you can use async component via composition but it's difficult so react lover please give some suggestion in comment.
The API's you wanna load in between, try to put them in mounted or useEffect hook part not created hook or directly in script part.
Try to use less API call, as it will take some time to go through DNS, then server, then firewall, then your code Middlewares and with some extra code dependencies. In my case I combined multiple API into initial-data API.

3. Third party script async and defer.

Your project may be using third party scripts in main HTML element like google analytics, chat plugin etc.
If you define this scripts in head section then they will block further scripts and load first which is not needed at all. If your user can't interact with app quickly what's the point of all other tools.
Try to use these scripts in bottom body part instead of head section.
Now we have to decide between defer and acync script for those who don't know defer will call your script after page loads and async will load script in parallel thread non-blocking you main app JS.
In my case I used async for loading third party scripts

 <script async src="https://www.googletagmanager.com/gtag/js?id=G-DNJN1PF3CS"></script>

and defer for executing those script

<script defer>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());

gtag('config', 'G-XXXXXXX');
</script>

4. Lazy load Modals and charts.

In other blogs this part may be on top but I kept it below because it may not bring significant difference in app load unless you modal is calling some API's or is using large/heavy component

Please don't lazy load modal component itself but the component that's used inside it, In most case it would be passed by slot.
You can also lazy load chart components and other benefit you may find with it is suspense component till main component is loaded.

5. Use ES6 modules.

For those who don't know there's two type of js module, CommonJs and ES6, there is fight going on between them but most probably ES6 will win, because it's newer and have benefit of tree-shaking which we want to make use of.

This step also might not bring significant difference to your app bundle size but it's good to have. For me it was 12kb.
For those old packages which are created in CommonJS does not provide tree-shaking and hence increases the bundle size.
Most common use case is lodash which is used in many projects, some developers even use it in new projects so the alternative is lodash-es.
and you must use it in correct way otherwise it wont make any difference. Even I spent hours on figuring out why it isn't working 😅.

import { flatten as l_flatten, reduce as l_reduce } from "lodash-es";

6. Vite plugins.

Vite provides various other packages to enhance your app. some of the packages I will mention here with link so you can read in detail about them, if you know others please mention them in comment

ViteCompression from "vite-plugin-compression"
VitePWA from "vite-plugin-pwa"
Visualizer from "rollup-plugin-visualizer"
pluginUnused from "@gatsbylabs/vite-plugin-unused"
AutoImport from "unplugin-vue-components/vite"
Also please try to use import.meta.env

7. Use CDN

I have written this in last as it comes at a cost but for the cost being paid it provide massive improvement in loading time of your Vite bundle assets. and all you have to do is add one simple static line of code to vite config file.

const CDN_URL = process.env.CDN_URL || '';

export default { 
  base: CDN_URL, //cdn.example.com
  [...]
}

8. Optimize Inertia, if you use it

Last but not the least tip, if you use Inertia, please don't make HandleInertiaMiddleware heavy, either store and load the data in session if necessary, else keep it lightweight.

Thanks for read and Have a great day. ❤️
Please give your love and support to this post.

Why Laravel is better then NodeJs/Express?

Yogesh Galav — Sun, 07 Jul 2024 06:33:00 +0000

Hello WebDevs,
First thing first, JS devs have more salary then PHP devs on average.
I've come from Laravel background and recently due to less salary in php environment I switched to JS environment NodeJs/Express. You can get more salary in php but that require other knowledge like DSA, SQL or Project Management.

If you are a Startup which has less time to go to market, want's less overhead tension and want cheaper employees then always prefer Laravel.

The major drawback of using JS is there's no batteries included framework in JS, you have to search a good package with good documentation and actively maintain. Then learn that library. Then if in future it's not maintained or any security issue came then repeat the process again.
While in batteries included framework majority of features will be maintained till lifetime of framework so we don't have to worry a bit.

The reality of tech world is you get more money to work on complex technology, Even if the simpler solution is more Robust.

Woof that was lot from my heart and not to be made public but will help you guys make the right decision.

I will share my real world experience of onboarding to Express project.
Let's compare implementation difference both the frameworks.

1. Language

Laravel is created from PHP one of the most used programming language in backend.
Express is created in JS, a functional programming language made for browsers running frontend.
Although you can do functional programming in PHP and OOP in JS, it's not that much supportive and easy.
The only major benefit of JS is speed due to it's asynchronous nature.
You can return the response while not waiting for other functions like logging or saving record/file
But as con part you have to take care of async-await as well in JS, for the same reason.
Php will just perform task synchronously, There's no such concept of promises or async/await here. Also due to same reason PHP is more easy to grab then JS.
For performing background task in Laravel, We have Jobs and Queues.
Another major difference between both languages is PHP provides optional type checking, while JS doesn't provide any type checking or else you have to use strict type checking with TypeScript.

2. Routes

Express provides mostly routing features.
Both frameworks provide use of separate files with name, middleware and prefix.
Laravel provide Route grouping and in node you have to use another package and learn it.
Laravel provide RouteBinding in controller parameters, It can even throw 404 if data not found in database. In Express you have to do it manually and add that data to request body, there's no concept of controller parameter binding or DB checking.
Laravel provide clear separation between web, api, console and channel route, A backend application generally needs all this. While in express you have to learn and implement all by yourself. If a beginner don't know what channel and console routes are Laravel will give opportunity to learn while express will not push him/her for learning.

3. Middleware
In Express every callback you provide to route is middleware, there's no clear difference between controller and middleware part.
A controller business logic is always unique for some request while middleware is peace of common to multiple request and always need to be run first before or after controller. If you give express to beginner they may put middleware after request validation or controller in Express but in Laravel it's not possible.

4. Request validation
Laravel provides simple yet powerful solution for request validation like FormRequest which provides feature like authorization, validation messages, pre-validation request update and post-validation,
While in Express you have to choose, learn and implement a package.
then also you will not find features like FormRequest in same package.

5. ORM
Express provide no ORM. When I started express I searched for good query builder and ended up with Sequalize, then learned it via documentation, then struggled a lot to implement it. then my friend told me it's not actively maintained. And then I find out recent commits in github were done by bots. Then again I found another query builder like knex, then learnt it, then also it was not as good as Eloquent ORM and Laravel DB query builder provided by default.

6. Logging
Last but not least logging, Laravel provide default and simple logging while I have to struggle a lot to implement logging via another third party package called winston. then for keeping separate files for separate dates I have to again install another package called daily-rotate. In both framework you can install extra package to log into other channels like email or slack.

In the end both are legendary frameworks, there's no hate for any framework, I only shared my experience, your experience and use case might be different. Please let me know If I'm wrong anywhere.

I hope you enjoyed reading this.
Thanks and regards,
Yogesh Galav

What are Api Standards or REST Style?

Yogesh Galav — Sun, 30 Jun 2024 17:08:28 +0000

Hello WebDevs,
I bet whichever framework you have been working on, you must have crossed your roads with API's and would have stuck for moment what should be the standard path for the URL you could use for that API.

Naming is the most difficult or brain consuming task for programmers, and when it comes to full url it becomes more difficult because they are not scoped by any block, they are all global and can be confusing if not used correctly.

For this Purpose some elite member of society ( Roy Fielding ) created a framework or architectural style called REST. It's very small concept but it becomes difficult when you start using it in real world project and brain consumption becomes equal. Hence I'm writing this blog to simplify the things for you, Let's Start.

What is REST?

REST(Representational State Transfer) is a standard that guides the design and development of processes for interacting with data stored on web servers. It simplifies communication by providing various HTTP methods (such as GET, POST, PUT, DELETE) that allow us to perform CRUD operations (Create, Read, Update, Delete) on server data. Think of REST as the set of rules that govern how we communicate with servers using the HTTP protocol.

In simple words,

It tells us how to change the state of our resource(db tables, files) on server with help of standard API pattern.

Here server means, machine from which we are requesting to change the state of our resources.

Now let's jump to real world example:

1. Fetch Data: Get Request

If you want a list of items like list of users or post, or excel/csv containing list then we will always use Get request.
If you want to filter or apply condition to the same list just use query parameters in get request.
Even if you have large form for filter, try to pass only id's. but use get request. This will help you retain filter and pagination when you navigate back and forth on website.
Example 1: /users/list?paginate=3&email=mr.yogesh.galav&name=yogesh
Example 2: /users/:id/details
Example 3: /users/:id/orders/csv

2. Create Data: Post Request

It's the most common type of web request, but real purpose of this type is to create resources on server, like create db row, create user in registration, create token in login, create or save some file like profile pic/resume, etc.
If you want some operation like createOrFind, updateOrCreate then also use post request.
If you don't know what type of request it should be, but want to send lot of data to server like form data or file, then use this.
Example 1: /users/create
Example 2: /users/:id/orders/create
Example 3: /users/:id/profile-pic

3. Update Data: Patch Request

For updating resources on server Patch request is used. Most of the time we may think that create and update may share same controller or business logic, but as our business logic grows it becomes harder to maintain both at same place, hence a separate route/url with patch request is beneficial.
If you want update some record on database on server then use this.
Example 1: /users/update
Example 2: /users/:id/orders/update

4. Replace Data: Put Request

Unlike Database resources, files are generally replaced on server when it comes to update operation.
If you want replace some file on server then use this.
Example 1: /users/:id/profile-pic/replace

3. Delete Data: Delete Request

This is most simple type of web request, as the name suggests, it is used to delete resources on server.
If you want to delete some database record or file or token while logout use this.
Example 1: /logout
Example 2: /users/:id/delete
Example 2: /users/:id/history/delete

These are only standards and not any hard and fast rule which will throw error somewhere so you can bend it like your choice but fundamentals should remain same so that url is clearly understandable without having to look into context or code.

Please Note that I have used suffix like create, details, update, replace, delete in above api's, It was personally easy for me to manage routes this way in framework, If you like not to use them then also fine, but then you had to take care of route ordering otherwise your framework will read

/users/create

as

/users/:id

I hope you enjoyed reading this.
Thanks & Regards,
Yogesh Galav

What are Composable Function?

Yogesh Galav — Fri, 03 May 2024 18:51:11 +0000

Since last year, I came across the concept of Composable function couple of times while learning about Vue3. When I searched on google found nothing about it, hence I might be the first person writing about it. I didn't fully understand this concept until I created my own Package VueNiceValidate.
Hence today I want to share my knowledge about composable function in this blog, which I attained from practical implementation.

If I comprise my understanding in one line then it's like:

Composable Function are functional representation of Class.

Yes, in OOP language like Java, Dart or even Php we have to create class and objects for declaring and using entities. Let's take example of person and fist implement in class way and then functional way.

Suppose you want to have many persons in your application with same properties as name and age. Also you want a common function
displayInfo for each person.
How would you do it? 99% of you would end up answering class and object, because that has been the way since the born of c++ and Java. Even the JavaScript which was suppose to focus on functional paradigm implemented class for the same reason.

Here's how the Person class will look like in JS. In all the language class concept at core will remain the same.

class Person {
    // class variables
    let name;
    let age;

    // constructor
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }
    displayInfo(){
        console.log(this.name + "is " + this.age + " years old!");
        return;
    }
}

We will have class name declaration
Then class private variable declaration like name and age.
Then we will implement constructor function for defining private variables at the time of creation of object, so no person can be created without name or age.
At last we will implement all our functions or methods we want to operate over person.

Now let's see how will we create object from this class

const firstPerson = new Person('Yogesh', 29);
firstPerson.displayInfo();
const secondPerson = new Person('Piyush', 24);
secondPerson.displayInfo();

I know till here was just the lame part you already now even if you have small experience with programming languages.

Now What if we want to implement the same concept in functional way without using the class.
If you are a beginner you might think why can't we just make a single file with name and age variable and export the functions.
But it would actually create a common state like state management tool or like static variables and function. The real answer is Composable function.

Composable function are just regular function used in a way so that it creates a new copy of object each time we call it.

As per common notation we start composable function name with use word. In our case usePerson will be the composable function which will create new object of person each time we will call it.

How to implement Composable Function

export function usePerson(personName, personAge){
  let name = personName;
  let age = personAge;
  function displayInfo(){
    console.log(name + "is " + age + " years old!");
    return;
  }

  return {
    displayInfo,
  }
}

We will create our composable function with the name of usePerson
This function will take same parameters or arguments which we passed to constructor in class format. Hence it doesn't require any constructor concept.
We will declare our public or private variable as simple scoped variables inside our composable function. To initialize this variables like constructor we simply initialize them at place of declaration.
Then we will implement our public or private functions as simple functions.
At last we will return an object including public properties. The variables and function we don't return will act as private properties, that's it.

Now let's see how will we create object from this composable function.

const firstPerson = usePerson('Yogesh', 29);
firstPerson.displayInfo();
const secondPerson = usePerson('Piyush', 24);
secondPerson.displayInfo();

Here we are creating firstPerson and secondPerson object by just calling usePerson function. This composable function will create new copy of name, age, displayInfo each time it will be called.

It's even more simpler then class way or OOP way because it doesn't include concept like constructor or public, private variables, Just function, function and function. That's the beauty of functional programming.

I hope you enjoyed reading this and fully understood the concept of composable functions.

Thanks and Regards,
Yogesh Galav

Stop using Try-Catch everywhere!

Yogesh Galav — Sat, 20 Apr 2024 03:22:34 +0000

Yes, you read it write. Here I will only share my experience and if you agree or convinced with it give it a like so it could reach to more people.
I'm a Full Stack developer with 6 years of experience, and in this tenure I mostly worked with Rest Api's. I have seen my fellow developers write try catch in every controller or api code.
And also on frontend side in all api requests.
Now I will explain one by one why this is redundant code.

Why we need to stop using Try-catch block

1. It stops the error to be shown or debugged.
Let's suppose you have error coming in your browser console
Cannot read response of undefined
I hope most of you will have seen this error. When we debug, we will find out that it's coming from catch block of 'fetch' or 'axios' promise api call.

axios.get('/my-api')
.then((res)=>{
  //some error code
  let user_name = res.data.user.full_name
})
.catch((err)=>{
   if (500 === err.response.status) {
     //do this
   }
   if (422 === err.response.status) {
     //do this
   }
})

Now last developer want to secure the 500 error by using try catch but guess what, it takes more effort for current developers to figure where's the error in then block, most of junior developers are not even able to recognize the above error.
Now you may argue all it takes is console statement in catch, but if that can't be pushed due to linting rules, that's extra effort as well, Isn't it?

Now move on to our next effort, sorry next step.
let's suppose the error is user property is not present in api, now we have to debug backend for that, Let's suppose our backend controller or logic code is written in this way

function myApiFunction(){
  try{
    const result = await models.Person.find({});
    res.locals.people = result;

    next();
  } catch (error){
    return next({
      log: `An error occurred at controller.myApiFunction ${error}`,
      status: 500,
      message: { err: 'An error occurred' }
    });
  }
}

Now first thing is if you return or next from inside try block it will never reach to catch. Now actual problem here is we are returning variable with people not user.

Now Let's suppose the second scenario that there really was some error in our 'myApiFunction'. All we will get in frontend is
'An error occurred'. What did the frontend guy will understand from it. if you have made extra effort to not show error to user, you could have diverted that effort to make your code error free.

If you use Modern backend frameworks, you can define common error handler and you get structured error response anyway, so why did you put extra effort to write that try catch block.

2. It is repeating code, which violates DRY rule.
Now let's jump to second problem statement.
99% of time you will write same code in catch block in every controller and in every frontend api catch block.
The solution for this problem is using interceptors for package like axios in frontend and in backend, most modern frameworks provide elegant way to handle all your 500, 422, 401 etc errors at one place. You can even configure it for web and api request separately.

3. It is non Testable.
Most developers in my community or in my region don't write tests,
But the people who do realises how difficult it is complete code coverage.
For the developers who don't know what is code coverage it's representation of what part of your code is covered in test cases.
You can never cover catch block. Because if you know where error will occur you will fix it, you will not ship the error to client right?
The typescript and typed parameters in languages in php makes it further difficult for error to induce inside the function.

Where should we use try catch

Now I'm not saying we should never use try-catch, only want to save you effort and want to reduce your code. At some places it becomes necessary to use try-catch, Here we will discuss them

1. Function with multiple DB insertion and update queries.
Sometimes you have to run multiple queries for insertion and updation in your logic part, If any thing in between broke then some queries which already ran will be successful and will create garbage data. In this case we can use database transactions with try catch, here how it looks like

function myApiFunction(){
  await connection.beginTransaction();

  try {
    // multiple insertion and updation queries
    await connection.commit();
  } catch (error) {
    await connection.rollback();
  } finally {
    await connection.end();
  }

  return 'something';
}

in above code we start declare db transaction, then executes all our queries then if all things successful we commit the results which finally changes the state of our database, else if any error occurs we can do rollback, and our database will return to original state before starting the transaction.

2. Third party Api call
Third party code is always a mystery, what error they return in which case we have to code it all, since we can't do all that in beginning we should must use try catch to catch all possible errors from third party api call.

try{
  stripe.doThis();
  twillio.doThat();
} catch(error) {
  log.info('Error occured in stripe while doing this.', error);
}

3. Handling external resource like file Handling.
Similarly like third party services, we also don't know about external resources like files. In our application when we read document or media files we must take in scenario that this file may not be in format we assume,
For example you have csv import api, there's lot of uncertainty in this case.

The CSV may not be in correct format.
The file extension may not be correct.
The file may be corrupt or in other asci/utf code.
Query for importing or updating csv item may fail for some item. Hence we need to cover this all factors in separate try catch. Hope you enjoyed this post. Please support my post with like and if you have job reference please pass onto my linkedin profile.

4. Running heavy tasks in background or in loop
Heavy tasks like heavy file import, bulk email etc. can be done efficiently in background and off course there will be loop involved in it, So whole job shouldn't terminate if there's error in any single item or task, therefore we need to use try-catch for safe continuation of background job or loop.

bonus tip: Async-Await

If you use Promises in JS or Dart with async-await syntax then you must be using try-catch block with it and hence you might totally disagree with post, therefore I'm writting this bonus tip for improving your code quality. Consider the following code which is general case for calling api's in your code.

try {
  await firstApiCall()
} catch(error) { 
  handle(error) 
}
try {
  await secondApiCall()
} catch(error) { 
  handle(error) 
}
try {
  await thirdApiCall()
} catch(error) { 
  handle(error) 
}

As you can see there's lot of repeating code or try-catch here, hence we will standardize our code to escape this hell. The only condition here is you have to use same response format on both frontend and backend.

async ApiCall(){
  const response = {data, success, message};
  try{
    response = await respectiveApiCall();
  } catch(error) {
    response = { data:null, success:false, message:error };
  }
  return response;
}

This is my personal choice however if you don't like it or it doesn't fit you your case you can refer to this short video as well by Firship.io.

Thanks and Regards,
Yogesh Galav

Use MVCRSH instead of MVC.

Yogesh Galav — Mon, 11 Mar 2024 16:28:27 +0000

There is a famous style of programming which most of you already knew "MVC" it's even inbuild in frameworks like Laravel and ROR.
You can also apply this style to frontend framework like flutter, Vue and React for better productivity.
Today I want to share an extended version of MVC which we all should use instead of MVC to keep code clean and healthy.
It's MVCRSH - Model, View, Controller, Routes, Services and Helpers.

What is MVC?

MVC (Model, View, Controller) is architecture for dividing our code in application.

Why we need to extend it?

MVC might be an good style for keeping things separated but there will be sometimes when you will get confused if the particular piece of code should be put in Controller or Model.

Model

Model should contain only definition of entity or database table, The field it contains, type of fields, foreign-key etc.

To define our list of fields we can define an array or object. In array you can only suggest field names while in object you can also provide their data types.
We can define relationship with help of functions to fetch related data, In most ORM we can define what kind of relationship do we want with other entities and fetch data accordingly.
We can also define Accessor or Mutator to run some condition before fechting or saving data.
Here's the list of famous ORM w.r.t frameworks which provide model functionality, for Laravel it's Eloquent, for Node it's Drizzle or prism, for Flutter it's Sqflite.

View

View should only contain UI part, which user sees or interact with. For web It ultimately compiles to HTML, CSS and JS.
Hence all the files related to it come inside view.

We can define which layout do we wan to use.
When using frontend framework, reactive data and js methods also comes into picture.
Along with it, more complex things like frontend routing and state management start to fill the view part. With tools like Inertia or File based routing we can eliminate frontend routing code.
Here's the list of famous templating engine w.r.t frameworks which provide UI functionality, for Laravel it's Blade, for Express it's pug, for Flutter it's Flutter.

Controller

Controller as we know should only contain business logic but there's lot of logic like validation, running big query, sending email, generating csv or excel and using services like Twilio, stripe, gmap etc.

We should only call functions to above all use cases inside controller, the way we call model inside controller.
Validation can be call before executing controller function like middleware. Framework like Laravel provide dependency injection for doing the same.
Rest of the things will move to services and helpers.
Controllers should contain only single word functions like create, update, delete, index, show, download, csv, excel etc

Routes

Routes as we all know are starting point of user entry in application, hence it's most simple and absolute one.
Most framework provide routing by default, In framework like flutter you can use get_router or getx to define routes.

Services

Services should be made in way, so that they can be used in any other project like ApiService, CsvExport, ExcelImport, TwilioSms, Mailchimp.

The code in services should always be reusable so it can be used in any project.

Helpers

Last but not the least, Helpers provide help to controller and model. The logic or function which makes controller bulky should be moved to helpers instead of models. Most developers confuse between Utils and helpers but they are not the same.
In frontend frameworks, state management tools are kind of helpers only. In backend frameworks you need to create one otherwise you would end up writing most of the bulky logic inside controller or model. Helper pattern can be better alternative to repository pattern here's how:

Helper class should extend particular modal class. Hence we can use helpers instead of models everywhere with extended functionality without breaking the quality of models.

namespace App\Helpers;

use App\Models\User;
class UserHelper extend User {}

We should not use Services and Jobs inside helpers, same as model, We can however access other helpers to perform dependency operation.
The meaning of this class is to help model entity perform tasks, the controller methods are more of crud operation, and models methods are limited to database only, hence we need human readable and doable tasks in form of methods inside helpers. For eg. UserHelper will contain methods like getFriendsList, getPhotos, getRecentPosts
While working between multiple models/helpers, most beginners get confused and create duplicate methods like PostHelper->getRecentPostsForUser While doing so we must remember which primary or single entity we want data for.

I hope you find this post useful for whatever framework you use.
Thank you and have a nice day!