Forem: Cristian Curteanu

Create an XMLHttpRequest wrapper, similar with Fetch API in JavaScript

Cristian Curteanu — Fri, 12 Feb 2021 05:51:11 +0000

This article was originally published here

When using fetch API function from the JS standard library, it annoys me every single time I want to process the response. So, I decided to create a wrapper for XMLHttpRequest prototype, which will make it simpler to handle the response, and will have similar interface with Fetch API (basically an alternative for Fetch API on top of XMLHttpRequest).

Getting started

XMLHttpRequest provides quite a simple API for handling HTTP requests, even though is oriented on callbacks interface, that are responding for specific events, and provide data from response.

Let's start with first version of httpRequest API function:

let httpRequest = function(method, url, { headers, body, options } = {}) {
  method = method.toUpperCase()

  let xhr = new XMLHttpRequest()
  xhr.withCredentials = true;
  xhr.open(method, url)

  xhr.setRequestHeader("Content-Type", "application/json")
  for (const key in headers) {
    if (Object.hasOwnProperty.call(headers, key)) {
      xhr.setRequestHeader(key, headers[key])
    }
  }

  xhr.send(body)

  return new Promise((resolve, reject) => {
    xhr.onload = function() {
      resolve(new HttpResponse(xhr))
    }

    xhr.onerror = function() {
      reject(new HttpError(xhr))
    }
  })
}

As we can see here, the function receives the HTTP method and URL as required parameters. After creating the basic objects it needs to operate with, it sends the request. The function is returning a promise, that wraps the event callbacks for xhr request object. When a specific event is triggered, the promise resolvers are sending wrapped values of HttpResponse and HttpError.

As a side note, here was also enabled the CORS, by setting the withCredentials to a true value; which means that it should be enabled on the server as well, in order to execute requests properly.

Now, we will define the HttpResponse prototypes:

let HttpResponse = function(xhr) {
  this.body = xhr.response
  this.status = xhr.status
  this.headers = xhr.getAllResponseHeaders().split("\r\n").reduce((result, current) => {
    let [name, value] = current.split(': ');
    result[name] = value;
    return result;
  })
  this.parser = new DOMParser();
}

HttpResponse.prototype.json = function() {
  return JSON.parse(this.body)
}

HttpResponse.prototype.getAsDOM = function() {
  return this.parser.parseFromString(this.body, "text/html")
}

The only thing that it does it takes in the XMLHttpRequest object, and decomposes only those specific fields, that represents most interest when handling an HTTP Response: status, body and headers . The parser field is defined to be used in getAsDOM method. That specific method parses a text/html content, and transforms it into a DOM object.

The json method is pretty straightforward: it parses a JSON from the body.

Let's take a look on HttpError prototype now:

let HttpError = function(xhr) {
  this.body = xhr.response
  this.status = xhr.status
  this.headers = xhr.getAllResponseHeaders().split("\r\n").reduce((result, current) => {
    let [name, value] = current.split(': ');
    result[name] = value;
    return result;
  })
}

HttpError.prototype.toString = function() {
  let json = JSON.parse(this.body)
  return "["+ this.status + "] Error: " + json.error || json.errors.map(e => e.message).join(", ")
}

This is pretty similar with HttpResponse prototype, however, it just provides only a functionality to unwrap the error messages following a specific convention for JSON error messages.

Let's check how it works:

let response = await httpRequest("GET", "https://api.your-domain.com/resource/1")
console.log(response.json())

This will return a JSON body of the response.

Track progress of the upload

Another feature that Fetch API lacks, is the upload progress tracking. We can also add it, as a callback to options field of the input object. Also, we need to track if there is something wrong during request, to receive an error.

The second version will cover all these changes:

let httpRequest = function(method, url, { headers, body, options } = {}) {
  method = method.toUpperCase()

  let xhr = new XMLHttpRequest()
  xhr.withCredentials = true;
  xhr.open(method, url, true)

  xhr.setRequestHeader("Content-Type", "application/json")
  for (const key in headers) {
    if (Object.hasOwnProperty.call(headers, key)) {
      xhr.setRequestHeader(key, headers[key])
    }
  }

  if (options && options.hasOwnProperty("checkProgress")) {
    xhr.upload.onprogress = options.checkProgress
  }
  xhr.send(body)

  return new Promise((resolve, reject) => {
    xhr.onload = function() {
      resolve(new HttpResponse(xhr))
    }

    xhr.onerror = function() {
      reject(new HttpError(xhr))
    }

    xhr.onabort = function() {
      reject(new HttpError(xhr))
    }
  })
}

