Forem: Sriram

Making concurrent API requests in Go

Sriram — Sun, 05 Jul 2020 08:25:42 +0000

Making API calls from the backend is a pretty common scenario we all come across, especially when working with microservices. Sometimes we even have to make multiple calls at the same time and doing it sequentially will be inefficient. So in this article, let us see how to implement concurrency when making multiple API calls.

Encapsulating request code

Taking a look at what we have got we have

a struct called Comic which contains the fields required fields from the response
a function to make the request to XKCD and to return the decoded response



type Comic struct {
    Num   int    `json:"num"`
    Link  string `json:"link"`
    Img   string `json:"img"`
    Title string `json:"title"`
}

const baseXkcdURL = "https://xkcd.com/%d/info.0.json"

func getComic(comicID int) (comic *Comic, err error) {
    url := fmt.Sprintf(baseXkcdURL, comicID)
    response, err := http.Get(url)
    if err != nil {
        return nil, err
    }

    err = json.NewDecoder(response.Body).Decode(&comic)
    if err != nil {
        return nil, err
    }

    return comic, nil
}

Getting started

Now coming to our basic version of the code down.
What it does is:

takes an integer array of comic IDs and loops over it
for each ID, retrieves the response from getComic and sets it in the map

As you can see, the code is pretty straightforward and should function effectively in most cases. But the problem comes with execution time.



func main() {
    start := time.Now()
    defer func() {
        fmt.Println("Execution Time: ", time.Since(start))
    }()

    comicsNeeded := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
    comicMap := make(map[int]*Comic, len(comicsNeeded))

    for _, id := range comicsNeeded {
        comic, err := getComic(id)
        if err != nil {
      continue
        }
    comicMap[id] = comic
        fmt.Printf("Fetched comic %d with title %v\n", id, comic.Title)
    }
}

A glance at the output can tell us that the output delivered is sequential as expected, since the each API call is made only after the previous one is done.

So the execution took well above 7 seconds, which would not be ideal if the server was dealing with heavy load at scale.

Making it concurrent

Compared to other languages, I believe that Go has much better concurrency support. We will be using goroutines here, they are lightweight threads that run concurrently and can be spawned easily, thanks to Go.

After modifying the main function to spawn goroutines, here's how it looks like



func main() {
    start := time.Now()
    defer func() {
        fmt.Println("Execution Time: ", time.Since(start))
    }()

    comicsNeeded := []int{11, 22, 33, 44, 55, 66, 77, 88, 99, 100}
    comicMap := make(map[int]*Comic)
  wg := sync.WaitGroup{}

    for _, id := range comicsNeeded {
        wg.Add(1)
        go func(id int) {
            comic, err := getComic(id)

            if err != nil {
                return
            }

            comicMap[id] = comic
            fmt.Printf("Fetched comic %d with title %v\n", id, comic.Title)
            wg.Done()
        }(id)
    }

    wg.Wait()
}

Okay, what's different?

We are creating a WaitGroup first in wg := sync.WaitGroup. The waitgroup can be thought of as a global counter which we can use to wait for all the goroutines to finish.
While we loop over the comicNeeded array, wg.Add(1) is used to indicate that we are creating a goroutine.
The go func(){...}() fires the anonymous function as a separate goroutine. The id argument is used to capture the loop variable at that point of time.
Inside the goroutine, we wait for getComic so we can append it to the map. Once that is done wg.Done() this indicates that this goroutine has finished.
And finally after the loop is over, we call wg.Wait(). Why is this necessary? When spawning of all the goroutines has been completed, the main thread has no work left to do, which will intuitively lead to its termination. However, it is undesirable, as it causes all the goroutines to quit. So in order to make the main thread wait till all the spawned goroutines are marked as done, we perform wg.Wait().

Phew, now take a look at the output.

Woah, a reduction in execution time by a huge factor! The calls are not sequential as each goroutine executes independently based on the CPU availability.

Conclusion

To wrap it up concurrency, depending on the application, can give huge performance boosts to your code. I wanted to do this using Channels at first but later realised that it could be done much simpler using just WaitGroups. But I do have a blog next planned with the use of channels in the same context.

Notes

Connection Pooling — what and why?

Sriram — Thu, 23 Apr 2020 07:47:09 +0000

I came across connection pooling recently when I was working on a large scale microservice in Clojure and realised the HUGE impact it has on performance even when you are talking about serving a couple of hundred users.

Having worked a lot in backend why didn’t I know this before? Maybe Django (my favourite backend suite) had abstracted it away in it’s ORM or I didn’t work in codebases where performance was paramount. 😛

But first what is a connection?

A connection can be formally defined as a way for a client to talk with the server. It is required to send commands and receive a result.

