DEV Community: Vaibhav Gharge 👨🏻‍💻

Embracing Failure in Distributed Cloud Applications

Vaibhav Gharge 👨🏻‍💻 — Sat, 28 Mar 2020 05:55:44 +0000

This article was originally published on blog.vaibhavgharge.com

Building a reliable application in the cloud is different than building a reliable application in an enterprise setting. While historically you might have purchased higher-end hardware to scale up, in a cloud environment you must scale out instead. Costs for cloud environments are kept low through the use of commodity hardware. Instead of focusing on preventing failures and optimizing mean time between failures, in this new environment the focus shifts to mean time to restore.

The goal is to minimize the effect of a failure. Embrace the fact that failures will happen, and design to handle them.

Reasons for failures

Developer: Unhandled exception, caused by something the developer was not expecting and did not handle. The natural order of events is that the service logs the exception and terminates. The developer analyzes the logs, and takes corrective action in the code either to avoid the exception in the future, or to handle it more gracefully. This is an iterative process.
DevOps: Scaling down the number of service instances. When the orchestrator takes the instances down, it is possible that the instance being stopped cannot shut down in a graceful way, and the request it was processing might fail.
DevOps: Updating service code to a new version also might result in the instance not shutting down gracefully. A service instance might be processing a request at the time it is taken down for upgrade, resulting in that instance being processed again.
Orchestrator: Moving service code from one machine to another. The orchestrator's job is to make sure the service is up and running, and in doing so, it might decide to shut down an instance and move it to another piece of hardware.
Force majeure: Hardware failure, such as with the power supply, overheating fans, hard disk, network controller, router, or bad network cable, among others.
Force majeure: Datacenter outages due to natural disasters or attacks.

It's rare that an entire service or region will experience a disruption, but even those events must be planned for. When architecting applications for the cloud, you should:

Assume failures will happen and design for resiliency.
Avoid single points of failure through redundancy.

Assuming that failures will happen and that machines will go down, applications should not depend on a single machine to continue operating. A popular analogy used when describing how we should think about servers is the “pets vs. cattle” analogy—the notion of treating servers like cattle, not pets.

They are part of a herd, almost identical, and when they get sick, we replace them with another one instead of nursing them back to health. If any server in the organization is known by name and it routinely causes pain when it's down, then it's likely being treated like a pet.

During the design phase, you should perform a failure mode analysis (FMA). The goal of the FMA is to identify possible points of failure, and define how the application will respond to those failures.

How will the application detect this type of failure?
How will the application respond to this type of failure?
How will you log and monitor this type of failure?

Design self-healing applications

Design an application to be self-healing when failures occur. This requires a three-pronged approach:

Detect failures.
Respond to failures gracefully.
Log and monitor failures to give operational insight.

How you respond to a particular type of failure may depend on your application's availability requirements.

Recommendations

Retry failed operations: Transient failures might occur due to momentary loss of network connectivity, a dropped database connection, or a timeout when a service is busy. Build retry logic into your application to handle transient failures.
Protect failing remote services (circuit breaker design pattern): It's advisable to retry after a transient failure, but if the failure persists, you can end up with too many callers hitting a failing service. This can lead to cascading failures as requests back up. Use the circuit breaker design pattern to fail fast (without making the remote call) when an operation is likely to fail.
Isolate critical resources (bulkhead pattern): Failures in one subsystem can sometimes cascade. This can happen if a failure causes some resources, such as threads or sockets, from being freed in a timely manner, leading to resource exhaustion. To avoid this, partition a system into isolated groups, so that a failure in one partition does not bring down the entire system.
Perform load leveling: Applications may experience sudden spikes in traffic that can overwhelm services on the backend. To avoid this, use the queue-based load leveling pattern to queue work items to run asynchronously. The queue acts as a buffer that evens out peaks in the load.
Fail over: If an instance can't be reached, fail over to another instance. For things that are stateless, like a web server, put several instances behind a load balancer or traffic manager. For things that store state, like a database, use replicas and fail over. Depending on the data store and how it replicates, this might require the application to deal with eventual consistency.
Compensate for failed transactions: In general, avoid distributed transactions because they require coordination across services and resources. Instead, use compensating transactions to undo any step that already completed.
Use checkpoints on long-running transactions: Checkpoints can provide resiliency if a long-running operation fails. When the operation restarts (for example, it is picked up by another virtual machine), it can be resumed from the last checkpoint.
Degrade gracefully: Sometimes you can't work around a problem, but you can provide reduced functionality that is still useful. Consider an application that shows a catalog of books. If the application can't retrieve the thumbnail image for the cover, it might show a placeholder image. Entire subsystems might be noncritical for the application. For example, in an e-commerce site, showing product recommendations is probably less critical than processing orders.
Throttle clients: Sometimes a small number of users create excessive load, which can reduce your application's availability for other users. In this situation, throttle the client for a certain period of time. See the throttling pattern for more information.
Block bad actors: Just because you throttle a client, it doesn't mean the client was acting maliciously. It just means that the client exceeded its service quota. But if a client consistently exceeds their quota or otherwise behaves badly, you might block them. Define an out-of-band process for the user to request getting unblocked.
Use leader election: When you need to coordinate a task, use leader election to select a coordinator. That way, the coordinator is not a single point of failure. If the coordinator fails, a new one is selected. Rather than implement a leader election algorithm from scratch, consider an off-the-shelf solution such as Apache ZooKeeper.
Test with fault injection: All too often, the success path is well tested but not the failure path. A system could run in production for a long time before a failure path is exercised. Use fault injection to test the resiliency of the system to failures, either by triggering actual failures or by simulating them.
Embrace chaos engineering: Chaos engineering extends the notion of fault injection by randomly injecting failures or abnormal conditions into production instances.

Wrapping Up

Even today, the breakdown or ‘outage’ of a cloud service happens surprisingly frequently. When you are planning or developing a distributed application, it is a bad idea to assume attributes and qualities in your network that aren’t necessarily there: far better to plan on the assumption that your network will be costly, and will occasionally be unreliable and insecure.
Remember that (successful) applications evolve and grow so even if things look Ok for a while if you don't pay attention to the failures they will rear their ugly head and bite you.

Hope you find this article useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment and give few ❤️ 😊 Cheers. See you next time.

Deep Dive Angular: How to Make One Component Talk to Another

Vaibhav Gharge 👨🏻‍💻 — Sat, 08 Feb 2020 12:19:32 +0000

This article was originally published on blog.vaibhavgharge.com

Any Angular application is a tree of components. So when designing components, you need to ensure that they’re reusable and self-contained and at the same time
have some means of communicating with each other.

That is the goal of this article to explain how components can pass data to each other in a loosely coupled manner.

Let's dig in,

Parent to Child using the Input Decorator
Child to Parent via ViewChild
Child to Parent via Output and EventEmitter
Reactive Apporach to Share Data Between Any Components Using Services
Final Thoughts

The picture below depicts a typical UI composition where each shape represents a component. I have purposely avoided using HTML elements such as input fields, buttons for easier reference.

When you design a view that consists of multiple components, the less they know about each other, the better.

Say a user clicks the button in component 4, which has to initiate some actions in component 5. Is it possible to implement this scenario without component 4 knowing that component 5 exists? Yes, it is.

Parent to Child using the Input Decorator

The input properties of a component are decorated with @Input and are used to get data from the parent component.

When you declare a variable with the Input decorator in the child component, it allows that variable to be received from a parent template.

child.component.ts

import { NgModule, Component, Input } from '@angular/core';

@Component({
    selector: 'child-processor',
    template: `You have new message : {{infoMessage}}`,
    styleUrls: ['./child.component.css']
})
class ChildComponent {

    @Input() infoMessage: string;

    constructor() { }
}

In this case, we define a message variable in the parent, then use square brackets to pass the data to the child. Now the child can display this data in its template.

parent.component.ts


import { Component OnInit } from '@angular/core';

@Component({
    selector: 'parent-processor',
    template: ` <input type="text" placeholder="Enter Message" (change)="onInputEvent($event)"><br/>
                <child-processor [infoMessage]="message"></child-processor>
              `
    styleUrls: ['./parent.component.css'] 
})
class ParentComponent implements OnInit {

    message: string;

    constructor() { }
    ngOnInit() { }

    onInputEvent({target}) : void {
        this.message = target.value;
    }
}

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { BrowserModule } from '@angular/platform-browser';

@NgModule({
    imports: [ BrowserModule],
    declarations: [ ParentComponent, ChildComponent],
    bootstrap: [ ParentComponent ]
})
class AppModule { }
platformBrowserDynamic().bootstrapModule(AppModule);

Child to Parent via Output and EventEmitter

Angular components can dispatch custom events using the EventEmitter object. Those events can be handled either in the component or by its parent components.

This approach is ideal when you want to share data changes that occur on things like button clicks, form entries, and other user events.

In the child, we declare a messageEvent variable with the Output decorator and set it equal to a new event emitter. Then we can create a function named
sendMessage that calls emit on this event with the message we want to send to the child.

child.component.ts


import { Component, Output, EventEmitter } from '@angular/core';

@Component({
    selector: 'app-child',
    template: `<button (click) = "sendMessage()" class="button"> Send Message </button>`,
    styleUrls: ['./child.component.css']
})
class ChildComponent {

    message: string = 'Hello from child';

    @Output() messageEvent = new EventEmitter<string>(); // EventEmitter is 

    constructor() { }

    sendMessage() : void {
        this.messageEvent.emit(this.message);
    }
}

In the parent, we have created a function to receive the message and set it equal to the message variable which in turn will be displayed on UI.

