DEV Community: Awais Akram Mughal

Currying Function and It's Advantages

Awais Akram Mughal — Wed, 17 Jun 2020 14:03:31 +0000

Turning a function that takes multiple arguments, to a function which returns functions (Unary and Anonymous).
Currying is right-associative (Read from Right-Left).
The concept acts systematic: Property needs to interact with other basic properties in order to fully develop its advantages. There is a mutual dependency between the properties involved.
Makes working with HOC(Higher Order Component) much more effective, provided the passed in functions are in curried form themselves.

Let's Look at an Example:

// * Abstraction over Arity(the amount of functions you can curry into one function)

const comp = f => g => x => f(g(x));
const inc = x => x + 1; // * Unary Function
const mul = y => x => x * y; // * Binary Function

// * Normal Composition of two unary Functions:
comp(inc)(inc)(2); // * 4

// * Composition of Binary and Unary Funtions:
comp(mul)(inc)(2)(3); // * 9

// * Invalid Composition of an inner binary Function:
comp(inc)(mul)(2)(3); // * Type Error

Let's look at the Invalid Composition Example:

Here, f's arity doesn't matter, because "comp" is polymorphic in nature/return.
If f is substituted with inc, comp's return type becomes:

x => f(g(x))

If f is substituted with mul, comp's return type becomes:

x => y => f(g(x))(y)

Which is perfectly valid. However, mul here is g and it requires 2 arguments but only one is given, hence, type error.

Important Things to note here:

Arguments Order matters, it only concerns non-commutative functions.
Primary parameters should be placed at the end to facilitate function composition.
Parameters that are least likely to change should be place leftmost to facilitate partially applied functions.

DON'T:

Rely on function's length property.
Use magic auto currying, that is, functions as return values are curried automatically.

Revealing Module Design Pattern

Awais Akram Mughal — Wed, 17 Jun 2020 13:38:09 +0000

Defining all functions and variables in private scope and return an anonymous object with pointers to the private functionality we wished to reveal as public.

var myRevealingModule = (function() {
  var privateVar = "Awais Mughal";
  function privateFunction() {
    console.log('name: ', privateVar);
  }

  function publicGetName() {
    privateFunction();
  }

  return {
    getName: publicGetName
  }
})()

myRevealingModule.getName(); // * name: Awais Mughal

How you can improve the readability in case of multiple functions?

Move the return object to the top, so when you look at the code days after writing, it'll be easy to know the public methods.
Focus on Naming conventions

Advantages:

Syntax of our Script will be more consistent.
readability
Accessibility Concerns are handled

Disadvantages:

If a private function refers to the public function, that public function can't be overridden wile using it on other places(calling the public function from another file) if a patch is necessary. WHY? Because you can't manipulate the implementation of private function from outside.
Public Object members which refer to private variables are also subject to the no-patch rule note above.

Using Recoil With React

Awais Akram Mughal — Mon, 01 Jun 2020 11:04:18 +0000

A new State Management Library for React

If you would like to learn more about its need and the thought process behind it. Kindly go to: Recoil Home Page and watch the video at the bottom of the page.

Introduction:

Firstly:
The basic use of Recoil is through the introduction of Atom.

import { atom } from 'recoil'

export const DataEntriesAtom = atom({
  key: 'dataEntries', // * unique Key (with respect to other atoms/selectors)
  default: [] // * default value (aka initial value)
})

The code is self explanatory with comments.

Here's how you use it in the component.

import React from 'react'
import { useRecoilState } from 'recoil'
import moment from 'moment'

// * Atoms
import { DataEntriesAtom } from '../../Recoil/Data/Atoms'

// * Style
import './index.css'

export default props => {
  const [logbookEntries, setLogbookEntries] = useRecoilState(DataEntriesAtom)

  return (
    <div id='logbook'>
      <div className='title-div'>
        <p className='title'>Logbook</p>
      </div>
      <div className='logbook-result'>
        {logbookEntries.map(entry => (
          <div className='entry' key={entry.id}>
            <p className='date'>
              {moment(entry.createdAt).format('MMMM Do YYYY')}
            </p>
            <div className='value'>{entry.value}</div>
          </div>
        ))}
      </div>
    </div>
  )
}

But What is the use of the Atom you ask?
If you're using the DataEntriesAtom in any other component and you call the setLogbookEntries from this component, Recoil monitors the change in that particular atom and only re-renders the component that is using this Atom. Simple yet efficient.