Different types of connections

For example, a browser talks to your favourite website using a TCP connection. Similarly a database connection lets you issue commands and receive answers in the form of a result set.

Connection pooling can be applied to any connection like a TCP connection, database connection or even a Redis connection. But in this article, I will be taking focussing on examples about database connections.

What is the problem with normal connections?

Assume we have a Postgres database and you want to run this query on it.

select chairs from dining_table;

To get the result, along with this query we need to provide the database details and our authentication details, usually the host, port, database, username and password. These are needed because before actually running the query, the program has to:

→ find the database

→ connect to it

→ authenticate our connection

→ use the given db

→ and then run our query.

Once the result is returned, the connection is closed. When we want to run a different query we need to start over again.

As you can see we this is time consuming. Authentication is a very expensive process and most of the times creating connections take relatively longer compared to the actual query they run. So it becomes very inefficient for us to create a connection for every query.

So instead of closing the connection, keeping it active and running all the queries using the same connection gets rid of this creation latency. But in a service, how do we share a connection between different clients? That is where connection pooling comes in.

Connection Pooling

Connection Pooling alleviates this problem by creating a pool of connections at the start and keeping them alive (i.e not closing the connections) till the end. Whenever some part of the application wants to query the database, they borrow the connection from the pool and once they are done with the query instead of closing the connection, it is returned back to the pool. As simple as that.

A connection pool example with one connection being idle

Using this manner, even a small number of connections pooled can serve a large number of requests as the overhead of authentication for every request is eliminated.

There are a lot of amazing connection pooling libraries out there like HikariCP, c3p0 etc. Most of these allow you to configure things like min-thread, max-thread, idle-timeout to make the connection pool suit our needs.

Performance Gains

For you to actually see how much of a difference connection pooling gives, I decided to run a simple select query multiple times in two ways:

Opening and closing a connection every time to execute the query
Keeping an active connection and running the query in a loop

I wrapped these two commands in a shell script to benchmark it and ran the script.

Output!

The output is shocking indeed. Though both the commands run the same query 100 times, the former loops externally in the shell causing the script to open and close a connection with Postgres every time to get the result.

While the latter opens a connection at start using your authentication credentials and keeps it alive till you close the shell. Every query that is run inside the Postgres shell uses the existing active connection so there is no extra latency other than the time taken for query execution. Thus using the active connection gives you a performance boost of 77x.

Conclusion

To conclude, connection pooling is quintessential to improve a backend service’s performance. It is not only limited to use with database connections but is also used widely in pooling TCP connections when it comes to interacting with other services.

Creating animations in Javascript using requestAnimationFrame

Sriram — Sun, 19 May 2019 07:37:03 +0000

Animations in Javascript? I bet keyframes are better._ I have almost entirely used CSS to create animations for my websites. In fact, I rarely use Javascript directly to touch the styles of an element. But I recently stumbled upon a tutorial using requestAnimationFrame for animations. I expected the usage of it to be complex, but it was very simple yet powerful.

Animations in JavaScript before requestAnimationFrame

Before requestAnimationFrame, it was common to see people use setInterval to update styles of elements so that it was animated similar to the given code below. For a smooth animation we need to match the display framerate, which is 60fps, so we need to execute our function for 60 times per second which translates to an interval of 17ms.

const progressBar = document.querySelector('#progress-bar')
let width = 0

const updateProgressBar = () => {
  progressBar.style.width = width + '%'
  width += 1
  if (width > 100){
    clearInterval(id)
  }
}

const id = setInterval(updateProgressBar, 17)

A function, which updated the style of the element, was executed repeatedly on set intervals. Though this did the job, it wasn’t an effective way. There were many disadvantages for this approach. The timer wasn’t accurate i.e the browser would give priority to other UI tasks over this. The function would keep executing even if the user is in some other tab and depending on the execution it meant higher CPU usage.

Now what is requestAnimationFrame?

requestAnimationFrame was developed to overcome the shortcomings of the setInterval/setTimeout approach providing a native API to run any type of animation. It takes in a function as it’s argument and tells the browser to execute that function before the next repaint.

It is very similar to setInterval except we are requesting the browser to execute the animation at the next available opportunity instead of predefined interval.

Browsers generally optimize execution based on load, battery and element visibility on screen. All the animations are grouped into a single repaint, thus reducing the number of CPU cycles required. The animations are also halted when the user switches to a different tab. Yay!

Now doing the same progress bar with requestAnimationFrame gives us

const updateProgressBar = () => {
  progressBar.style.width = width + '%'
  width += 1
  if (width < 100){
    requestAnimationFrame(updateProgressBar) 
  }
}

requestAnimationFrame(updateProgressBar)