The parent can now subscribe to this messageEvent that's outputted by the child component, then run the receive message function whenever this event occurs.

parent.component.ts

import { Component, OnInit } from '@angular/core';

@Component({
    selector: 'app-parent',
    template: ` <h1> Parent </h1>
                 Message from child : {{message}}
                <app-child (messageEvent)="receiveMessage($event)" ></app-child>
              `
    styleUrls: ['./parent.component.css'] 
})
class ParentComponent implements OnInit {

    message: string;

    constructor() { }

    ngOnInit() { }

    receiveMessage($event) : void {
        this.message = $event;        // So, every time button is clicked in child view, receiveMessage function will be invoked.
    }
}

Lastly, we create a button to trigger this function.

Child to Parent via ViewChild

ViewChild allows one component to be injected into another, giving the parent access to its attributes and functions.

One caveat, however, is that the child won't be available until after the view has been initialized. This means we need to implement the AfterViewInit lifecycle hook to receive the data from the child.

child.component.ts

import { Component } from '@angular/core';

@Component({
    selector: 'app-child',
    template: `<h1> Child </h1>`,
    styleUrls: ['./child.component.css']
})
class ChildComponent {

    childMessage: string = 'Hello from child';

    constructor() { }
}

In the AfterViewInit function, we can access the message variable defined in the child.

parent.component.ts

import { Component, AfterViewInit, ViewChild } from '@angular/core';

@Component({
    selector: 'app-parent',
    template: ` <h1> Parent </h1>
                 Message from child : {{message}}
                <app-child></app-child>
              `
    styleUrls: ['./parent.component.css'] 
})
class ParentComponent implements AfterViewInit {

    @ViewChild(ChildComponent) childComp : ChildComponent; // ViewChild returns the first element that matches a given component.

    message: string;

    constructor() { }

    ngAfterViewInit() : void {
        this.message = this.childComp.childMessage; // Here, We can access Child Property directly.
    }
}

One important thing to note here is that The @ViewChild decorator cannot see across component boundaries!

Queries done using @ViewChild can only see elements inside the template of the component itself.

It's important to realize that @ViewChild cannot be used to inject:

Anything inside the templates of its child components
and neither anything in the template of parent components as well

Reactive Approach to Share Data Between Any Components Using Services

You’ve learned how a parent component can pass data to its child using bindings to input properties and via @ViewChild decorator.

But there are other cases when passing data between components that have no direct connection, such as siblings, grandchildren, etc, you should use a shared service approach.

When you have data that should always be in sync, RxJS BehaviorSubject comes handy in this situation. The major advantage that a BehaviorSubject ensures that every component consuming the service receives the most recent data. If you would like to know more about Subjects in RxJS head over to my article on Reactive Programming - The best idea from Observer pattern, the Iterator pattern and Functional programming.

So in the service, we need to create a private BehaviorSubject that will hold the current value of the message.

Then We define a currentMessage variable handle this data stream as an observable that will be used by the components.

Lastly, we create function that calls next on the BehaviorSubject to emit the value.

data.transfer.service.ts

import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable()
export class DataTransferService {

  private messageSubject = new BehaviorSubject('default message');
  currentMessage = this.messageSubject.asObservable();

  constructor() { }

  sendMessage(message: string) {
    this.messageSubject.next(message);
  }
}

In parent, we simply subscribe to the Observable from DataTransferService.

parent.component.ts


import { Component, OnInit } from '@angular/core';
import { DataTransferService } from "../data.service";

@Component({
  selector: 'app-parent',
  template: `{{message}}`,
  styleUrls: ['./parent.component.css']
})
export class ParentComponent implements OnInit {

  message:string;

  constructor(private dataTransferService: DataTransferService) { }

  ngOnInit() {
    this.dataTransferService.currentMessage.subscribe(message => this.message = message)
  }

}

Now if we create a function in any one of these components that changes the value of the message. When this function is executed the new data it's automatically broadcast to all other components.

second.child.component.ts


import { Component, OnInit } from '@angular/core';
import { DataTransferService } from "../data.service";

@Component({
  selector: 'app-sibling',
  template: ` {{message}}
    <button (click)="newMessage()"> New Message </button>
  `,
  styleUrls: ['./second.child.component.css']
})
export class SecondChildComponent implements OnInit {

  message:string;

  constructor(private dataTransferService: DataTransferService) { }

  ngOnInit() {
    this.dataTransferService.currentMessage.subscribe(message => this.message = message);
  }

  newMessage() {
    this.dataTransferService.sendMessage("Hello from 2nd Child"); // All those components who have subscribed will receive the message.
  }

}

The parent, child, and sibling components all receive the same treatment. We inject the DataTransferService in the constructor, then subscribe to the
currentMessage observable and set its value equal to the message variable.

Final Thoughts

You have learned about binding to the component’s input properties and dispatching events via the output properties allow you to create loosely coupled components.
You have learned that @ViewChild which not only allows us to pass the data from parent to child but also can let parents use the API exposed by the child.
You have also learned about communications between unrelated components can be arranged by using the reactive shared services approach.
Finally, you learned that when you design a component-based UI, each component should be self-contained, and components shouldn’t rely on the existence of other UI components.

Hope you find this post useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment and give a few ❤️ 😊 Cheers. See you next time.

Reactive Angular : Understanding AsyncSubject, BehaviorSubject and ReplaySubject

Vaibhav Gharge 👨🏻‍💻 — Sat, 11 Jan 2020 11:54:27 +0000

This article was originally published on blog.vaibhavgharge.com

To understand various Subjects in RxJS, we first need to know the fundamentals and different aspects of “Reactive Programming”.

What is Reactive Programming in the first place?

The term, “reactive,” is a general programming term that is focused on creating responsive (fast) event-driven applications, UI controllers reacting to mouse events, where an observable event stream is pushed to subscribers.

In short, non-blocking is reactive, because, instead of being blocked, we are now in the mode of reacting to notifications as operations complete or data becomes available.

One of the most important characteristics of Reactive Programming is that it allows us to implement the Push Model of data processing.

In contrast, the Pull Model is implemented by looping through an array, by an Iterable, or by using ES6 generator functions.

To get an in-depth understanding of reactive programming paradigm, head over to my other post
Reactive Programming - The best idea from Observer pattern, the Iterator pattern and Functional programming

Lets continue with,

What are Observables and Observers?
Observables vs Promises
What are Subjects
Parting Thoughts

What are Observables and Observers?

An observer is an object that handles a data stream pushed by an observable function.

There are two main types of observables: hot and cold.

A cold observable starts streaming data when some code invokes a subscribe() function on it.
A hot observable streams data as soon as it is created, even if there’s no subscriber interested in the data.

An observable is an object that streams elements from some data source (a socket, an array, UI events) one element at a time. An observable stream knows exactly how to do three things:

Emit the next element from the source towards Observers
Throw an error to indicate Observers, so that errors can be handled gracefully.
Send a signal that the streaming is over (that the last element has been served)

To handle the above actions, an observer object provides up to three callbacks:

A function to handle the next element emitted by the observable
A function to handle errors in the observable
A function to be invoked when the stream of data completes

In short, An observable object is a more advanced version of an iterator. Iterators use the pull model to retrieve the data, whereas observables push the data to subscribers.

Observables vs Promises

Both Promises and Observables provide us with abstractions that help us deal with the asynchronous nature of our applications.
However, there are important differences between the two:

Observables can define both the setup and teardown aspects of asynchronous behavior.
Observables are cancellable.
Observables can be retried using one of the retry operators provided by the API, such as retry and retryWhen. On the other hand, Promises require the caller to have access to the original function that returned the promise to have a retry capability.

What are Subjects?

A Subject is a special type of Observable that allows values to be multicasted to many Observers. Subjects are like EventEmitters.

Every Subject is an Observable and an Observer. What does that mean? It means that a subject can emit data, on top of having the capability to be subscribed to.
You can subscribe to a Subject, and you can call next to feed values as well as error and complete.

A regular observable does not have the next() method as regular observables are not observers. So that’s the first distinctive capability of a subject: Data emission.

AsyncSubject
BehaviorSubject
ReplaySubject

AsyncSubject

A variant of Subject that works differently than BehaviorSubject/ReplaySubject as both of them store values.
However former will emit its latest value to all its observers only upon completion.


import { AsyncSubject } from 'rxjs';

export class StockService {

    stockSubject;

    constructor() {
        this.stockSubject = new AsyncSubject();
    }

    public performOperation() {

        stockSubject.next(100); // This value is never received by Observers.
        stockSubject.next(101); // This value is never received by Observers.
        stockSubject.next(102); // This value is never received by Observers.

        stockSubject.subscribe(sharePrice => {
            console.log('1st Trader:', sharePrice);}
        );

        stockSubject.next(103);

        stockSubject.subscribe(sharePrice => {
            console.log('2nd Trader:', sharePrice);
        });

        stockSubject.complete(); // Last value gets pushed to Observers i.e 103.
    }
}

And the output:

1st Trader: 103
2nd Trader: 103

BehaviorSubject

A variant of Subject that requires an initial value and emits its current value whenever it is subscribed to.

Behavior subjects are similar to replay subjects, but will re-emit only the last emitted value, or a default value if no value has been previously emitted.


import { BehaviorSubject } from 'rxjs';

export class StockService {

    stockSubject;

    constructor() {
        this.stockSubject = new BehaviorSubject(0);
    }