It reduces the boilerplate code that you have to write and let's say you have a DOM tree with two main branches that have no link to one another, but you want a node of the separate branch to change its value as soon as you change the value of the current branch.

While using redux, you would have to write a lot of code to get this working. But in this case, just defining an atom with get it working. :)

Also, Notice that we are using useRecoilState imported from Recoil.

Secondly:
Recoil Introduced Selector.

import { selector } from 'recoil'

// * Atom
import { DataEntriesAtom } from './Atoms';

// * API calls
import {
  GetDataEntriesAPI
} from '../../Api/Data'

export const GetDataEntriesQuery = selector({
  key: 'dataEntriesQuery',
  get: async ({ get }) => {
    let previousEntries = get(DataEntriesAtom);
    let entries = await GetDataEntriesAPI()

    return previousEntries.concat(entries)
  }
})

Selectors represent derived state. You can think of derived state as the output of passing state to a pure function that modifies the given state in some way.

Let's Setup Recoil:

In you Parent JS File(In my case it's the index.js)

For Asynchronous calls: you can use Suspense, on calling the selector, Recoil will manage the loading of the Component for you.

import React from 'react'
import ReactDOM from 'react-dom'
import { RecoilRoot } from 'recoil'

// * Routes
import Routes from './Routes'

// * Styling
import './index.css'

ReactDOM.render(
  <React.StrictMode>
    <RecoilRoot>
      <React.Suspense fallback={<div>Loading...</div>}>
        <Routes />
      </React.Suspense>
    </RecoilRoot>
  </React.StrictMode>,
  document.getElementById('root')
)

Getting Started with System Design!

Awais Akram Mughal — Mon, 18 May 2020 09:56:46 +0000

Let's get you started with a real world example:

Opening a Restaurant(A Pizza Parlour)

Opening of the restaurant:

You open up the restaurant with a single chef. There comes a point that A single chef can not handle all the orders.

How would you then manage all the incoming orders then?

If you think like a manager, You'll ask the chef to work harder 😁. And you'll pay them more: Put more money, get more output.

Here:
We are Optimizing Processes and Increase Throughput Using the same resource. It's called Vertical Scaling

The other thing you can do is: If the order is a pizza, you can have some ingredients/pieces prepared beforehand so when the order comes, less time is taken.

Preparing beforehand during non-peak hours. It's termed as Pre-processing & Cron Job

Let's make the business Resilient:

Let's say that chef calls in sick one day and you won't have any business that day, So the chef becomes a single point of failure.

What you can do for this kind of emergency:

Hire a backup chef, so, in case if the primary chef doesn't comes, you can employ the backup chef that day.

Keep backups and avoid single point of failure. Backups

Aside from backups, what you can do is hire more primary and backup chefs.
That's buy more resources. It's called Horizontal Scaling.

Let's Expand our Business:

Let's say you got 3 chefs in the Pizza shop and they have their specialties:
chef 1 and chef 2 got specialty in Pizzas, while chef 3's specialty is in garlic bread.

So, to efficiently get the orders done, when an order comes you can direct/route those orders according to the specialty of a chef.
If the order is of a pizza, you can send it to either chef 1 or 2 according to their availability etc. If you want any change in the recipe of a garlic bread, chef 3 is your man.

Let's make a team around the chefs that we have,
Team1: totals chefs: 3, leading: Chef 3 (Getting all the Garlic Bread order)
Team2: total chefs: 3, leading: Chef 2
Team3: total chefs: 4, leading: Chef 1
(Team 2 and 3 get all the Pizza orders)

Now all the pizza orders are being divided/routed towards the Team 2 and 3, while all the garlic bread orders are going to Team 1.

What you're doing is that you are scaling these three teams at different rates and dividing the responsibilities among them.

What we have here now is a Micro-Services Architecture.

At this point your restaurant/Shop is doing pretty well, able to handle different orders and this business is scale-able to a large extent.

But, What if, there is an electricity outage in this shop? You won't have business that day.
What if you loose licence that day? You won't have business that day.

You don't want your eggs in a single basket, you want a separate shop, in a different place may not have the same number of chefs, but, at-least you have a backup.

Now, we create a new shop SHOP 2. This is very we take complexity to a new level. An advantage of shop 2 is that orders close to its range, can be served by it.

Now if you receive an order, you need to be able to route it that either you want this order to be sent to SHOP 1 or SHOP 2. This is called a Distributed System.(partitioning)
It's more response tolerant and gives a quicker response time.

Now let's say you have a customer who sent its order to the Central Authority(the routing mechanism), but you need some specific requirements to route that order to either SHOP 1 or SHOP 2. The parameter can be the delivery time.

Let's say, if you send the order to the SHOP 1, it takes 1.5 hours for it to deliver to the customer, as it's a popular shop. But the SHOP 2 only takes 1 hour to deliver the order.

So, the central authority should route the order to the SHOP 2, and as long as the Central Mechanism is getting real time updates, It can make smart business decisions, which means, more money.

This central Mechanism is called Load Balancer.

At this point, The System is:
Scalable and Fault Tolerant.

How to make it Future Proof?(Extensibility).

You have a delivery agent and a pizza shop, and they have nothing in common, The delivery agent's concern is to only deliver the order as quickly as possible to the customer, while the shop's concern is to prepare the order as quickly as possible, it does not cares who is going to pick the order up.

We can see the separation in responsibilities. It's called Decoupling the System. (Separating out the concerns).

Let's say, SHOP 1's oven becomes faulty or the Delivery agent's bike becomes faulty. You need all the events(logs) happening in present or that have already happened. It's called Logging and Metrics.

The Most Important Point, as a back-end engineer, you need to make your system as extensible as possible, you do not need to rewrite your code again and again to serve a different purpose.

For example, Delivery Agent doesn't need to know that it's delivery a Pizza, it could be a burger tomorrow. Extensible

Finally, Now we are able to scale our business.

Let's recap and see what are the High level problems that we faced and how we resolved them:

Following is know as HIGH LEVEL DESIGN

Order Overload --> Recruitment

Complexity --> Separation of Concern

Mishaps --> Fault Tolerance

LOW LEVEL DESIGN has a lot to do with how you code, making classes, objects, functions, signature.

System Design Basics: Horizontal vs Vertical Scaling

Awais Akram Mughal — Thu, 23 Apr 2020 07:27:39 +0000

Let's understand this concept through a story:

Mughal accidentally made a script and it is running on a local computer, he writes some documentation and makes it public for people to look at.

Now some folks find this functionality very useful and they contact him and tells him that they'll pay for this scripts usage.

So, Mughal Makes an API and exposes the script functionality to them, but it's still running on a computer that he has and he can't keep it running forever, there might be a power outage or it shuts down accidentally, that's quite a problem.

He decides to host/deploy his script on a cloud, which is essentially another computer somewhere, but all the maintenance is provided and you just need to login and do your thing, your immediate concerns are taken care of.

Now, the usage of your scripts functionality is made popular and many other people also want to implement its usage, but more the implementation, more the traffic and more the computational power required to handle those requests sent to the API.

So, He got 2 options:
1: Buy Bigger machine or make computational power of existing machine strong.
2: Buy more machines with the somewhat same computational power, so the requests can be distributed among them.

Here, Option 1 is called Vertical Scaling, which means that you're upgrading your existing machine with regards to your need, while Option 2 is called Horizontal Scaling.

Now, let's compare the Horizontal and Vertical Scaling:

1: In case of Horizontal Scaling, you need an Load Balancer to manage the request pouring in and have them consistent with every machine. While it is not required in the Vertical Scaling.

2: Horizontal Scaling is Data Resilient, which means that if one machine is powered off(let's say), other machines can handle its requests. While that is not the case in the Vertical Scaling, there is only a single point of failure.

3: We have many machines involved in Horizontal Scaling, so the communication between them is done through the Network calls, which makes it a little slow, while on the other side we have a single machine and it uses Inter Process Communication, which is quite fast.

4: Let's say in Horizontal Scaling, machines are communicating with each other and tasks might be dependent, like machine 1 sends data to machine 2, then machine 2 sends it to machine 4, here, you can see that data is complicated to maintain, so if this kind of transaction is happening, what happens is that we have to lock all the databases, which is impractical and because of which we have this issue of loose transactional guarantee, and this is called Data Inconsistency, which is quite a big issue. While it's not the case in Vertical Scaling.

5: Very important point, there's gonna come a point when you just can't upgrade your existing computer, it's the Hardware Limit, In this scenario, Horizontal Scaling Scales well as the number of Users increases.

The Question is: What is being used in the real world?

The Answer is Both, What happens is that we start with Horizontal Scaling and Vertical Scale Every Machine as possible, and we take Strong points from both types,

We take:
Resilience and User Scaling from Horizontal Scaling
Inter Process Communication and Data Consistency from Vertical Scaling

Web First or Mobile First UI Improvement?

Awais Akram Mughal — Mon, 20 Apr 2020 05:29:34 +0000

When you're asked to improve the UI of an already hosted/build Web Application, We always have this thought of should I go with Mobile First Design Improvement or Web First? What Breakpoints Should I use for better responsiveness?

We'll be looking into it, in this post!

What I do is that, I always ask for analytics panel's credentials or permission to view the analytics console of the Web Application.

First: Let's look into how to look for best possible Breakpoints for the Website?

One way is to go in Analytics Console, go to: Audience -> Technology -> Browser & OS -> Click on Screen resolution Tab.

Here you'll get the screen resolutions of the devices, ordered accordingly to the number of users accessing this Website.
You can prioritise the breakpoint accordingly if you want here.

Second way is to go to this link
where you'll see the screen resolution statistics and you can plan accordingly as well.

Secondly: How to make a decision between Web First Design improvement and Mobile First Design improvement?

In Analytics Console, go to: Audience -> Mobile -> Overview

Here you'll be able to see three rows Desktop, Mobile, Tablet, you can make a decision on the basis of number of users as per device.

Generators and Async/Await Comparison

Awais Akram Mughal — Thu, 16 Apr 2020 09:02:05 +0000

What is a Generator?

There is an introduction in ES6 to a new way of working with functions and iterators as generator functions. A generator is a function that gives the power of execution in the hands of the user, what it does is that it can stop at a specific point and returns the power of execution from that point onwards to the user. In short, a generator appears to be a function but it behaves like an iterator. Let's discuss it with an example and comparison with Async/Await.

Example

Generator:

function* generator() {

  // yield Keyword is where the execution stops and an object is returned
  const user = yield getUserFromDB();
  return (user + " Correctly Received");
}

const iterator = generator();

// It will run the generator function up to the first yeild keyword
// But the execution will be halted right after calling the 'getUserFromDB' function but right before assigning it to the const user(Very important to note here)
const iteration = iterator.next();  

// Generator returns an Object after calling the next() function
// iteration will return the unresolved promise {value: Promise{}, done: false}
console.log(iteration);

// Why is the done's value false? 
// You need to understand that, the last yield keyword is like the return statement in the normal function
// while previous yield keywords are like mini returns but they do not terminate the generator
// Only the final yield keyword returns the done:true because it tells that the generator function is now completed, its state is moved to "completed" state.

// It is called when the promise resolves
iteration.value.then( resolvedValue => {
  console.log(resolvedValue); // let's say it's "Got some Users"

  // Now, we can continue the execution by
  const nextIteration = iterator.next(resolvedValue);

  // Notice, we are using the very first const we initialised with
  // Another amazing thing to notice
  // We can pass the value to the generator function as well
  // Which can become the part of the next returned object :-)


  console.log(nextIteration); 
  // We get the final value: {value: "Got some Users Correctly Received", done: true}
  // See, Now Done is true
}

Async/Await:

async function testing() {
  const users = await getUsersFromDB();
  return (users + " Correctly Received");
}
// That's it with async/await :p

The async function declaration defines an asynchronous function — a function that is an AsyncFunction object. Asynchronous functions operate in a separate order than the rest of the code via the event loop, returning an implicit Promise as its result. But the syntax and structure of code using async functions looks like standard synchronous functions.

What is the difference between "Await" and "Yield" Keywords you ask?

Yield can be considered to be the binding block of await. Yield takes the value it's given and passes it to its caller.

The caller can do whatever it wishes with that value
Later the caller may give a value back to the generator(via generator.next()), which becomes the result of the yield expression.
Or an error that will appear to be thrown by the yield expression.

async-await can be considered to use yield.

At the caller(i.e. the async-await driver) will wrap the value in a promise using a similar algorithm to new Promise(r => r(value)) (note, not Promise.resolve, but that's not a big deal).
It then waits for the promise to resolve. If it fulfils, it passes the fulfilled value back.
If it rejects, it throws the rejection reason as an error.

In this Answer's Summary:

Utility of async-await is to use yield and unwrap the yielded value as a promise and pass it's resolved value back, repeating until the function returns its final value.

Now there's an another question: Is it possible to reset Generator?

Once a generator enters the "completed" state, it never leaves it and its associated execution context is never resumed. Any execution state associated with generator can be discarded at this point.