DEV Community: Shahadat Hossain

Recap the highlight of the sorting algorithms using JavaScript for beginners

Shahadat Hossain — Sat, 05 Oct 2024 15:45:01 +0000

Sorting algorithms are methods used to arrange elements of a list or array in a specific order, typically numerical or lexicographical. They are fundamental in computer science for organizing data efficiently. It is an exercise in understanding how to break down a problem into steps and then implement those steps, i.e., how to create an algorithm. It's also an exercise in realizing that there are multiple methods to tackle an issue, and some are superior to others.

Why should I learn it?

It's a simple practical example for thinking recursively (see: merge sort and quick sort) and divide and conquer.
It's a simple but nontrivial example for algorithmic analysis (I.e. big O).
It's a traditional intro computer science topic that is expected to be taught.
It's a simple example to motivate why you might care about having a better algorithm than the simplest native one (I.e. bubble sort).

Here are some common sorting algorithms

Bubble Sort

Description: Repeatedly swaps adjacent elements if they are in the wrong order.
Time Complexity: O(n²)
Use Case: Simple but inefficient for large datasets.
Bubble Sort GitHub Gist

var arr = [10, 55, 20, 4, 28, 69, 22, 85, 7, 37];

function bubbleSort(arr)
{
    var temp, i, j;

    for(i = 0; i<arr.length; i++)
    {
        for(j = 0; j< arr.length; j++)
        {
            if (arr[j] > arr[j+1])
            {
                temp = arr[j];
                arr[j] = arr[j+1];
                arr[j+1] = temp;
            }
        }
    }

    return arr;
}

console.log(bubbleSort(arr));

Selection Sort

Description: Selects the smallest element from the unsorted part and swaps it with the first unsorted element.
Time Complexity: O(n²)
Use Case: Inefficient for large datasets but easy to implement.
Selection Sort GitHub Gist

var arr = [10, 55, 20, 4, 28, 69, 22, 85, 7, 37];

function selectionSort(arr)
{
   var min;
   for(var i = 0; i < arr.length; i++)
   {
       min = i;
       for(var j = i+1; j < arr.length; j++ )
       {
           if (arr[j] < arr[min])
           {
               min = j;
           }
       }


       if (min !== i) {
           var s = arr[min];
           arr[min] = arr[i];
           arr[i] = s;
       }
   }

   return arr;
}

console.log(selectionSort(arr));

Insertion Sort

Description: Builds the sorted list one element at a time by inserting each element into its correct position.
Time Complexity: O(n²)
Use Case: Good for small datasets or nearly sorted arrays.
Insertion Sort GitHub Gist

var arr = [10, 55, 20, 4, 28, 69, 22, 85, 7, 37];

function insertionSort(arr)
{
    for(let i = 1; i< arr.length; i++)
    {
        let key= arr[i];
        let j = i - 1

        while (j >= 0 && key < arr[j]) {
            arr[j+1] = arr[j];
            j--;
        }
        arr[j+1] = key;
    }

    return arr;
}

console.log(insertionSort(arr));

Merge Sort

Description: Divides the array into halves, recursively sorts them, and then merges the sorted halves.
Time Complexity: O(n log n)
Use Case: Efficient for large datasets, uses additional space for merging.
Merge Sort GitHub Gist
Merge Sort 2 GitHub Gist

var unsortedArr = [10, 55, 20, 4, 28, 69, 22, 85, 7, 37];

function merge(left, right)
{
    const result = new Array();

    let i = j = 0;
    while (i < left.length && j < right.length) {
        if (left[i] < right[j]){
            result.push(left[i]);
            i++;
        }else {
            result.push(right[j]);
            j++;
        }
    }

    while (i < left.length) {
        result.push(left[i]);
        i++;
    }

    while (j < right.length) {
        result.push(right[j]);
        j++;
    }

    return result;
}