    public performOperation() {

        stockSubject.subscribe(sharePrice => {
            console.log('1st Trader:', sharePrice);} // Immediately receives initial value as that is the last value.
        );

        stockSubject.next(100);

        stockSubject.subscribe(sharePrice => {
            console.log('2nd Trader:', sharePrice); // Does not receives initial value as last emitted value is 100.
        });
    }
}

And the output:

1st Trader: 0
1st Trader: 100
2nd Trader: 100

ReplaySubject

A variant of Subject that "replays" or emits old values to new subscribers. It buffers a set number of values and will emit those values immediately to any new subscribers in addition to emitting new values to existing subscribers.


import { ReplaySubject } from 'rxjs';

export class StockService {

    stockSubject;

    constructor() {
        this.stockSubject = new ReplaySubject(2); // No of values to be buffered.
    }

    public performOperation() {

        stockSubject.next(100);
        stockSubject.next(101);
        stockSubject.next(102);

        stockSubject.subscribe(sharePrice => {
            console.log('1st Trader:', sharePrice);} // Receives last 2 values only.
        );

        stockSubject.next(103);

        stockSubject.subscribe(sharePrice => {
            console.log('2nd Trader:', sharePrice); // Receives last 2 values only.
        });
    }
}

And the output:

1st Trader: 101
1st Trader: 102
1st Trader: 103
2nd Trader: 102
2nd Trader: 103

Parting Thoughts

You have learned what an Observable is — An object that emits or publishes values over time and asynchronously.
You learned about cold and hot Observables — hot refers to when the Obseravble starts publishing values when it’s created even before getting any subscriptions.
We also learned about special types of Observables such as Subjects, AsyncSubject, BehaviorSubject, and ReplySubject.

Hope you find this post useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment and give a few ❤️ 😊 Cheers. See you next time.

Making life easier with Angular Reactive Forms

Vaibhav Gharge 👨🏻‍💻 — Sat, 21 Dec 2019 11:33:17 +0000

This article was originally published on blog.vaibhavgharge.com

Angular offers rich support for handling forms. It goes beyond regular data-binding by treating form fields as first-class citizens and providing fine-grained control over form data.

If you’re familiar with Angular in general and forms in particular, you probably know that there are two different ways to manage forms with Angular: template-driven and reactive.

These two approaches are exposed as two different APIs (sets of directives and TypeScript classes) in Angular. We are interested in understanding the reactive approach.

So Let's explore,

An angular App is a Reactive App
Understanding Building Blocks of Angular Forms API (FormControl, FormGroup, AbstractControl, FormArray, FormBuilder)
Watching changes to the state and being Reactive
Implementing Reactive Form using FormGroup and FormControl
Key Differences Between Reactive Forms and Template-Driven Forms
Parting Thoughts

An angular App is a Reactive App

In short, non-blocking is reactive, because, instead of being blocked, we are now in the mode of reacting to notifications as operations complete or data becomes available.

One of the most important characteristics of Reactive Programming is that it allows us to implement the Push Model of data processing.

In contrast, the Pull Model is implemented by looping through an array, by an Iterable, or by using ES6 generator functions.

Working with Forms (FormControl, FormGroup, AbstractControl, FormArray, FormBuilder)

Let’s break it down.

Creating a FormControl

FormControl is a class that powers an individual form control, tracks the value and validation status, whilst offering a wide set of public API methods. Represents a single input field - it is the smallest unit of an Angular form.

Let's consider an example where we are setting up the Reactive form using the form model FormControl instance.


<input type="text" name="userInput" pInputText formControlName="userInput"  maxlength="10">


FormControl someFormControlOne = new FormControl(formState, validatorOrOpts, asyncValidator);

Where,

formState -> Initializes the control with an initial value or an object that defines the initial value and disabled state.
validatorOrOpts -> A synchronous validator function, or an array of such functions.
asyncValidator -> A single async validator or array of async validator functions.

Each form field should have a formControlName directive in the template with a value that will be the name used in the component class for referring to that field.

There are four possible validation status values for a FormControl:

VALID: This control has passed all validation checks.
INVALID: This control has failed at least one validation check.
PENDING: This control is in the midst of conducting a validation check.
DISABLED: This control is exempt from validation checks.

These status values are mutually exclusive, so control cannot be both valid and invalid or invalid and disabled at the same time.

Creating a FormGroup

Most forms have more than one field, so we need a way to manage multiple FormControls. That's what exactly FormGroup provides. It usually represents a part of the form and is a collection of FormControls. FormGroup aggregates the values and the statuses of each FormControl in the group. If one of the controls in a group is invalid, the entire group becomes invalid. It’s convenient for managing related fields on the form.

Here's how you create a FormGroup:


this.someFormGroup = new FormGroup({
        someFormControlOne: new FormControl('', []),
        someFormControlTwo: new FormControl('', [])
    });

What's inside AbstractControl?

Both the FormGroup and FormControl inherit from AbstractControl, which has lots of interesting properties, that allows Angular to render the UI differently, based on the status of FormControl.

dirty: A control is dirty If the user has changed the value in the UI.
touched: A control is marked touched once the user has triggered a blur event on it.
untouched: A control is untouched If the user has not yet triggered a blur event on it.
valueChanges: A multicasting observable that emits an event every time the value of the control changes, in the UI or programmatically.
statusChanges: A multicasting observable that emits an event every time the validation status of the control recalculates.

Using FormArray

FormArray is similar to FormGroup, but it has a variable length. Whereas FormGroup represents an entire form or a fixed subset of a form’s fields, FormArray
usually represents a growable collection of fields.

In short, we can use FormArray to create a form of variable or unknown length. Let us assume that we need to create an account registration form, which will have two fields for an bankAccountType and a bankAccountCode.


// FormArray can contain both FormGroup and FormControl.

this.formArrays = new FormArray([
                        new FormGroup({
                            bankAccountType: new FormControl('', [Validators.required]),
                            bankAccountCode: new FormControl('', [Validators.required])
                        }),
                        interestType: new FormControl('Simple', []),
                ])

Declarative approach with FormBuilder

The FormBuilder class provides a simpler API to deal with control groups.

FormBuilder is part of ReactiveFormsModule, to use you will need to inject FormBuilder instance in your component. In Angular, the simplest way to accomplish this is by listing it as a typed constructor parameter.


export class LoginComponent implements OnInit {

    constructor(
    private formBuilder: FormBuilder // FormBuilder instance created and set by Angular, through a technique called Dependency Injection.
    ) { }

    ngOnInit() {
        this.loginForm = this.formBuilder.group({
          usernameString: ['', Validators.required], // note that we no more need to use FormControl specifically.
          passwordString: ['', Validators.required]
        });
  }
}

To get in-depth understanding of declarative programming paradigm, head over to my another post Imperative vs Declarative programming. Your enemy is not object-oriented programming

Watching State Changes and Being Reactive

Let's see a simple demonstration of how we can use valueChanges Observable. So every time the user enters the userName, it will be checked for availability with backend.


this.sampleForm.get('userName').valueChanges.subscribe(
            (userName) => {
                userService.validateUserName(userName);
            }
         );

Ideally, we shouldn't be invoking backend calls for every letter user typed. Hence the RxJS operator like debounce comes in handy for such scenarios, which deserves a post on its own.

Implementing Reactive Form using FormGroup and FormControl.


<form [formGroup]="bankDetailsForm">
    <div>
       "Bank Code"
       <div>
          <input type="text" name="bankCode" pInputText formControlName="bankCode"  maxlength="4">
       </div>
       "Bank Account No"
       <div>
          <input type="text" name="bankAccountNo" pInputText formControlName="bankAccountNo"  maxlength="20">
       </div>
    </div>
</form>


import { Component, OnInit } from '@angular/core';
import { FormControl, FormGroup, Validators } from '@angular/forms';

@Component({
  selector: 'display-bank-account-details',
  templateUrl: './display-bank-account-details.component.html',
  styleUrls: ['./display-bank-account-details.component.css']
})
export class DisplayBankAccountDetailsComponent implements OnInit {

  constructor(private formBuilder: FormBuilder) {}
  bankDetailsForm: FormGroup;

  initFormControls(): void {
    this.bankDetailsForm = new FormGroup({
        bankCode: new FormControl('', [Validators.required]), // Creates new FormControl instance which will be tracked by Angular.
        bankAccountNo: new FormControl('', [Validators.required]) // Creates new FormControl instance which will be tracked by Angular.
    });
  }

  init(): void {
    this.initFormControls();
  }

  ngOnInit() {
    this.init();
  }
}

To enable reactive forms, add ReactiveFormsModule from @angular/forms to the imports list of the NgModule that uses the Forms API.


import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { ReactiveFormsModule } from '@angular/forms';

@NgModule({
    imports : [ BrowserModule, FormsModule, ReactiveFormsModule ],
    declarations: [ AppComponent ],
    bootstrap : [ AppComponent ]
})

class AppModule {}
platformBrowserDynamic().bootstrapModule(AppModule);

Key Differences Between Reactive Forms and Template-Driven Forms

Reactive forms are synchronous in nature, whereas template-driven forms are asynchronous.
The data model in reactive forms is more structured than template-driven forms.
Form validations in reactive forms are handled through functions, whereas in template-driven forms they are handled through directives.
Reactive forms are immutable in nature, whereas template-driven forms are mutable.
Reactive forms are more explicit and created in the component class and template-driven forms are less explicit and created by directives.

Parting Thoughts

You have learned what a Reactive approach is — An object that emits or publishes values over time and asynchronously. In a reactive approach, you create the form model programmatically in the code (in TypeScript, in this case). The template can be either statically defined and bound to an existing form model or dynamically generated based on the model.
Forms have a lot of moving parts, but Angular makes it fairly straightforward. Once you get a handle on how to use FormGroups, FormControls, and Validations, it's pretty easy going from there!

