How to avoid HTTP request overload when consuming REST API?

Question

I have a REST API made with Laravel and a Webapp (which uses the features of this API) made in Angular.JS. My Webapp is a unique portal for registered users, but now I’m creating a website so that unregistered users can just check a few things.

I decided to make a normal site because this way the searchers can index the site more easily and this should help improve the position of the site in the results of searches in google, for example.

However now I am facing a big problem. My idea was for the site to take advantage of the features the API already provides (so you don’t have to make new implementations). So far so good, it worked, but it was very slow due to the overload of HTTP Requests. Basically when you click on a link on the site an HTTP Request is generated and when the server fetches the content in the API another HTTP Request is generated.

In my local development environment, simple access to a page with a list of items provided by the API already takes 2.5 seconds, leaving me very concerned about the performance that this will have in other scenarios. In the end this seems to me that it is very advantageous to have an API for Webapps and Apps but very bad for Sites.

My questions are: How do I fix this? Is this a price to pay for using an API? Is there anything I can do to avoid this request overload? Some plugin, package or network schema?

Answer 1

This is more a matter of architecture than about REST Apis. Any applications, technologies or platforms that do not take into account possible usage loads may become slow.

One of the techniques that applications with high data traffic use is caching, or temporary storage. The idea is to prevent access to resources that consume processing time or enter a standby state (such as access to bank, disk and LDAP, for example).

Some levels of caching that you can implement:

• Bench: If your app is spending a lot of time waiting for a response from a query or stored Procedure, consider storing reasonably static search results in temporary tables (also called staging Tables).

• DAL (Data Access layer): Whenever possible, implement a mechanism that stores the result of queries made to the database in memory (Memcached, Redis) and re-use the result obtained instead of consulting again.

• Distributed cache: If you have multiple servers performing basically static queries in the same database, use a distributed cache engine to store your data. This will allow only one query to be made to the bank.

• Result cache of GET operation: You can add a header to the reply stating that the value will not be changed for a certain period of time, thus preventing new requests from the web application.

You can also implement several of these techniques in parallel.