function mergeSort(arr)
{
    if (arr.length <= 1)
        return arr;

    const mid = Math.floor(arr.length/2);
    const LA = new Array();
    const RA = new Array();

    for(let i = 0; i< mid; i++)
        LA.push(arr[i]);

    for(let j = mid; j< arr.length; j++)
        RA.push(arr[j]);


    const leftSorted = mergeSort(LA);
    const rightSorted = mergeSort(RA);

    return merge(leftSorted, rightSorted);
}

console.log(mergeSort(unsortedArr));

Quick Sort

Description: Selects a pivot element and partitions the array into two sub-arrays: elements less than the pivot and elements greater than the pivot, then recursively sorts the sub-arrays.
Time Complexity: O(n log n) on average, O(n²) in the worst case.
Use Case: Fast and widely used for large datasets.
Quick Sort GitHub Gist

var arr = [10, 55, 20, 4, 28, 69, 22, 85, 7, 37];

function partition(arr, low, high)
{
    const pivot = arr[high];

    let i = low -1;

    for(let j = low; j <= high -1; j++)
    {
        if (arr[j] < pivot) {
            i++
            swap(arr, i, j)
        }
    }

    swap(arr, i+ 1, high);

    return i + 1
}

function swap(arr, i, j)
{
    let temp = arr[i];
    arr[i] = arr[j];
    arr[j] = temp;
}

function QuickSort(arr, low, high)
{
    if (low  < high){
        const po = partition(arr, low, high);
        QuickSort(arr, low, po - 1);
        QuickSort(arr, po + 1, high);
    }

    return arr;
}

console.log(QuickSort(arr, 0, arr.length - 1));

Heap Sort

Description: Converts the array into a heap data structure and repeatedly extracts the maximum element to build the sorted array.
Time Complexity: O(n log n)
Use Case: Efficient and doesn't require extra space like merge sort.

Radix Sort

Description: Non-comparative sorting algorithm that sorts elements digit by digit, starting from the least significant digit to the most significant.
Time Complexity: O(nk) where k is the number of digits.
Use Case: Suitable for sorting numbers or strings with fixed-length keys.

Bucket Sort

Description: Divides elements into several buckets and then sorts each bucket individually (usually using another sorting algorithm).
Time Complexity: O(n + k) where k is the number of buckets.
Use Case: Effective when input is uniformly distributed over a range.

Each algorithm has its strengths and weaknesses, and the choice of which one to use depends on the size of the dataset, memory constraints, and whether the data is partially sorted.

Let's discuss how often we should practice those.

3 major REST API problem can solve using GraphQL

Shahadat Hossain — Tue, 16 Apr 2019 05:07:56 +0000

Here I am not going to talk what is and how do GraphQL. I think, there are hundreds of articles about it. I want to share, what I understand in my learning and working time. if I am wrong please amend me.

When Facebook building its mobile application in 2012 its faced some issues in their REST API which led them to create GraphQL. We are also facing those problems when we design the REST API. That is :

Poor performance
A lot of endpoints
Over-fetching or under-fetching of data
Difficulty understanding APIs
Difficulty API versioning

With GraphQL, we get a lot of new features that give you superpowers when you are building your APIs.

Minimize data fetching

Over-fetching or Under-fetching is a performance issue in REST API. Basic REST APIs always return a fixed structure of data. we should fetch the data that we need. Using GraphQL we can minimize data fetching and improve the performance of our REST API especially in case of slow network connection.

There’s also a problem with under-fetching of information. To fetch relational data we need too many requests in the server or large object with unnecessary data. This damage not only our application performance but also catch space. In that case, GraphQL can help to solve the problem.

Minimize Application endpoint

To fetch REST API data all of us use CRUD system. For each particular resource, there are GET, POST, PUT, DELETE, OPTION request methods to control data. So, in a real-world application, we would end up having a lot of endpoints for a lot of resources. It is hard to remember or control those endpoints. If you are dealing with large scale application like facebook or twitter, it is very difficult to maintaining those endpoints.