Hope you find this post useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment and give a few ❤️ 😊 Cheers. See you next time.

A Quick Look at React's useContext() Hook

Vaibhav Gharge 👨🏻‍💻 — Sat, 14 Dec 2019 16:19:04 +0000

This article was originally published on blog.vaibhavgharge.com

I’ve always been fascinated with the idea of web application development. Building web apps was one of the reasons I wanted to learn how to code.
This fascination led me down many paths, from Java to JavaScript to Angular and now to React.

When it comes to React development, there are some things that are good to know and some things that we need to know to embark on our great journey.

One of the things that is good to know is hooks in React and specifically useContext() hook which makes using contexts in react a lot easier.

Hooks are functions that let you “hook into” React state and lifecycle features from function components. Hooks don’t work inside classes — they let you use React state and other features via functions, without classes

Let’s forget the hype around React and focus on what this post should do for you. My primary hope for this article is that it equips you to understand and work with React
useContext hook effectively.

Let's take a closer look at,

What and Why of React's Context API
Using Contexts before the Introduction of Hooks
Why using useContext() hook is a cleaner way of using contexts in React than Context APIs
Wrapping Up

What and Why of React's Context API

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

In any typical react based application, data is passed from parent to child using props

Consider, a react application, which has many nested components. We have at root the AppComponent and nested within the AppComponent, at different levels we have several other components.

At the first level, we have Component A, which in turn has nested Components B, C, D, and F. Furthermore, we have Component B which is nested within Components E
and G.

Suppose, we have a requirement to display logged in User's ID inside Component G and F which is maintained as a property inside AppComponent.

To successfully able to display the userID in Component G and F, using traditional React approach, we will have to pass the property information all the way down
the Component tree as a prop.

So for Component G to display the userId, the prop has to be passed through Component A, B and E.

As you might have already noticed, even though components A, B, and E has do not need the userId prop, they still have to act as a mediator to pass the prop down to their children.

In typical real-world applications, components may be nested up to 5 or 10 levels deep. Cluttering those components is definitely not a good web development practice.

So to overcome such cross-cutting concerns so that data can be sent directly to the required component without the hassle of sending it through the tree, the team at react has released a new set of APIs called Context API in React v16.3.0.

Using Contexts Before the Introduction of Hooks

To use context before the release of hooks, we usually implemented it by following these 3 steps:

We will create a Context, using React's createContext() method.
We will use the Provider in the high-level component to provide the Context Value.
We will then Consume the Context value using render props pattern.

app.js


import React from 'react'
import './App.css'
import ComponentA from './components/ComponentA'

export const UserContext = React.createContext()
export const StatusContext = React.createContext()

function App() {
    return (
        <div className="App">
            <UserContext.Provider value={'Vaibhav'}>
                <StatusContext.Provider value={'Focusing'}>
                    <ComponentA />
                </StatusContext.Provider>
            </UserContext.Provider>
        </div>
    )
}

export default App

ComponentA.js


import React from 'react'
import ComponentF from './ComponentF'

function ComponentA() {
    return <ComponentF />
}

export default ComponentA

ComponentF.js


import React from 'react'
import { UserContext, StatusContext } from '../App'

function ComponentF() {
    return (
        <div>
            <UserContext.Consumer>
                { userId => {
                    return (
                        <StatusContext.Consumer>
                            { status => {
                                return <div> User context value {userId}, 
                                             Status context value {status}
                                      </div>
                                }
                            }
                        </StatusContext.Consumer>
                    )
                  }
                }
            </UserContext.Consumer>
        </div>
    )
}

export default ComponentF

Using Contexts After the Introduction of Hooks. It's a cleaner way of using contexts in React than Context APIs

Now, as you have seen using Context API, makes the creation of context quite easier. However, we still needs to use Context.Consumer to consume the context value.

As you might think, having multiple contexts, going to difficult consuming those values.

In such scenarios, React's useContext() hook comes handy as it makes consumption of Context values a lot easier and clean.

There are 3 simple steps to consume context using useContext() hook:

We need to import the useContext from react.
Import the required contexts. In our example, UserContext and StatusContext.
Finally, we call the useContext() function passing UserContext and StatusContext as arguments.

UserContext will return the context value that is nothing but userId. Whereas StatusContext will return the status of the user. So once fetched those values, we can straight away use it to display on the UI.

ComponentG.js


import React, { useContext } from 'react'
import { UserContext, StatusContext } from '../App'

function ComponentG() {

  const userId = useContext(UserContext)
  const status = useContext(StatusContext)
  return <div> User is {userId} and Status is {status}</div>
}

export default ComponentG

Wrapping Up

You have learned what a React context API is and with React, now you don't have to differentiate between "is it a class?" or "should I use a functional component?" Also, Hooks let us organize the logic inside a component into reusable isolated units.
Unlike patterns such as to render props and higher-order components, Hooks don’t introduce unnecessary nesting into your component tree. They also don’t suffer from the drawbacks of mixins.
You have also learned that using context hooks, makes consumption of the context much easier and giving you a lot of cleaner code. You'll end up using React's hook every single day of your React development, a great addition to the library.

Hope you find this article useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment and give a few ❤️ 😊 Cheers. See you next time.

The Complete Guide to Destructuring in JavaScript

Vaibhav Gharge 👨🏻‍💻 — Sun, 08 Dec 2019 07:19:15 +0000

This article was originally published on blog.vaibhavgharge.com

Object and array literals are two of the most frequently used notations in JavaScript, and thanks to the popular JSON data format, they have become a particularly
an important part of the language.

The goal of this article is to define and clarify the different aspects of “Destructuring in JavaScript”.

Lets take a closer look at,

What and Why of Destructuring?
Array Destructuring
Object Destructuring
Parting Thoughts

What and Why of Destructuring?

Destructuring is an elegant way to extract data from arrays and objects.

ECMAScript 6 simplifies the task of systematically pulling out relevant pieces of information from structures such as arrays and objects by adding destructuring, which is the nothing but a process of breaking down a data structure into smaller parts.

The need to fetch information from objects and arrays could result in a lot of duplicate code to get certain data into local variables.

For example:

before-destructuring.js


let userDetails = {
    userHasSubscribed: true,
    userLoggedIn: false
};

// extract values from the object

let userHasSubscribed = userDetails.userHasSubscribed,
let userLoggedIn = userDetails.userLoggedIn;

As you can see, this piece of code extracts the values of userHasSubscribed and userLoggedIn from the userDetails object, and stores that data in local variables with the same names in order to be used further.

What if you had a large number of variables to assign, you would have to assign them all one by one. Even the worst thing is that if you have nested data structure, where you might have to dig through the entire structure just to find one piece of data.

That’s the sole purpose why ES6 has added Destructuring for objects and arrays. When you break down a data structure into smaller parts, getting the information
you need from it becomes much easier.

The notation takes a bit of getting used to, but soon you’ll be quite comfortable making use of it in your own code.

Array Destructuring*

In a typical javascript application, functions usually return a single value: a primitive or an object. There is no elegant way to return multiple values other than returning an array.

That makes the code within function easy to comprehend, but on the receiving end, it is much messier to handle.

Let’s take a look at an example.

array-destructuring.js


const getUserNameById = function(id) {
    return ['Kent', 'Bob', 'Victor'];
};


const userNamById = getUserNameById('@kent_Victor');

const userFirstName = userNamById[0];
const userMiddleName = userNamById[1]
const userLastName = userNamById[2];

The function getUserNameById() returns the first name, the middle name, and the last name for a user at a given userId.

Wouldn't it be nice to assign the result to variables like firstName and lastName directly? without having to use the index operator.

That's what exactly Destructuring makes possible.

array-destructuring.js


let [firstName, middleName, lastName] = getUserNameById('@kent_Victor');

As you have seen, we do not need to fetch values from an array based on index. Moreover, allowing us to assign the values straight away to the variables:
firstName, middleName and lastName.

Different ways of extracting values

Fewer values

If we want only the first name and not the other details, we would gently extract only the first name, like so:


let [firstName] = getUserNameById('@kent_Victor');

Ignoring values

We can even ignore the middle name and extract only the first and last names like this:


let [firstName, , lastName] = getUserNameById('@kent_Victor'); // Extract only firstName and lastName

let [, , lastName] = getUserNameById('@kent_Victor');// Extract only lastName

As you have seen examples of extracting all the values and also extracting fewer values than available. However, JavaScript even allows us to extract more values than what's available in the array.

Extracting more than what's available


let [firstName, , lastName, userName] = getUserNameById('@kent_Victor'); // Extract only firstName, lastName and userName with value 'undefined'

Using Rest Operator to Extract Values

If we need to use just one or more variables but don’t want to lose the rest of the values, we can gather them into an array using the ... rest operator.


// Extract only firstName and variable otherName will contain remaining values from the array.

let [firstName, ...otherName] = getUserNameById('@kent_Victor');

Passing default values

As you can see, there is no destructuring for userName variable as there is no 4th value available inside array. However, we can assign a default value to userName.


// Extract firstName, middleName, lastName along with userName with default value.

let [firstName, middleName, lastName, userName = "Kent Victor"] = getUserNameById('@kent_Victor');

Object Destructuring

Object destructuring provides an elegant way to extract data from objects into variables in local or lexical scope.

Let’s extract the data from an object using non-destructuring way first and then see how object destructuring makes things easier.

Using a similar example as previously, let's just convert the array to an object that holds the details of a user.

object-destructuring.js