Let's see how it will look for a POST request:

let response = await httpRequest("POST", "https://api.your-domain.com/resource", {
  body: JSON.stringify({"subject":"TEST!"}),
  options: {
    checkProgress: function(e) {
      console.log('e:', e)
    }
  }
})
console.log(response.status)
console.log(response.json())

Let's take a look one more time on the full implementation:


let HttpResponse = function(xhr) {
  this.body = xhr.response
  this.status = xhr.status
  this.headers = xhr.getAllResponseHeaders().split("\r\n").reduce((result, current) => {
    let [name, value] = current.split(': ');
    result[name] = value;
    return result;
  })
  this.parser = new DOMParser();
}

HttpResponse.prototype.json = function() {
  return JSON.parse(this.body)
}

HttpResponse.prototype.getAsDOM = function() {
  return this.parser.parseFromString(this.body, "text/html")
}


let HttpError = function(xhr) {
  this.body = xhr.response
  this.status = xhr.status
  this.headers = xhr.getAllResponseHeaders().split("\r\n").reduce((result, current) => {
    let [name, value] = current.split(': ');
    result[name] = value;
    return result;
  })
}

HttpError.prototype.toString = function() {
  let json = JSON.parse(this.body)
  return "["+ this.status + "] Error: " + json.error || json.errors.join(", ")
}

let httpRequest = function(method, url, { headers, body, options } = {}) {
  method = method.toUpperCase()

  let xhr = new XMLHttpRequest()
  xhr.withCredentials = true;
  xhr.open(method, url, true)

  xhr.setRequestHeader("Content-Type", "application/json")
  for (const key in headers) {
    if (Object.hasOwnProperty.call(headers, key)) {
      xhr.setRequestHeader(key, headers[key])
    }
  }

  if (options && options.hasOwnProperty("checkProgress")) {
    xhr.upload.onprogress = options.checkProgress
  }
  xhr.send(body)

  return new Promise((resolve, reject) => {
    xhr.onload = function() {
      resolve(new HttpResponse(xhr))
    }

    xhr.onerror = function() {
      reject(new HttpError(xhr))
    }

    xhr.onabort = function() {
      reject(new HttpError(xhr))
    }
  })
}

This small piece of code take advantage of the XMLHttpRequest library, and still has a similar API. Of course there is a lot of space for improvement, so if you can, please share your ideas in the comments.

Mutexes and RWMutex in Golang

Cristian Curteanu — Thu, 28 Jan 2021 08:40:55 +0000

This article was originally published here

If you have ever used processing using multiple threads, you probably are fully aware about what are race conditions.

Just to recap, it happens when two processing threads are accessing the same value in memory, and are changing it. Because of non-deterministic nature of concurrent threads, the value stored will comply for only one specific thread, which leads to a inconsistent behaviour. If you are working on a payment system, or a banking software this can can cost business huge amount of money.

To avoid that, there is a mechanism in go for locking the value in the memory, called Mutext. This stands for mutual exclusion, and what it means is that it keeps track of which thread has access to specific value in memory, at specific point in time.

Let's consider the following piece of code:

type Account struct {
    balance int
    Name    string
}

func (a *Account) Withdraw(amount int) {
    a.balance -= amount
}

func (a *Account) Deposit(amount int) {
    a.balance += amount
}

func (a *Account) GetBalance() int {
    return a.balance
}

It is a pretty simple structure in Go, that keeps track of accounts balance, nothing so special. However, if we will try to withdraw, or deposit an amount on some specific account from multiple goroutines, it will inevitably lead to a race condition, like this:

var account Account
account.Name = "Test account"

for i := 0; i < 20; i++ {
  wg.Add(1)
  go account.Deposit(100)
}

for i := 0; i < 10; i++ {
  wg.Add(1)
  go account.Withdraw(100)
}

wg.Wait()
fmt.Printf("Balance: %d\n", account.GetBalance())

This means, that when running this code several times, the value of balance will be inconsistent, meaning it will have different values. In order to avoid that, we need to add locks for both reading and writing to the values. In our case, the Mutex lock will be added as a field to this structure, which Golang runtime will understand, that this lock is applied for the scope of this specific struct:

type Account struct {
    balance int
    Name    string
    lock    sync.Mutex
}

func (a *Account) Withdraw(amount int, wg *sync.WaitGroup) {
    defer wg.Done()
    a.lock.Lock()
    a.balance -= amount
    a.lock.Unlock()
}

