# How To Parallelize Ruby HTTP Requests

DevFeed: [How To Parallelize Ruby HTTP Requests](<https://devfeed.tech/articles/how-to-parallelize-ruby-http-requests-21058.md>)

Original publisher: [Read original article](<https://jakeyesbeck.com/2016/01/10/how-to-parallelize-ruby-http-requests/>)

Published: 2016-01-10T12:00:00Z

Content type: tutorial

Language: en

Sources: [Jake Yesbeck](<https://devfeed.tech/sources/jake-yesbeck.md>)

Topics: [Ruby](<https://devfeed.tech/topics/ruby.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [API](<https://devfeed.tech/topics/api.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [Development](<https://devfeed.tech/topics/development.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>), [Back end](<https://devfeed.tech/topics/backend.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [development](<https://devfeed.tech/tags/development.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [http](<https://devfeed.tech/tags/http.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [web-development](<https://devfeed.tech/tags/web-development.md>)

## AI overview

This tutorial explains why managing and parallelizing Ruby HTTP requests matters in a Ruby on Rails web application backed by an external or internal API. It presents a history page whose user, favorite, wishlist, and transaction data require separate API requests, and describes how sequential retrieval can make the page slow as request counts grow.

## Source excerpt

It turns out that managing web requests is quite important when doing web development. A web application backed by an external or internal API can issue a lot of requests when rendering a seemingly simple web page. How those requests are made and in what order is very important. With improper parallelization, an end user's entire experience can go from delightful to horrific in a matter of seconds. The Build Up A basic Ruby on Rails application might have the following features: A User can create a favorite of an item, creating a FavoriteItem. A User can add an item to their wishlist, creating a WishlistItem. A User can buy an item, creating a TransactionItem. Each model this system uses is backed by an API. User, TransactionItem, WishlistItem, and FavoriteItem models all require a remote HTTP request for their information. As a web application experiences growth, this structure is not uncommon. The same API might back a mobile app, website, and any other internal tooling to help this company with its day to day affairs. The API that this application uses works in a two phase manner: A user can be requested by their id. /users/:id returns a User corresponding to the given id. Each supporting model is requested with the same user_id. /users/:id/favorite_items will return an array of FavoriteItems for the specified User. The contract of this API is for all intents an purposes, non-negotiable. In-lined data or other request saving patterns are not available, the client must use the API as provided. Sequential Approach Within this example application, the most request intensive page is the User's history page. The history page consists of everything the user has done. Items a user has added to their favorites resulting in FavoriteItems, Items bought by the user resulting in TransactionItems, and Items added to a user's wish list resulting in WishListItems. To complement the (ex/in)ternal API, two helper methods exist on each model: remote_find which accepts an id or arr