let userDetails = {
    firstName: 'Kent',
    middleName: 'Bob',
    lastName: 'Victor',
    address: { street: '909 Holly St.'}
} 

const firstNameOfUser = userDetails.firstName;
const middleNameOfUser = userDetails.middleName;
const lastNameOfUser = userDetails.lastName;

As you can see, we just need to extract the user's first name, middle name, and last name. But that took a couple of lines and an invocation of the dot notation—that’s rather verbose.

Destructuring can reduce a lot of that unwanted code.

object-destructuring.js


let userDetails = {
    firstName: 'Kent',
    middleName: 'Bob',
    lastName: 'Victor',
    address: { street: '909 Holly St.'}
} 

const { firstName: firstNameOfUser, middleName: middleNameOfUser , lastName: lastNameOfUser } = userDetails;

Extracting to Variables with the Same Name


const { firstName, middleName, lastName} = userDetails;

Assigning Default Values

When extracting, if a property we wanted does not exist in the object, we can assign a default value for the missing property.


const { firstName, middleName, lastName, age = 25} = userDetails; // age will be assigned with default value of 25

Extracting When Passing Object to a Function

Let’s create a function that receives the user object and logs the first name, middle name, and last name.


const logInfo = function(userDetails) {
    console.log(`${userDetails.firstName} ${userDetails.middleName} ${userDetails.lastName}`);
};

logInfo(userDetails);

This is a traditional way of handling object parameters to a function.

Using the object destructuring syntax, we can straightaway declare parameter with object value extraction. Let’s rewrite the logInfo() function to use object destructuring.


const logInfo = function({ firstName, middleName, lastName}) {
    console.log(`${firstName} ${middleName} ${lastName}`);
};

logInfo(userDetails);

Nested Object Destructuring

So far in the examples, we extracted the top-level properties of objects. The destructuring syntax makes it easy to extract properties in lower levels or embedded objects as well. Let’s extract the street property of the address embedded object in userDetails.


const { firstName, address: { street } } = userDetails;

As we saw before, the firstName property, which is a top-level property, is extracted. Besides, the street property that is nested within the address property is also being
extracted.

As we can see, these changes allow us to extract properties of the nested object then we can access firstName and street, but any attempt to access the address object will result in a “variable not defined” error.

Extracting into Existing Variables

So far, we’ve extracted properties from objects into new variables, which are defined using const or let. However, We are not limited to extracting into new variables. We can even destructure an object and assign it to existing variables in local or lexical scope.


let firstNameOfUser = 'NA';
let lastNameOfUser = 'NA';

({ firstName : firstNameOfUser,  lastName : lastNameOfUser } = userDetails);

To avoid SyntaxError: Unexpected token =, All we've to wrap the extraction code inside a pair of (). The semicolon should be outside the ().

Parting Thoughts

You have learned that Destructuring makes working with objects and arrays in JavaScript a lot easier.
You'll end up using JavaScript's destructuring many a times, a great feature of the language, makes extracting data from arrays and objects pretty darn easy.
You have seen that both object and array destructuring can specify default values for any property or item that is undefined, and both throw errors when the right side of an assignment evaluates to null or undefined.

Hope you find this article useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment and give a few ❤️ 😊 Cheers. See you next time.

Everything you need to know about the fundamentals of Callbacks in JavaScript

Vaibhav Gharge 👨🏻‍💻 — Tue, 03 Dec 2019 04:29:42 +0000

This article was originally published on blog.vaibhavgharge.com

The goal of this article is to define and explore the callbacks as an asynchronous programming construct. As we all know, JavaScript is a popular language for developing web applications and is increasingly used for both client-side and server-side application logic.

The JavaScript runtime is inherently event-driven and callbacks are a key language feature. Since JavaScript is single-threaded, any long-running operations are blocking. JavaScript uses events to handle these blocking operations.

Lets take a closer look at,

What are Callbacks in Javascript?
Building Callbacks
Issues with Callbacks
Fixing Callback Hell
Parting Thoughts

What are Callbacks in Javascript?

Callbacks are the most basic form of JavaScript Asynchronous Programming. In simple words, a callback is a function that gets invoked after another function completes.

In JavaScript, functions are treated as objects which allow them to be passed around as arguments, returned by functions and stored into variables. A callback is a function object which can be passed as an argument into a Higher Order Function. HOF are functions that accept functions as arguments and can return a function as a result.

Any function that does not return instantaneously should be asynchronous. The traditional approach to designing asynchronous functions relied heavily on callbacks.

Programming with callbacks is especially useful when a caller does not want to wait until the callee completes. To this end, the desired non-blocking operation is scheduled as a callback and the main thread continues its synchronous execution.

Let’s take a look at a small example and discuss how to build callbacks.

Building Callbacks

The first thing we need to know that, Callbacks in JavaScript follow an unofficial convention. A callback may take in as many arguments as needed or specified by the Higher-Order Function, but the first argument should be the error object. Again this no hard and fast rule, this is just a convention followed by nearly every API in existence.

understand-callbacks.js


let https = require('https');

let make_request = function(url, callback) {

  var options = {
    host: this.host,
    path: url,
    method: 'post'
  };

  var req = https.request(options, function(res) {

    var buffer = '';

    res.on('data', function(data) {
      buffer += data;
    });

    res.on('end', function() {
      if (res.statusCode !== 200) {
        var message;

        try {
          message = JSON.parse(buffer);
        } catch(e) {
          message = buffer;
        }

        return callback('Error : ' + res.statusCode); // callback is invoked with error.
      }

      try {
        var json = JSON.parse(buffer);
      } catch (err) {
        return callback(err);  // callback is invoked with error.
      }

      callback(null, json); // callback is invoked with no error.

    });

  });

  req.on('error', function(err) {
    callback(err);  // callback is invoked with error.
  });

  req.end(data);
}

let callback = function (error, data) {

    if(error){
        console.log('Error Occured');
    }

    if(data){
        console.log('Request Successful');
    }
}

make_request('https://www.example.net/api/v1/sample/', callback);

As you can see when we have written a function called request that takes two arguments: URL, callback.
We then make an HTTP request to provided URL using post method.
Once the request is successful, we invoke the callback provided with null as the first argument (as there is no error) and data received is passed as the second argument.
However, that's not the case all the time, in real life response from API may throw an error. To handle this we are invoking the callback with an error as a first argument.

Let's see what can go wrong when using callbacks.

Issues with Callbacks

Callbacks are easy to use and serve their purpose well, but there are a few issues to consider when using callbacks. The two most common issues are Callback Hell and Callback Existence Assumption.

Callback Hell

Developers often need to combine several callback-accepting functions together to achieve a certain task. For example, two callbacks have to be nested if the result of
the first callback needs to be passed into the second callback in a non-blocking way. This structure becomes more complex when the callbacks need to be conditionally nested.


    getData(function(a) {
      getMoreData(a, function(b) {
        getMoreData(b, function(c) {
          getMoreData(c, function(d) {
            getMoreData(d, function(e) {
              // ...
            })
          })
        })
      })
    })

Callback Existence Assumption

It is always wise to check that the callback function passed in the parameter is indeed a function before calling it. Without the check in place, if the callback function is called either without the actual function as a parameter or in place of a function a non-function is passed, our code will result in a runtime error.


function make_request (url, data, callback) {
  // what happens if callback passed as an argument is not a function.
}

To summarize, callback problems comes from the fact that callbacks:

Don’t compose easily for multiple levels of callbacks.
This leads to code that is not extensible.
Inconsistency between the order of parameters.
Lacks, inbuilt error handling.

Fixing Problems Associated with "using Callbacks"

Callback hell can be easily avoided with two tricky ways: Named Functions and Modules.

Fixing Callback Hell using Named Functions

A name function is nothing but a function defined and assigned to a variable. So using named function instead of nested callbacks prevents our code from cluttering. Named callbacks can be reused and are easily identified in stack traces or breakpoints during debugging activities.

In Our initial example, we are already having a callback defined as named function to make it easily readable.


let callback = function (error, data) {
    // same as previously defined.
}

function make_request (url, data, callback) {
    // callback here is a named function passed as an argument
}

Separate your code into modules, so you can export a section of code that does a particular job. Then you can import that module into your larger application.

Fixing Callback Existence Assumption

To overcome this problem, considering back the same example, We first check that callback provided is not null and it is a valid function using typeof operator.

understand-callbacks.js


function make_request (url, data, callback) {

  if(!callback || !( typeof callback === 'function' )){
    throw new Error('Provided Callback is not a function. Please provide a function.');
  }

  // remaining part is same as above.
}

To summarize, problems with callbacks can substantially be reduced if We:

Don't nest functions. Give them names and place them at the top level of your program
Handle every single error in every one of your callbacks.
Create reusable functions and place them in a module to reduce the cognitive load required to understand your code. Splitting your code into small pieces like this also helps you handle errors, write tests, forces you to create a stable and documented public API for your code, and helps with refactoring.

And of course, you can always choose to ignore all of this callback stuff and go fall in love with promises. Promises are a JavaScript language extension. A Promise based function takes some input and returns a promise object representing the result of an asynchronous operation. But that deserves it's whole other post entirely :)

Parting Thoughts

You have learned what a Callback is and why Callback is the most basic form of Asynchronous Programming in JavaScript. Unfortunately, callbacks induce a non-linear control flow and can be deferred to execute asynchronously, declared anonymously, and may be nested to arbitrary levels.
We have seen an example that takes a callback as an input argument which is invoked depending upon the state of execution of the HOF.
You have also learned how to avoid callback issues by gracefully defining named functions. However naming causes the callback function to persist in memory and prevents it from being garbage collected. On the other hand, anonymous callbacks are more resource-friendly because they are marked for garbage collection immediately after being executed. However, anonymous callbacks are not reusable and may be difficult to maintain, test, or debug and checking for the existence of the callback function.
You'll end up seeing Callbacks in a lot of legacy libraries. So It's absolutely important to understand how callback works.