func (a *Account) Deposit(amount int, wg *sync.WaitGroup) {
    defer wg.Done()
    a.lock.Lock()
    a.balance += amount
    a.lock.Unlock()
}

func (a *Account) GetBalance() int {
    a.lock.Lock()
    defer a.lock.Unlock()

    return a.balance
}

and the client code will now look like this:

    var account Account
    var wg sync.WaitGroup

    account.Name = "Test account"

    for i := 0; i < 20; i++ {
        wg.Add(1)
        go account.Deposit(100, &wg)
    }

    for i := 0; i < 10; i++ {
        wg.Add(1)
        go account.Withdraw(100, &wg)
    }

    wg.Wait()
    fmt.Printf("Balance: %d\n", account.GetBalance())

Now, it is more consistent, and the value of the balance will be the same.

Problem solved, why we need RWMutex?

That's fair enough. But the problem is, that when using Mutex the value from the memory will be locked until the Unlock method will be invoked. This is also valable for the reading phase. In order to make reading accessible for multiple threads, the Mutex can be replaced with RWMutex, and for reading it will be used RLock and RUnlock methods.

In this case the code will look something like this:

type Account struct {
    balance int
    Name    string
    lock    sync.RWMutex
}

func (a *Account) Withdraw(amount int, wg *sync.WaitGroup) {
    defer wg.Done()

    a.lock.Lock()
    defer a.lock.Unlock()
    a.balance -= amount

}

func (a *Account) Deposit(amount int, wg *sync.WaitGroup) {
    defer wg.Done()

    a.lock.Lock()
    defer a.lock.Unlock()
    a.balance += amount
}

func (a *Account) GetBalance() int {
    a.lock.RLock()
    defer a.lock.RUnlock()

    return a.balance
}

Note, that other thing that changed, is the defer unlock for Deposit and Withdraw. This may be useful for other complex operations, that may result into unlocked locks, due to failures, that may occur to the code.

Conclusion

Race conditions very often are hard to detect, and can lead to serious bugs in system functionality. The most straightforward approach would be to use Mutex for locking your critical data. The RWMutex can be used if, and only if there are a limited number of concurrent readers of that data. Starting from a number of concurrent readers, it may become ineffective to use RWMutex.

Design patterns in Go: Bridge

Cristian Curteanu — Mon, 25 Jan 2021 20:41:21 +0000

This article was originally published here

Have you ever had the situation when you need to use different database drivers for your repository. Well, in order to avoid using separate repositories for different database drivers, I would suggest to use Bridge design pattern to make things more elegant.

Problem

Let's say that you have started to create an application, and you designed it to use MySQL database. It's actually a good choice to start with, essentially it is always good to start with a relational database. But you came across an issue: your start receiving errors alerts in the logs like database connection pool exceeded. The problem is that a MySQL database is not as easy to scale horizontally as a NoSQL database, like MongoDB.

So you decide to migrate to a MongoDB database. You already prepared the infrastracture, but the problem now is that you have to migrate all data, but still keep it consistent, at least before the moment when you will prepare a migration script for that.

In order to make transition easier, you need to be able to connect with both databases. Hence, you will need to use a bridge, to migrate all the data.

Let's take a look on how an implementation would look like.

Solution

First of all, we will need an interface with common driver operation (CRUD). For this current implementation example we will use on Create and Read actions, for the sake of simplicity:

type Database interface {
    // For now only two methods will be defined, just illustrate the idea
    Create(input map[string]interface{}, result interface{}) error
    Find(id string, result interface{}) error
}

Let's see how the MySQL driver will look like, in the context of this new interface:

type MySqlConnection struct {
    url string
}

func NewMySqlConnection(url string) *MySqlConnection {
    return &MySqlConnection{url}
}

type MysqlDatabase struct {
    conn *MySqlConnection
}

func NewMysqlDatabase(conn *MySqlConnection) *MysqlDatabase {
    return &MysqlDatabase{conn}
}

func (ms MysqlDatabase) Create(input map[string]interface{}, result interface{}) error {
    fmt.Printf("Creating %s using MySQL\n", reflect.TypeOf(result))
    return nil
}

func (ms MysqlDatabase) Find(id string, result interface{}) error {
    fmt.Printf("Fetching %s, with id %s, using MySQL\n", reflect.TypeOf(result), id)
    return nil
}

I have also added, some rudimentary MySQL connection object, that should be injected into driver, but is can have a different structure for a production system.

Now let's add a repository and model struct, in order to operate somehow; let's say it will be User model:

type User struct {
    FirstName string
    LastName  string
    Email     string
}

type UserRepository struct {
    db Database
}