As we can see, we call the requestAnimationFrame initially and then recursively keep calling it until the required width level is reached. Clearly, this syntax is much better than setInterval.

Gravity using requestAnimationFrame

Now let’s try to use requestAnimationFrame to implement (a more complex) animation for a Ball experiencing free-fall under gravity.

We will be building a page which creates a ball everytime the user clicks on the page and the ball falls to the bottom. We will be trying to create mimic gravity for the fall.

First we will write a function to create a ball-like element. The ball will be div (with border-radius 50%) positioned absolutely. We will pass this function the x, y coordinates received from the click event.

const createBall = (top, left) => {
  const ball = document.createElement("div");
  ball.classList.add("ball");
  ball.style.top = top + "px";
  ball.style.left = left - 25 + "px";
  document.body.appendChild($ball);
  return ball;
}

Here we are creating a div, adding the class ball and sets the top/left values before returning the created element.

Next we write a function for initialising the fall animation which creates a function to deal with styles and initialises the animation frame request.

const initFalling = ball => {
  const ballHeight = 100
  const acceleration = 9.8 / 60;
  const { innerHeight } = window;

  let fallingSpeed = 0;

  const animateFall = () => {
    const top = parseInt(ball.style.top);
    const newTop = `${top + fallingSpeed}px`;

    // To break the fall, when the ball is near the surface
    if (parseInt(newTop) >= innerHeight - ballHeight) {
      ball.style.top = this.innerHeight - ballHeight + "px";
      ball.style.background = "red";
      return null;
    }

    // Else set the top to the new value
    ball.style.top = newTop;
    fallingSpeed = fallingSpeed + acceleration;
    requestAnimationFrame(animateFall);
  };

  requestAnimationFrame(animateFall);
};

Let’s breakdown this function.

Every ball starts with a fallingSpeed of 0 and is accelerated with every execution. Since acceleration due to gravity is 9.8m/s per second and the browser executes our function 60 times each second (general display framerate), so the acceleration per execution is 9.8/60.

We write another function inside function and call it animateFall. This will be the main function which will be passed to requestAnimationFrame. Pretty straight forward stuff inside. We retrieve the top of the ball and add falling speed to it. We check if this newTop value is greater the window’s innerHeight. If it is not, then we set it to the new value and increment fallingSpeed before requesting an animation frame again. If the newTop is greater, then the ball has hit the surface so we return from the function.

We are nearly done, all we have to do now is create a event handler and chain these two functions together.

const onClickListener = event => {
  const { x, y } = event;
  const ball = createBall(y, x);
  initFalling(ball)
};

document.addEventListener("click", onClickListener, false);

The event coordinates and the positioning coordinates are inverted. That is x here is equivalent to the left in positioning and y is equivalent to the top. And skadoosh we have created a free falling portal.

We can still make this better

Dying Animation; added a dying animation based on the impact of the collision. The falling speed is an indicator of how long the ball has travelled in air. So we can add a fading animation in which balls which have travelled more fade faster and those which have travelled less fade slowly.
Randomness; added a random factor for the color and size of the ball.
Organize; orgainize the code into components using Typescript + Webpack.

When should I use this instead of keyframes?

Though the performance of both requestAnimationFrame and keyframes/transitions are very close, we can stick to CSS animations for most of the cases.

Animating using JavaScript becomes super useful if the animation depends on some state or data, like the example above where we managed the fall of the ball using JS. We can also use it to create more complex animations like staggering animations or trailing animations (cue: I will be making a tutorial on trailing animations next).

References

And…

Thank you for reading!

GSoC ’18 with WorldBrain : The Journey

Sriram — Tue, 14 Aug 2018 12:49:04 +0000

Hello World. This is Sriram coming straight out of a really exciting and productive summer. This summer, I got selected to GSoC through WorldBrain to work on their browser extension Memex. It proved to be awesome working there. Here comes the blogpost about my entire GSoC journey

Pre GSoC

As a freshman in college last year, I was very keen on getting into the GSOC. To take a step forward, I gave a shot at Zulip. Though that didn’t turn out well, it gave me an amazing learning experience. You can read more about that in this article I wrote a while ago.

With the hopes of getting into GSoC gone, I didn’t want to waste an entire summer. I decide to learn something new and went for the most trending framework at that point of time, React! Ended up getting quite a grasp of it over the summer and even refactored my old website completely in React. In no time, I started working on many more projects in React, enhancing my confidence in the area.

Time flew and soon it was February ’18. GSoC organisations list was up, and I was still confused over which one was I going to choose.

WorldBrain

Scrolling through the list of GSoC ’18 organisations, I was specifically looking for projects involving React. I found WorldBrain and their vision for the web caught my eye!