This biggest problem can solve using GraphQL. GraphQL has only one endpoint and just makes the whole server a single custom endpoint that can reply to all data questions. You just need type or mutation to control your resource.

Optimize API Versioning

One of the biggest problem in general REST API is version controlling. In different reason and adding new features, we need to change backend API several times. To keep unbreakable front-end and API users we need vertioning in our REST API.

In GraphQL there’s no need for it since you are fetching your APIs by adding new types or removing old ones. Since are fetching, how much data we need, it will be unbreakable in most of the case.
Also, there is an only one endpoint we do not need endpoint like

https://api.example.com/v1/users/12312
https://api.example.com/v2/users/12312

Conclusion

GraphQL might seem complex at first because it’s a technology that reaches across many areas of modern development. But if you take the time to understand the underlying concepts, I think you’ll find out that a lot of it just makes sense.
Agree? Disagree? Questions? Just let me know here in the comments. And if you’ve enjoyed this article, please consider and sharing it! Want to reach me just follow on twitter

Designing Laravel REST API: Best practices

Shahadat Hossain — Sun, 07 Apr 2019 19:15:49 +0000

In modern application, API is one of the main feature in the application. It’s not only for creating mobile applications, desktop applications but also important for self-hosted web applications.

Now front-end and backend applications development has great changes using Vue or React front-end framework. All new applications want to single page application. That’s why implement API in the backend is the main feature.

Basically, an API is an interface that returns data in a special format that any kind of application, either it’s an Android app or a web app, can understand.

When developing an API, you need to take into considerations some best practices which follow different developer. I have research on web tutorials and sort out some best practices which I follow in my Laravel applications.

Best practices for developing Laravel rest API

Coding standards

It’s not only related to designing rest API, but it’s related to all kind of applications. Whenever I start building some application I start reading the coding standard of the application even I read it before. It’s forced me to follow the coding standard. Some of are related to designing rest API in Laravel.

Use routes/api.php file for API routes

Laravel be default has a separateroutes/api.php file that defers from the usual routes/web.php file. I think we must store our API routes in this file. It has an onboard applied middleware (which can be seen inapp/Http/Kernel.php the $middlewareGroups variable, under api) and a prefix of/api so all routes defined are already available to /api.

Route names with a api prefix

What I like to do, is to set a group route an as setting to the whole API, so I can access the routes by their name, with api. prefix.

Route::get('/users', "API\V1\UserController@index")->name("users");

This route’s URL can be get using route('users') but it might conflict with web.php.