func NewUserRepository(db Database) *UserRepository {
    return &UserRepository{db}
}

func (repo UserRepository) Create(user User) error {
    data := map[string]interface{}{
        "first_name": user.FirstName,
        "last_name":  user.LastName,
        "email":      user.Email,
    }

    err := repo.db.Create(data, &user)

    return err
}

func (repo UserRepository) Find(id string) (User, error) {
    var result User
    var err error

    err = repo.db.Find(id, &result)

    return result, err
}

As we can see here, it does a preprocessing for User data that will be used for drivers in order to create new records. And also the result will be written to the reference of the User that is passed to drivers.

In order to add the MongoDB driver, we will simply implement the Database interface for MondoDB driver:

type MongodbConnection struct {
    url string
}

func NewMongodbConnection(url string) *MongodbConnection {
    return &MongodbConnection{url}
}

type MongoDatabase struct {
    conn *MongodbConnection
}

func NewMongoDatabase(conn *MongodbConnection) *MongoDatabase {
    return &MongoDatabase{}
}

func (md MongoDatabase) Create(input map[string]interface{}, result interface{}) error {
    fmt.Printf("Creating %s using MongoDB\n", reflect.TypeOf(result))
    return nil
}

func (md MongoDatabase) Find(id string, result interface{}) error {
    fmt.Printf("Fetching %s, with id %s, using MongoDB\n", reflect.TypeOf(result), id)
    return nil
}

And now let's test it:

    var db Database

  if os.Getenv("DB_DRIVER") == "MY_SQL" {
        db = NewMysqlDatabase(NewMySqlConnection(os.Getenv("DB_URL")))
  } else if os.Getenv("DB_DRIVER") == "MONGO_DB" {
    db = NewMongoDatabase(NewMongodbConnection(os.Getenv("DB_URL")))
  } else {
    panic("Unknown DB driver had been given")
  }

    repo := NewUserRepository(db)

    repo.Create(User{
        FirstName: "John",
        LastName:  "Smith",
        Email:     "john.smith@gmail.com",
    })

    repo.Find("1")

which, if the DB_DRIVER will have MONGO_DB value, it will produce following:

Creating *main.User using MongoDB
Fetching *main.User, with id 1, using MongoDB

Conclusion

The bridge as we saw, separates the implementation from the interface, which can be used in the client object, only by injecting with specific implementation. This could be very handy, in other scenarios, when you need to have several implementations of the same abstraction, and have a client that will just consume the injected object only by using it's abstraction, which as a result might help when implementing an Abstract Factory

How to implement and use Builder pattern in JS

Cristian Curteanu — Wed, 29 Jul 2020 03:36:57 +0000

There might be cases when an object contains too many details to be passed via a constructor, and that might be the case to use builder pattern, so that an object setup could be done gradually, thus taking the complex construction of an object into smaller pieces

Let's consider a Car type abstraction:

class Car {
    brand;
    model;
}

At this point the encapsulation of these fields are not relevant, as it can be added; and also the set of properties is kept minimal for the ease of understanding, although the Builder pattern could make sense for a more complex type.

The builder pattern, as it's representation, should take values from external world, that will be injected into Car object, that will also be contained by the builder. When the object is considered to have everything set up, the build method should be called, which basically will return the built object.

The following is a possible implementation of the Car builder:

class CarBuilder {
    #car;
    constructor(car = null) {
        this.#car = car || new Car();
    }

    madeBy(brand) {
        this.#car.brand = brand;
        return this;
    }

    model(model) {
        this.#car.model = model;
        return this;
    }

    build() {
        return this.#car;
    }
}

Note that in this implementation, the Car object could be also injected into builder, which makes the implementation of the builder less coupled with the Car object itself. And this is how it can be used:

let carBuilder = new CarBuilder(new Car());
let car = carBuilder.madeBy("Toyota").model("Prius").build();

console.log(car) // => Car { brand: 'Toyota', model: 'Prius' }

This way, the model name and brand name was passed to a Car object, using madeBy and model method of a separate abstraction.

This implementation, can be replaced to a more functional approach:

class FunctionalCarBuilder {
    actions = [];

    constructor(car) {
        this.car = car
    }

    madeBy(brand) {
        this.actions.push(function(car) {
            car.brand = brand;
        })
        return this;
    }

    model(model) {
        this.actions.push(function(car) {
            car.model = model;
        })
        return this
    }

    build() {
        for (let i = 0; i < this.actions.length; i++) {
            const build = this.actions[i];
            build(this.car)
        }
        return this.car
    }
}