Hope you find this article useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment. See you next time.

Understanding Prototypal Inheritance in JavaScript : Part 1

Vaibhav Gharge 👨🏻‍💻 — Sun, 01 Dec 2019 04:26:46 +0000

This article was originally published on blog.vaibhavgharge.com

When it comes to JavaScript development, there are some things that are good to know and some things that we need to know to embark on our great journey.
One of the things that you should know is a prototypal inheritance.

The goal of this article is to define and clarify the different aspects of “Prototypes in JavaScript”.

Lets take a closer look at,

What are Javascript Objects
What's a prototype? and how to create one?
How does it work?
Gets are deep, but sets are always shallow
Difference between prototype, getPrototypeOf and _proto_
Parting Thoughts

What are Javascript Objects

Objects are JavaScript's fundamental data structure. Like many other languages, JavaScript provides support for implementation inheritance: the reuse of code or data structure through a dynamic delegation mechanism.

However, unlike many other conventional languages, JavaScript's inheritance mechanism is based on prototypes rather than classes.

In many languages, for example, Java every object is nothing but an instance of pariticular class, which provides code shared between all of its instances and inheritance provided by such languages is very static, you cannot do something that you can with aggregates.

On the other hand, JavaScript has no built-in notion of classes. Instead objects inherit from other objects. So it allows every object to be assosicated with some other object, known as its prototype.

What's a prototype? and how to create one?

To understand, what and why of prototype let's look at following example,

We have a person object, with firstName and lastName properties.
As you can see when we invoke a function called work on person object, javascript throws an error as there is no such property exists.
We will then attach an employment object containing work function to person's prototype using syntax proto.
Now, if we invoke function work on person object, 'Working ...' is displayed in console.


var person = {

    firstName: 'John',
    lastName: 'Smith'
};

console.log(person.firstName); // outputs John

person.work() // throws error, as there is no such function property exists in person object


var employment = {
    work : function () {console.log('Working ...');}
};


console.log(person.__proto__); // outputs {}, as there is no prototype object is assosicated with person

person.__proto__ = employment;

person.work(); // outputs Working ...

How does it work?

As inheritance in JavaScript is implemented using an object chain, and not using a class hierarchy, to understand prototypal inheritance we have to know how object chaining behaves.
Lets take a look at an example.

understand-prototype.js


class Person {}

const personOne = new Person();
const personTwo = new Person();

const personOnePrototype = Reflect.getPrototypeOf(personOne);
const personTwoPrototype = Reflect.getPrototypeOf(personTwo);

console.log(personOne === personTwo); //outputs false
console.log(personOnePrototype === personTwoPrototype); //outputs true

As you can see when we created two objects of class Person and compared their identity and the identity of their prototypes.
The objects are different, but they share their prototypes.
The instance personOne of Person has a prototype Person {}, which in turn has a prototype {}, which has null as its prototype, resulting in end of the prototype chain.

Two objects of the same class in class-based inheritance share the same class hierarchy, two objects of the same class in prototypal inheritance share the same object chain.

Gets are Deep, but Sets are Shallow

The motivation behind the inheritance is to reuse the methods and properties. In class-based inheritance, the instances of a class reuse the members of the class’s
base class. Whereas, in the case of prototypal inheritance, the prototype is reused by delegating calls to its prototype.

However, the behavior is widely different when we are trying to get a property as compared to setting it.

So let’s dig in,


class Person {}

Person.prototype.birthYear = 2000;
Person.prototype.calculateAge = function () { return new Date().getFullYear() - this.birthYear; };
Person.prototype.incrementBirthYearByOne = function () { this.birthYear += 1; };

const person1 = new Person();
const person2 = new Person();

console.log(person1.calculateAge()); //outputs 19
console.log(person2.calculateAge()); //outputs 19

person1.incrementBirthYearByOne();

console.log(person1.calculateAge()); //outputs 18
console.log(person2.calculateAge()); //outputs 19

We added and initialized a field, birthYear, to the prototype
Then we added a function, calculateAge(), to the prototype as well.
When called, will return the difference between the current year and javascript this.birthYear .
We then created two instances of Person — person1 and person2 — and displayed the value returned by calculateAge().
The birthYear field does not exist directly in these instances, but JavaScript will get the values from the prototype.
We then called the incrementBirthYearByOne() function on person1. Once again, incrementBirthYearByOne() is reused from the prototype and it increments javascript this.birthYear by 1.
We then asked for the age on the two instances by invoking function calculateAge(), and we get the output that confirms the isolation of the instances.

One thing to note here is that even if we override the field or property in the derived class, then we will correctly use the overridden field or property in the instance and not the one in the base class.

Difference between prototype, getPrototypeOf and _proto_

Person.prototype is used to establish the prototype of objects created by new operator i.e new Person().
Object.getPrototypeOf(person1) is used for retrieving person1's prototype object.
person.proto is non-standard mechanism for retrieving person1's prototype object.


  Object.getPrototypeOf(person1) === Person.prototype; // outputs true
  person1.__proto__ === Person.prototype; // outputs true

Parting Thoughts

JavaScript supports object-oriented programming, but unlike most of the other mainstream languages, it offers prototypal inheritance instead of class-based inheritance.
You have learned what a Prototype is and with Prototypal Inheritance, now you can achieve dynamic delegation.
You have seen that when a field or property is not present in an object, JavaScript will search for it in the prototype chain—that is, it will automatically look it up in the base class.
You have also learned the differences between prototype, getPrototypeOf and _proto_.
You'll end up using JavaScript's prototypal inheritance at many, a great feature of the language.

Hope you find this article useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment and give a few ❤️. See you next time.

Everything you need to know about the fundamentals of Callbacks in JavaScript

Vaibhav Gharge 👨🏻‍💻 — Sat, 30 Nov 2019 05:31:27 +0000

This article was originally published on blog.vaibhavgharge.com

The JavaScript runtime is inherently event-driven and callbacks are a key language feature. Since JavaScript is single-threaded, any long-running operations are blocking. JavaScript uses events to handle these blocking operations.

Lets take a closer look at,

What are Callbacks in Javascript?
Building Callbacks
Issues with Callbacks
Fixing Callback Hell
Parting Thoughts

What are Callbacks in Javascript?

Callbacks are the most basic form of JavaScript Asynchronous Programming. In simple words, a callback is a function that gets invoked after another function completes.

Any function that does not return instantaneously should be asynchronous. The traditional approach to designing asynchronous functions relied heavily on callbacks.

Let’s take a look at a small example and discuss how to build callbacks.

Building Callbacks

understand-callbacks.js


let https = require('https');

let make_request = function(url, callback) {

  var options = {
    host: this.host,
    path: url,
    method: 'post'
  };

  var req = https.request(options, function(res) {

    var buffer = '';

    res.on('data', function(data) {
      buffer += data;
    });

    res.on('end', function() {
      if (res.statusCode !== 200) {
        var message;

        try {
          message = JSON.parse(buffer);
        } catch(e) {
          message = buffer;
        }

        return callback('Error : ' + res.statusCode); // callback is invoked with error.
      }

      try {
        var json = JSON.parse(buffer);
      } catch (err) {
        return callback(err);  // callback is invoked with error.
      }

      callback(null, json); // callback is invoked with no error.

    });

  });

  req.on('error', function(err) {
    callback(err);  // callback is invoked with error.
  });

  req.end(data);
}

let callback = function (error, data) {

    if(error){
        console.log('Error Occured');
    }

    if(data){
        console.log('Request Successful');
    }
}

make_request('https://www.example.net/api/v1/sample/', callback);

As you can see when we have written a function called request that takes two arguments: URL, callback.
We then make an HTTP request to provided URL using post method.
Once the request is successful, we invoke the callback provided with null as the first argument (as there is no error) and data received is passed as the second argument.
However, that's not the case all the time, in real life response from API may throw an error. To handle this we are invoking the callback with an error as a first argument.

Let's see what can go wrong when using callbacks.

Issues with Callbacks

Callback Hell


    getData(function(a) {
      getMoreData(a, function(b) {
        getMoreData(b, function(c) {
          getMoreData(c, function(d) {
            getMoreData(d, function(e) {
              // ...
            })
          })
        })
      })
    })

Callback Existence Assumption


function make_request (url, data, callback) {
  // what happens if callback passed as an argument is not a function.
}

To summarize, callback problems comes from the fact that callbacks:

Don’t compose easily for multiple levels of callbacks.
This leads to code that is not extensible.
Inconsistency between the order of parameters.
Lacks, inbuilt error handling.

Fixing Problems Associated with "using Callbacks"

Callback hell can be easily avoided with two tricky ways: Named Functions and Modules.

Fixing Callback Hell using Named Functions

In Our initial example, we are already having a callback defined as named function to make it easily readable.


let callback = function (error, data) {
    // same as previously defined.
}

function make_request (url, data, callback) {
    // callback here is a named function passed as an argument
}

Separate your code into modules, so you can export a section of code that does a particular job. Then you can import that module into your larger application.

Fixing Callback Existence Assumption

To overcome this problem, considering back the same example, We first check that callback provided is not null and it is a valid function using typeof operator.

understand-callbacks.js