WorldBrain is an open-source software collective with the mission of making it 10X+ faster for people to organise, recover, share and discover the most useful and knowledge-expanding content on the web. Memex , which is there first product, is a free browser extension which solves one of the most frustrating experiences of doing online research: organising and finding websites again.

I was every excited to try their extension, Memex. I did and Oh boy I loved it, being a student myself, it proved really helpful in finding sites which I had already visited before. Soon, I got myself introduced to my peers, who happened to be very friendly. First, I had to choose the project I wanted to work on from their idea list. Although there were many interesting ideas in front of me, I went for the one that seemed relatively easy to work on. :D

The idea of this project was to show Memex’s search results a box alongside Google’s search results. Basically, I had to get the content script running in all pages; if the page’s URL matches the Google’s search url, fetch Memex results and render it on the page. All the discussion, implementation . and code of this feature can be found in this PR.

Memex results injected alongside Google search results

About the project

Even though the above mentioned one was a GSoC project, I finished it much before GSoC, which resulted me in changing my project to what it is right now - Comments and Annotations; with the help of Oliver.

WorldBrain’s vision is to have a p2p social network for collaborative web research. One of the important steps for that is the need for people’s interactions with content such as highlights, comments or ratings. These interactions would help an user know more about the authenticity, quality and useful information of every website they visit.

My project helps achieve this vision by adding the ground work for this. It adds the ability to highlight any piece of text on the internet and store it along with a comment. The user will be able to see the comments/annotations he made in each page he visits. With this established; features such as sharing the annotations within an user’s network, giving quality ratings etc. could be easily added in the future.

Work 💻

Fast forward to coding period: Vincent, an awesome developer at WorldBrain, had built the backend for a new Memex feature called Memex Link (previously known as DirectLink) which allowed users to highlight a piece of text and get an URL to share it. It was super cool. So my first tasks for the summer was writing the code to bring the Memex Link tooltip up in every page (PR #398) and making the demo UI prettier (Link to all my PRs related to this task). Soon Memex.Link was put into production and it turned out to be a really cool feature.

Memex tooltip in action with Annotate and Share buttons.

By this time, I had also started my work on adding a sidebar to display all the user’s annotations on each website. There were two versions to this sidebar: one on Memex’s overview page and the other as an overlay on every website. Getting the former up and running was relatively easier compared to the latter. After a quick discussion, I decided to go with the iFrame approach. Through the content_script I would inject a button ( called Ribbon ) and an iframe (which loads the sidebar stored as a separate html) and when the user clicks the Ribbon it shows the sidebar. After some struggle, I got the initial design up and running on both, the overview and the iFrame.

I was planning on tackling the storage of annotations next, but the initial designs weren’t really pleasing and I was given an UI overhaul to work on. For the next couple of weeks I worked on the UI and all the styling-related bugs that popped up. Oliver wanted it all pixel perfect. Although it was a struggle to get all the minute details done, it resulted in a more intuitive and aesthetically pleasing UI.

Memex sidebar with new UI on top of a webpage containing few annotations

Next came the storing of annotations with tags, which went smoothly compared to the previous parts. With the storage part done, an MVP was nearly ready. Finally, the part which I found most exhausting were the interactions between the frame and it’s parent page (for example: highlighting/scrolling on hovering the annotation container in the iFrame).

Although, there were already existing methods to communicate between the extension scripts there weren’t any to support communication between a website and an extension page inside an iframe. So I wrote my own Class which served as a wrapper around the window.postMessage allowing the execution of remote functions on both the sides.

Production 🎉

After tons of nifty feature additions, repercussions and bugs, we finally got the Comments and Annotations into productions. 🎉 It is LIVE and being used by 8000+ Memex users right now. Do check it out, by downloading their Chrome/Firefox/Vivaldi extension. It was such a rewarding feeling seeing my work being used by others in production! ❤

The last week was dedicated to cleaning up, refactoring and writing tests. And right now as am finishing up this article, I’m working on adding UI tests with Jest + Puppeteer.

Demo

Important Links

Comments/Annotations Pull Request

All Pull Requests during GSoC

GSoC Proposal

My Github

To sum it up

There were a lot of things that I learnt through the course of GSoC.

Working in a professional environment exposed me to so many new etiquettes like the git flow, stand-ups etc.
Realized the need of clean code and an organised file structure. The importance was legit visible when I was working with huge project directories.
There were a lot of bugs which popped up as a result of some silly typo or negligence. So realized that testing thoroughly before pushing it is very critical.

Conclusion

It was a reminiscing experience working with everyone at WorldBrain. I made a lot of mistakes and there were times where I slacked off or was not able to complete all the tasks but thanks to everyone, especially Oliver, Vincent and Jon for always being there to help out and guide me!

~ Sriram