which can be used as follows:

let carBuilder = new FunctionalCarBuilder(new Car());
let car = carBuilder.madeBy("Toyota").model("Prius").build();

console.log(car) // => Car { brand: 'Toyota', model: 'Prius' }

So it does have the same interface, however here we have a set of function objects, that basically are modifiers of the build object. It might be useful for the cases when we need to decouple the logic of value definition from the builder, and don't have any assignment parameter. To go even further, a modifier function can be passed as parameter on specific builder methods, and this way to improve the decoupling.

Conclusion

The builder pattern can be extremely useful when we have to deal with definition of an object with a complex structure, thus the object definition is delegated to separate abstraction, and the control of definition process is even better. Due to it's nature, JavaScript provides several ways of builder definitions; although the interface is the same, the approach and the mechanism of object construction would be different.

How else you can define properties for JavaScript objects

Cristian Curteanu — Sat, 24 Nov 2018 10:27:31 +0000

JavaScript is an awesome technology. It's really flexible, and allows cool runtime object manipulation, which are not such a headache like in case with Ruby (though that's my personal opinion after working with both).

The common way of properties definition

Well, there are several ways of default properties definition. First one is using object initializer literal. For instance let's have the Car object:

var Car = {
    brand: 'Toyota',
    model: 'Prius',
    engine: {
        state: 'off'
    },
    turnOn: function() {
        this.engine.state = 'on'
        console.log('Engine is:', this.engine.state)
    }
}

This way object's properties are accessible from the outside world, like:

Car.brand // => "Toyota"
Car.brand = 'Honda'
Car.brand // => "Honda"

Car.engine.state // => "off"
Car.turnOn() // => "Engine is: on"
Car.engine.state // => "on"

And can be changed with values of other type.

Another way of property definition is in the function constructor using this keyword, which will reference to current Function object:

function Car() {
    this.brand = 'Toyota'
    this.model = 'RAV 4'
    this.engine = {
        state: 'off'
    }
}

and they are also accessible from the outside world:

var car = new Car()

car.brand // => "Toyota"
car.brand = 'Honda'
car.brand // => "Honda"

But there are some additional features for property definitions in JavaScript which will be described in next section.

Defining property using Object.defineProperty method

According to documentation, this is a Object's static method, which takes an object as first parameter, the name of new property as the second parameter, and an object with options. Let's see the next example:

var Car = {
    brand: 'Toyota'
}

Object.defineProperty(Car, 'brand', {
  writable: false,
})

Car.brand // => "Toyota"
Car.brand = 'BMW'
Car.brand // => "Toyota"

This way, the brand property can not be overwritten from the outside world. This way, it is possible to set all the aspects of an object property, and gives a good portion of control over the objects' properties. Here are some other options, that should be taken in account:

configurable - has false as default, and will allow to change the type of this property or delete the property from this current object if the value will be true
enumerable - this will indicate if this property should be shown during enumeration, and it will do so only if it's value will be true. By default it is false
writable - true if this property should be changed with an assignment operator =. Default to false
value - it would take any value of any valid, specific type, like number, object, function, etc.
get - this property can take a function as a value and it will override the property value extraction of object through which the property is accessed
set - this property can take a function as a value with a single argument, which can override the logic of assignment operator of object through which the property is accessed.

Let's consider a more complex example. If there is a need to manipulate some other data inside an object, without specific method invocation, it is wise to customise the set property of object property, as follows:

function CustomGettersSetters() {
    var a = null;
    var history = [];

    Object.defineProperty(this, 'a', {
        get() {
            console.log('Inside getter')
            return a
        },
        set(arg) {
            console.log('Inside setter')
            history.push(arg)
            a = arg
            return true
        }
    })

    this.getHistory = function() { return history }
}

var custom = new CustomGettersSetters();

custom.a // will log "Inside getter" and return `null`
custom.a = '321' // will log "Inside setter", push a value to `history`, and will set value to `a`
custom.a = 764 // will log "Inside setter", push a value to `history`, and will set value to `a`
custom.a // will log "Inside getter" and return `764`
custom.history // will return `undefined`
custom.getHistory() // will return an array ["321", 764]

This way there was added an additional functionality for the current object, without any need for any additional method calls.

Conclusion

The Object.defineProperty method is a very powerfull tool for object property manipulation, as it allows some sort of control over it, which can be useful at some point. There is also Object.defineProperties which can create multiple properties in similar way. The difference is that it takes two parameters: first is the object which will have new properties, and second would be an object of properties, which also will contain an object of options mentioned above.