function make_request (url, data, callback) {

  if(!callback || !( typeof callback === 'function' )){
    throw new Error('Provided Callback is not a function. Please provide a function.');
  }

  // remaining part is same as above.
}

To summarize, problems with callbacks can substantially be reduced if We:

Don't nest functions. Give them names and place them at the top level of your program
Handle every single error in every one of your callbacks.
Create reusable functions and place them in a module to reduce the cognitive load required to understand your code. Splitting your code into small pieces like this also helps you handle errors, write tests, forces you to create a stable and documented public API for your code, and helps with refactoring.

Parting Thoughts

You have learned what a Callback is and why Callback is the most basic form of Asynchronous Programming in JavaScript. Unfortunately, callbacks induce a non-linear control flow and can be deferred to execute asynchronously, declared anonymously, and may be nested to arbitrary levels.
We have seen an example that takes a callback as an input argument which is invoked depending upon the state of execution of the HOF.
You have also learned how to avoid callback issues by gracefully defining named functions. However naming causes the callback function to persist in memory and prevents it from being garbage collected. On the other hand, anonymous callbacks are more resource-friendly because they are marked for garbage collection immediately after being executed. However, anonymous callbacks are not reusable and may be difficult to maintain, test, or debug and checking for the existence of the callback function.
You'll end up seeing Callbacks in a lot of legacy libraries. So It's absolutely important to understand how callback works.

Hope you find this article useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment. See you next time.

Understanding GraphQL - A New Frontier for Querying Data Over the Network

Vaibhav Gharge 👨🏻‍💻 — Sun, 24 Nov 2019 07:33:41 +0000

This article was originally published on blog.vaibhavgharge.com

GraphQL is a query language that can be used anywhere, but it often used to fulfill the gap between client and server applications.

Let's see how we can optimize APIs for consumers with GraphQL but before we dive into GraphQL, let's start with APIs and more specifically REST API's.

Let's take a closer look at,

REST isn't a fit for modern applications
GraphQL to the rescue
Who is using GraphQL?
Key Takeaways

What is a REST API?

In general, an API (or Application Programming Interface) provides an interface between two systems. It’s like a cog that allows two systems to interact with each other. In this case, the two systems are computers that interact programmatically through the API.

In REST, everything evolves around the idea of having resources that are accessible by URLs.

The following diagram shows the general model of a REST API:

So when looking at a REST API specifically a request for a REST API there are a few components to it the first is an HTTP verb or method and that specifies the operation that we'd like to take against the API and the second is an endpoint which is an identifier that allows us to specify the part of the API that we'd like to interact with.

REST isn't a fit for modern applications

Let's dig into an example to understand this,

If we execute this request we'll get back a response that looks like this in this particular case this API returns back JSON and it's comprised of information about user along with URLs to fetch user comments from the server.


// a RESTful request with HTTP GET

https://api.sample.com/users/

// the response in JSON

[
  {
    "userId": 1,
    "id": 1,
    "firstName": "Josh",
    "lastName": "Long",
    "userComments": "https://sample.com/user-comments/1"
  },
  {
    "userId": 1,
    "id": 2,
    "firstName": "Venkat",
    "lastName": "Subramaniam",
    "userComments": "https://sample.com/user-comments/2"
  }
]

So if we look at the response, we can see that, user details such as first name and last name of the user, in some cases you'll also see hypermedia such as userComments which is nothing but a machine-readable link to another place in the API about information related to the resource.

Now if we execute that request you'll notice that we get again attributes and more hypermedia.


// a RESTful request with HTTP GET

https://sample.com/user-comments/1

// the response in JSON

{
   "userId":1,
   "id":1,
   "userComments":[
      {  
         "userId":1,
         "id":10,
         "comment":"First Comment Added by Josh",
         "userAvatar":"https://sample.com/user-avatar/1"
      },
      {  
         "userId":1,
         "id":11,
         "comment":"Latest Commented Added by Josh",
         "userAvatar":"https://sample.com/user-avatar/1"
      }
   ]
}

If you imagine us as a desktop/web application you will immediately say that it takes numerous requests for us to determine the information that we may need as a client.

We have to keep making HTTP requests to get all the details that we need and this is especially painful when you're working with say a mobile client which might be working off a super slow connection.

This problem is called over fetching. The point-to-point nature of REST, a procedural API technology, forces the authors of services and clients to coordinate each use case ahead of time.

When frontend teams must constantly ask backend teams for new endpoints, often with each new screen in an application, development is dramatically slowed down.

So REST API's are optimized around servers and not necessarily clients and they're modeled around the resources that they return which makes them general-purpose and reusable from client to client and honestly that's one of rests biggest strengths.

GraphQL to the Rescue

"GraphQL is a query language designed to build client applications by providing an intuitive and flexible syntax and system for describing their data requirements and interactions". - GraphQL Specification

In short, GraphQL is an open-source query language specification created by Facebook, a company that unsurprisingly remains at the pinnacle of web-based software development.

Facebook used it internally for its mobile applications since 2012, as an alternative to the common REST architecture and it's been implemented in a variety of different languages like Ruby, JavaScript, Python and so on.

It allows requests to be made for specific data, giving clients more control over what information to be retrieved. This is more difficult to achieve with a RESTful architecture because the backend defines what data is available for each resource on each URL, while the frontend always has to request all the information in a resource, even if only a part of it is needed.

Once a GraphQL service is running (typically at a URL on a web service), it can be sent GraphQL queries to validate and execute. A received query is first checked to ensure it only refers to the types and fields defined, then runs the provided functions to produce a result.

For example the query:

One query already requests multiple resources (comments), called fields in GraphQL, and only a particular set of nested fields for these fields (name, urlSlug for article), even though the entity itself offers more data in its GraphQL schema (e.g. description, releaseData for article).

A RESTful architecture needs at least two round trips to retrieve the user entity and its comments, but the GraphQL query made it happen in one. In addition, the query only selected the necessary fields instead of the whole entity.

That’s GraphQL in a nutshell. The server application offers a GraphQL schema, where it defines all available data with its hierarchy and types, and a client application only queries the required data.

Who is using GraphQL?

Facebook is the driving company behind the GraphQL specification and reference implementation in JavaScript, but other well-known companies are also using it for their applications. They are invested in the GraphQL ecosystem due to the huge demand for modern applications.

Apart from Facebook and Instagram, GraphQL has also been used by these well-known companies:

GitHub
Shopify
Twitter
Coursera
Strip
Wordpress
The New York Times

Key Takeaways

This tutorial gives you a basic idea of how GraphQL helps us be client-centric than server-centric.
It allows us to perform optimized queries to application servers, requesting only data required by the client at that moment in time.
You also learned that GraphQL is not a programming language, but is instead a language used to query application servers that have capabilities to provide the results of complex queries.

Hope you find this post useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment.

Imperative vs Declarative programming. Your enemy is not object-oriented programming.

Vaibhav Gharge 👨🏻‍💻 — Sun, 17 Nov 2019 05:20:26 +0000

This article was originally published on blog.vaibhavgharge.com

A lot of people complain that OOP has done very poorly. Well sure but a lot of things have been done poorly but our enemy is not Object Oriented Programming.

The real conversation is not the difference between object-oriented and functional, the difference is Imperative versus Declarative style of programming.

Well as a mainstream programmer, we've been programming an imperative style for a very long time and of course, the world is moving towards more of a declarative style of programming.

So the real question is to program imperatively or should we program declaratively and which one should we choose?

Let's explore,

How they are different.
Code example.
Parting Thoughts.

What is the difference though between these two paradigms?

Imperative style of programming is where you tell what to do but you also have to spend the time and effort telling how to do it. So not just the what but also the how. First do this and next do that.

Let's look at an example

So here I have a little program. I have a list of names but I want to know if our good friend Nemo is on the list.

So how do I find if Nemo is on this list?

The very first step I'm gonna do, is I'm gonna define a boolean found is equal to false and of course if we found what do I want to output Nemo found.
Otherwise, what I'm gonna say Nemo not found.


    List<String> names = List.of("Gill", "Dorry", "Bruce", "Nemo", "Darla");

    boolean found = false;

    for (String name : names) {
        if (name.equals("Nemo")) {
            found = true;
            break;
        }
    }

    if (found) {
        System.out.println("Nemo Found. :-)");
    } else {
        System.out.println("Nemo Not Found. :-(");
    }

When I run the code it says "Nemo Found. :-)".

This is an example of an imperative style of code as we are not only explicit about what to do but also how to do it.

Now let's take a look at code, that is an example of a declarative style of programming.

Declarative style is where we tell what to do and not how to do it. It is an abstraction on top of imperative systems that opens the whole new world of possibilities to program in asynchronous and event-driven fashion without having to think about how to it works.

List<String> names = List.of("Gill", "Dorry", "Bruce", "Nemo", "Darla");

    if (names.contains("Nemo")) {
        System.out.println("Nemo Found. :-)");
    } else {
        System.out.println("Nemo Not Found. :-(");
    }

Parting Thoughts

The fact that everything ends up being imperative at some point as it hits the operating system and hardware is important to remember and understand because it helps us with the mental model of what declarative programming is addressing and how it ultimately executes - there is no magic.
Imperative Style is easy to write but it's hard to read.
On the other hand, Declarative Style is easy to read but it's hard to write (to a certain extent due to unfamiliarity).
Should programs be imperative or should they be functional? and I'm gonna say the answer to me is that it's neither one of them and there are times when the code has to be imperative and there are times when the code has to be functional and I think it is very naive to say it's got to be entirely one and not the other.

Hope you find this post useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment.😊 Cheers

Understanding the Eight Fallacies of Distributed Systems