Route::group(['as' => 'api.'], function () {
  Route::get('/users', 'API\V1\UserController@index)->name('users');
});

This way, you will have it on route('api.users').

If you use the route namings, if you write tests, you won’t need to replace the URL everywhere if you plan to change the URL location and keep the route name.

Use plurals to describe resources

When you write resource route you should write plurals.

Route::resource('/users', 'API\V1\UserController’)->name('users');
// mysite.com/api/v1/customers

API Versioning

Remember the API will be used by other programs. We occasionally update the code on the server but it will break the client’s applications. This is when API versioning comes in handy. If your API is not publicly accessible you can keep as default. Our above URL when versioning is considered will look as follows.

mysite.com/api/v1/customers

Use Passport instead of JWT for API authentication

I personally like the Passport for authentication. It’s reliable and has support for Laravel developer.

Use a transformer

I always use a transformer to get data in one format. Although Laravel has own transformer class I personally like league/fractal

Response Codes and Error Handling

HTTP status codes will simplify giving feedback to your API users. Also you have to give a server message with a response. To handle errors, transformer and keep similar data set I have write a controller that is responsible to handle errors.

Limit the number of request in a given time period from the same IP Address

If it’s exposed to the public online then it is a target for spam, bots and abuse. You can limit to a request made per second to say maybe 5. Anything more than that may be an indicated of automated programs abusing your API.

<?php

namespace App\Http\Controllers\Api\V1;

use League\Fractal\Manager;
use League\Fractal\Resource\Item;
use App\Http\Controllers\Controller;
use League\Fractal\Resource\Collection;
use League\Fractal\Pagination\IlluminatePaginatorAdapter;

class ApiController extends Controller
{
    /**
     * @var int $statusCode
     */
    protected $statusCode = 200;

    const CODE_WRONG_ARGS = 'GEN-FUBARGS';
    const CODE_NOT_FOUND = 'GEN-LIKETHEWIND';
    const CODE_INTERNAL_ERROR = 'GEN-AAAGGH';
    const CODE_UNAUTHORIZED = 'GEN-MAYBGTFO';
    const CODE_FORBIDDEN = 'GEN-GTFO';
    const CODE_INVALID_MIME_TYPE = 'GEN-UMWUT';

    /**
     * @var Manager $fractal
     */
    protected $fractal;

    public function __construct()
    {
        $this->fractal = new Manager;

        if (isset($_GET['include'])) {
            $this->fractal->parseIncludes($_GET['include']);
        }
    }

    /**
     * Get the status code.
     *
     * @return int $statusCode
     */
    public function getStatusCode()
    {
        return $this->statusCode;
    }

    /**
     * Set the status code.
     *
     * @param $statusCode
     * @return $this
     */
    public function setStatusCode($statusCode)
    {
        $this->statusCode = $statusCode;

        return $this;
    }

    /**
     * Repond a no content response.
     * 
     * @return response
     */
    public function noContent()
    {
        return response()->json(null, 204);
    }

    /**
     * Respond the item data.
     *
     * @param $item
     * @param $callback
     * @return mixed
     */
    public function respondWithItem($item, $callback, $message = 'Successfully')
    {
        $resource = new Item($item, $callback);

        $data = $this->fractal->createData($resource)->toArray();

        $data['message'] = $message;

        return $this->respondWithArray($data);
    }

    /**
     * Respond the collection data.
     *
     * @param $collection
     * @param $callback
     * @return mixed
     */
    public function respondWithCollection($collection, $callback, $message = 'Successfully')
    {
        $resource = new Collection($collection, $callback);

        $data = $this->fractal->createData($resource)->toArray();
        $data['message'] = $message;

        return $this->respondWithArray($data);
    }

    /**
     * Respond the collection data with pagination.
     *
     * @param $paginator
     * @param $callback
     * @return mixed
     */
    public function respondWithPaginator($paginator, $callback, $message = 'Successfully')
    {
        $resource = new Collection($paginator->getCollection(), $callback);

        $resource->setPaginator(new IlluminatePaginatorAdapter($paginator));

        $data = $this->fractal->createData($resource)->toArray();
        $data['message'] = $message;

        return $this->respondWithArray($data);
    }

    /**
     * Respond the data.
     *
     * @param array $array
     * @param array $headers
     * @return mixed
     */
    public function respondWithArray(array $array, array $headers = [])
    {
        return response()->json($array, $this->statusCode, $headers);
    }

    /**
     * Respond the message.
     * 
     * @param string $message
     * @return json
     */

    public function respondWithMessage ($message) {
        return $this->setStatusCode(200)
            ->respondWithArray([
                    'message' => $message,
                ]);
    }

    /**
     * Respond the error message.
     * 
     * @param string $message
     * @param string $errorCode
     * @return json
     */
    protected function respondWithError($message, $errorCode, $errors = [])
    {
        if ($this->statusCode === 200) {
            trigger_error(
                "You better have a really good reason for erroring on a 200...",
                E_USER_WARNING
            );
        }

        return $this->respondWithArray([
            'errors' => $errors,
            'code' => $errorCode,
            'message' => $message,
        ]);
    }

    /**
     * Respond the error of 'Forbidden'
     * 
     * @param string $message
     * @return json
     */
    public function errorForbidden($message = 'Forbidden', $errors = [])
    {
        return $this->setStatusCode(500)
                    ->respondWithError($message, self::CODE_FORBIDDEN, $errors);
    }

    /**
     * Respond the error of 'Internal Error'.
     * 
     * @param string $message
     * @return json
     */
    public function errorInternalError($message = 'Internal Error', $errors = [])
    {
        return $this->setStatusCode(500)
                    ->respondWithError($message, self::CODE_INTERNAL_ERROR, $errors);
    }

    /**
     * Respond the error of 'Resource Not Found'
     * 
     * @param string $message
     * @return json
     */
    public function errorNotFound($message = 'Resource Not Found', $errors = [])
    {
        return $this->setStatusCode(404)
                    ->respondWithError($message, self::CODE_NOT_FOUND, $errors);
    }

    /**
     * Respond the error of 'Unauthorized'.
     * 
     * @param string $message
     * @return json
     */
    public function errorUnauthorized($message = 'Unauthorized', $errors = [])
    {
        return $this->setStatusCode(401)
                    ->respondWithError($message, self::CODE_UNAUTHORIZED, $errors);
    }

    /**
     * Respond the error of 'Wrong Arguments'.
     * 
     * @param string $message
     * @return json
     */
    public function errorWrongArgs($message = 'Wrong Arguments', $errors = [])
    {
        return $this->setStatusCode(400)
                    ->respondWithError($message, self::CODE_WRONG_ARGS, $errors);
    }
}

Security

The biggest problem you should be take care of is security. Laravel application is easy to secure it, but if not doing it properly, you might get hacked. In Laravel, you might want to use Laravel Passport — it belongs to the Laravel ecosystem, supports authentication through that App ID — App Secret thingy in order to get an access token, either to impersonate somebody or a server, either it’s backend or frontend.

Too hard to understand? Reach me!

If you have more questions about Laravel, if you need help with any information related to Laravel you can get in touch.

Say Thank you.

If any mistake please mention in the comment. If you like it you can encourage me saying Thank you.

The post Designing Laravel REST API: Best practices appeared first on Shahadat Hossain.

How I structured my Vue project for scaling large Vue.js application

Shahadat Hossain — Tue, 02 Apr 2019 21:53:06 +0000

Vue.js is great. However, when you start building large scale Vue applications, you will find some architectural issues in your application. These issues are not really the limitations of the framework; rather these are the important design decisions that Vue.js team had taken from time to time.

Unlike React or Angular, Vue.js caters to the different level of developers. It is developers friendly, easy-to-use for beginners and equally flexible for experts. It doesn’t try to shy away from DOM. Instead, it plays well with it.

Like other developers, first, you have to consider exactly what are your needs when building a large scale application. So I will share my own experience building a large app with vue, vuex, vue-router as front-end application.

The difficulties of building a large scale application

I face some of the difficulties when I working on a large scale application. we should Be prepared to

Review the behavior, the architecture, the code base and the look of the front-end several times, which takes a long time.
Change several times as long as the change in the backend the ways to access the data.
Manage code from different developers with diametrically opposed ways of thinking.
Rewrite codes to the developers that you do not like within your guideline.
Spend a lot, but a LOT of time writing and debugging tests.
Give question answer for the developers and manager where you have written the codes.
The estimates you make on new features ALWAYS magically transform to deadlines, with big events if they are outdated.
Be very very flexible in all those things you need to be ready for.

Component Modularisation

A component as a build tool not only deals with JavaScript; it can also build CSS, templates and other assets. With builder hooks, it can also pre-process files written in non-native formats, e.g. CoffeeScript, SASS and Stylus. Therefore it is possible to deliver highly self-contained components that encapsulate template structure, JavaScript logic and CSS presentation at the same time.

Vue js default folder structure

I recommend you to start the project with vue-cli. I personally like the default Webpack template provided. Here is the content of the src folder.

.
├── app.css
├── App.vue
├── assets
│ └── ...
├── components
│ └── ...
├── main.js
├── mixins
│ └── ...
├── router
│ └── index.js
├── store
│ ├── index.js
│ ├── modules
│ │ └── ...
│ └── mutation-types.js
├── translations
│ └── index.js
├── utils
│ └── ...
└── views
   └── ...

Modularisation of Vue component

Vue-cli provided a great file architecture. But growing your project, your files will start to become overweight.

You might be tempted to put separate your components into multiple folders. But, again, after 10 pages, you will face the same issue again.

The idea is to split your application by notions. Stick to one unique word.

For example, in a shop application, we could get Catalog, Basket and Payment. Now

├─ src/
│ ├─ components/
│ │ ├─ Catalog/
│ │ │ ├─ Components/
│ │ │ ├─ Pages/
│ │ │ ├─ Routes/ Or router.js
│ │ │ ├─ mixin/
│ │ │ │ ├─ catalog.api.js
│ │ │ │ └─ catalog.services.js
│ │ │ ├─ Store/
│ │ │ │ ├─ action.js
│ │ │ │ └─ getters.js
│ │ │ │ └─ mutationTypes.js
│ │ │ │ └─state.js
│ │ │ │ └─ index.js
│ │ │ ├─ Tests/
│ │ │ ├─ Catalog.vue
│ │ │ ├─ index.js

Module A shouldn’t share a component with Module B. For common functionalities (i.e. user logged in, user language…), I have the core folder!

Smart vs. Dumb components

smart components: can access the store, router, window object…
dumbs components: take props, emits events. That’s it!

It is important to keep a separation between your smart components(Pages folder) from the dumbs (Components folder). The main benefits of this approach are reusability, a better separation of concerns.

Testing

Testing application is a very complex topic. It is the hardest part too. By this architecture, I can keep simple and clean. The things I test for the application.

Components: High priority, easy to do. write unit tests for each component. it should be easy to do.
Pages: High priority, hard to do. You probably gonna have to mock API/browser parts.
Routes: Usually bugs aren’t here. Leave it for E2E tests.
Mixins: API Part I personally don’t test this part. But others functions I test it.
Store: The hardest part to test. You can test it via integration tests. Testing action, getter, and initial state separately are useless.

Modularisation of the vuex store

Vuex store, One of the biggest problems with a component-based application. This is a really great tool for state management. The first time I start using the Vue tools, it completely change my mind. But we can’t use it everywhere. With the growing your application the problem arises.

ime travel impossible with lots of mutations when a page load.
The state isn’t reinitialized when page switched. We need to update the state every time;
Overkilled features. You need to create a mutation for everything.

Using module in Vuex store is really great. For beginner user or small projects, you can store data in a file. With growing your project you should separate state, getters, mutations, and actions in different files, which is a good thing. It also presents modules, but without true guidelines to manage them. there’s a lot of ways to handle complexity, each one with pros and cons.

By organizing your store like you gain several advantages :

For more readable and maintainable Having one file per data model is good.
With backend update, you don’t need to change every file.
You can have a consistent getters and methods naming model across different data models.
Don’t overuse the store, you have a complete view where you need to use it or not.

When should I use the store or not?

It’s not mandatory, nor recommended putting all your state inside a Vuex store.

Evan You (creator of Vue.js)

data must be accessible in multiple components of your application, by components which oftentimes are not related in any way, they neither are parents or children of each other.
Data frequently update from different components.
When data complexity is higher to manage it and event passing is not possible
when you need to communicate or pass data between sibling components, or if a data change in one component (such as a boolean change) triggers a change in another

I recommend you to use the local component state as your default and only opt-in to Vuex as soon as a reason to do so arises

The post How I structured my Vue project for scaling large Vue.js application appeared first on Shahadat Hossain.