Vaibhav Gharge 👨🏻‍💻 — Sun, 11 Aug 2019 11:03:14 +0000

This article was originally published on blog.vaibhavgharge.com

The software industry has been writing distributed systems for several decades. In 1969, the U.S. Department of Defense created ARPANET, the precursor to today’s internet. Around the same time, the SWIFT protocol was established.

SWIFT is a vast messaging network used by banks and other financial institutions to quickly, accurately, and securely send and receive information, such as money transfer instructions.

Nevertheless, In 1994, Peter Deutsch, a sun fellow at the time, drafted 7 assumptions architects and designers of distributed systems are likely to make, which prove wrong in the long run resulting in all sorts of troubles and pains for the solution and architects who made the assumptions.

In 1997 James Gosling added another such fallacy. These assumptions are now collectively known as the “The Eight Fallacies of Distributed Computing” :

The network is reliable.
Latency is zero.
Bandwidth is infinite.
The network is secure.
Topology doesn't change.
There is one administrator.
Transport cost is zero.
The network is homogeneous.

The goal of this article is to define and clarify the different aspects of “Fallacies of Distributed Computing”.

Lets take a closer look at each of these fallacies, explains them and checks their relevancy for distributed systems today.

1. The network is reliable

When was the last time you saw a switch fail? After all, even basic switches these days have MTBFs (Mean Time Between Failure) in the 50,000 operating hours and more.
If your application is a mission critical 365 x 7 kind of application, you will hit that failure--and Murphy will make sure it happens in the most inappropriate moment.

You might aruge that, most applications are not like that. So what's the problem?

Well, there are plenty of problems: Power failures, someone trips on the network cord, all of a sudden clients connect wirelessly, and so on. If hardware isn't enough to make your system go haywire--the software can fail as well, and it does.
The situation may even be overwhelming, if you collaborate with an external partner, such as an e-commerce application working with an external credit-card processing service. Their side of the connection is not under your direct control and failture on their side makes your application unusable.

Lastly there are security threats like DDOS attacks and the like.

So how to handle such situations?

On the infrastructure side, you need to think about hardware and software redundancy and weigh the risks of failure versus the required investment.

On the software side, you need to think about messages/calls getting lost whenever you send a message/make a call over the wire. Using circuit breaker pattern while developing, gives the failing side some time to breath and recover.

To sum up, the network is Unreliable and we as software architect/designers/developers need to address that.

2. Latency is zero

Latency is nothing but how much time it takes for data to move from one place to another (versus bandwidth which is how much data we can transfer during that time).

Latency can be relatively good on a LAN--but latency deteriorates quickly when you move to WAN scenarios or internet scenarios.

Latency is more problematic than bandwidth. Here's a quote from a post by Ingo Rammer on latency vs. Bandwidth that illustrates this:

"But I think that it’s really interesting to see that the end-to-end bandwidth increased by 1468 times within the last 11 years while the latency (the time a single ping takes) has only been improved tenfold. If this wouldn’t be enough, there is even a natural cap on latency. The minimum round-trip time between two points of this earth is determined by the maximum speed of information transmission: the speed of light. At roughly 300,000 kilometers per second (3.6 * 10E12 teraangstrom per fortnight), it will always take at least 30 milliseconds to send a ping from Europe to the US and back, even if the processing would be done in real time."

So what can be done in such scenarios?

Taking latency into consideration means you should strive to make as few as possible calls and assuming you have enough bandwidth. For example, The AJAX/Asynchronous approach allows for using the dead time the users spend digesting data to retrieve more data - however, you still need to consider latency.
Making correct design decisions, regarding the data availability. Can your application take data from the end of the day Batch Process avoiding network calls for real time data needs?
These design chocies makes a huge impact on the overall user experience of your application.

3. Bandwidth is infinite

This fallacy, in my opinion, is not as strong as the others. If there is one thing that is constantly getting better in relation to networks it is bandwidth.

However, there are two forces at work to keep this assumption a fallacy.

One is that while the bandwidth grows, so does the amount of information we try to squeeze through it. VoIP, videos, and IPTV are some of the newer applications that take up bandwidth. Downloads, richer UIs, big javascript bundles and reliance on verbose formats (XML) are also at work--especially if you are using lower lines.
The other force at work to lower bandwidth is packet loss. In the local area network or intranet environment, packet loss usually small enough.
On the other hand In the WAN however, packet loss are often rather large and something that the end systems can not control. In streaming media and online game applications, packet loss can affect a user's quality of experience (QoE) drastically.

The main implication then is to consider that in the production environment of our application there may be bandwidth problems which are beyond our control. And we should bear in mind how much data is expected to travel over the wire.

4. The network is secure

Statistics published at Aladdin.com shows that: "For 52% of the networks the perimeter is the only defense". According to Preventsys and Qualys, 52% of chief information security officers acknowledged having a "Moat & Castle" approach to their overall network security . They admitted that once the perimeter security is penetrated, their networks are at risk.
Aladdin also claims that the costs of Malware for 2004 (Viruses, Worms, Trojans etc.) are estimated between $169 billion and $204 billion. The implications of network (in) security are obvious--you need to build security into your solutions from Day 1.

Security is a system quality attribute that needs to be taken into consideration starting from the architectural level. Security is usually a multi-layered solution that is handled on the network, infrastructure, and application levels.

5. Topology doesn't change

The fifth Distributed Computing Fallacy is about network topology. "Topology doesn't change." That's right, it doesn’t--as long as it stays in the test lab.
When you deploy an application in the wild (that is, to an organization), the network topology is usually out of your control. The operations team (IT)
is likely to add and remove servers every once in a while and/or make other changes to the network.
When you're talking about clients, the situation is even worse. There are laptops coming and going, wireless ad-hoc networks , new mobile devices. In short, topology is changing constantly.
What does this mean for the applications we develope? Simple. Do not to depend on specific endpoints or routes, if you can't be prepared to renegotiate endpoints. Or provide discovery services which allows to abstract the physical structure of the network and handle it gracefully.
The most obvious example for this is DNS names instead of IP addresses. For example, If you move your blogging site from one hosting service to another. The transfer will go through without a hitch, because when the DNS routing tables are updated (it takes a day or two to the change to ripple) readers will be directed to the new site without knowing the routing (topology) has changed under their feet.

6. There is one administrator

The IT group usually has different administrators, assigned according to expertise--databases, web servers, networks, Linux, Windows, Main Frame and the like. This is the easy situation.
The problem occurs when your company collaborates with external entities (for example, connecting with a business partner), or if your application is deployed for Internet consumption and hosted by some hosting service and the application consumes external services. In these situations, the other administrators are not even under your control and they may have their own agendas/rules.
Well, as long as everything works, you may not care. You do care, however, when things go astray and there is a need to pinpoint a problem (and solve it). Furthermore, you need to understand that the administrators will most likely not be part of your development team so we need provide them with tools to diagnose
and find problems.
To sum up, when there is more than one administrator, you need to remember that administrators can constrain your options (administrators that sets limited privileges, limited ports and protocols and so on), and that you need to help them manage your applications.

7. Transport cost is zero

There are a couple of ways you can interpret this statement, both of which are false assumptions.

One way is that going from the application level to the transport level is free. This is a fallacy since we have to do marshaling (serialize information into bits) to get data unto the wire, which takes both computer resources and adds to the latency.
The second way to interpret the statement is that the costs (as in cash money) for setting and running the network are free. This is also far from being true. There are costs--costs for buying the routers, costs for securing the network, costs for leasing the bandwidth for internet connections, and costs for operating
and maintaining the network running. Someone, somewhere will have to pick the tab and pay these costs.

8. The network is homogeneous

The eighth and final Distributed Computing fallacy is "The network is homogeneous", which was added by James Gosling six years later (in 1997). Any network, except maybe the very trivial ones, are not homogeneous. Heck, even my home network has a Linux based HTPC, a couple of Windows based PCs, and a Android Mobile--all connected by a wireless network.
Even if you managed to maintain your internal network homogeneous, you will hit this problem when you would try to cooperate with a partner or a supplier.
It is worthwhile to pay attention to the fact the network is not homogeneous at the application level. The implication of this is that you have to assume interoperability will be needed sooner or later and be ready to support it from day one.
Do not rely on proprietary protocols--it would be harder to integrate them later. Do use standard technologies that are widely accepted; the most notable examples being XML or Web Services.

Conclusions

Even today, the breakdown or ‘outage’ of a cloud service happens surprisingly frequently. When you are planning or developing a distributed application, it is a bad idea to assume attributes and qualities in your network that aren’t necessarily there: far better to plan on the assumption that your network will be costly, and will occasionally be unreliable and insecure.
Remember that (successful) applications evolve and grow so even if things look Ok for a while if you don't pay attention to the issues covered by the fallacies they will rear their ugly head and bite you.
I hope that reading this article both helped explain what the fallacies mean as well as provide some guidance on what to do to avoid their implications.

Hope you find this article useful. Please share your thoughts in the comment section.

I’d be happy to talk! If you liked this post, please share, comment and give few 👏 😊 Cheers. See you next time.

References

[Britton2001] IT Architecture & Middleware, C. Britton, Addison-Wesley 2001, ISBN 0-201-70907-4 [JDJ2004]. http://java.sys-con.com/read/38665.htm
[Gosling] http://blogs.sun.com/roller/page/jag
[Ingo] http://blogs.thinktecture.com/ingo/archive/2005/11/08/LatencyVsBandwidth.aspx
[RichUI] http://richui.blogspot.com/2005/09/ajax-latency-problems-myth-or-reality.html