1

Here's the context : we're actually using the basic web stack, and our website builds HTML templates with datas it gets from the database directly.

For tons of reasons, we're splitting this into two projects, one will be responsible for talking with the database directly, the other one will be responsible for displaying the datas.

To make it simple, one is the API, the other one is the client.

Now we're wondering about how we should ask our API for datas. To us, there are 2 totally different options :

  1. One request, one route, for one page. So we would get a huge object to use which would contain everything needed to build the corresponding page.
  2. One request for one little chunk of data. For example on a listing page, we'd make one request to get datas about the current logged user and display its name along with its avatar, then another request to get every articles, another request to get datas about the current page category...

Some like the first option, I don't like it at all. I feel like we're going to have a lot of redundance. I'm also not sure one huge request is that much faster than X tiny requests. I also don't like binding data to a specific page, as I feel like the API should be (somewhat) independant from our front website.

Some also don't like the second option, they fear we overcharge the server by making too many calls, and I can understand this fear. It also looks like it'll be hard to properly define the scope of what to send, what to not send without any redundancy. If we're sending only what's needed to display a page, isn't that the first option in the end ? But isn't sending unneeded information a waste ?

What do you guys think ?

Steve Chamaillard
  • 2,289
  • 17
  • 32
  • 1
    It's hard to give you an objective answer, as often, it depends ™. It really depends on what you are trying to achieve, in which context data are going to be used. The first option is likely to be the easier to implement, and depending on how smart you are able to fetch / process the data, it may easily evolve in the second option. Having a lot of requests is indeed not recommended especially using the current implementation of HTTP and the cost of creating a new Request, however, you may use HTTP Cache, the same applies to the first option too. – Boris Guéry Jan 16 '17 at 13:48
  • You may also be interested in [Relay](https://facebook.github.io/relay/) which can be inspiring in your case. – Boris Guéry Jan 16 '17 at 13:49

1 Answers1

2

The first approach will be good if getting all data is fast enough. The less requests - the faster app. Redundancy I think you mean code redundancy because sending the same amount of data in one request will be definitely faster than in 10 small non-parallel ones (network overhead). If you send a few parallel requests from UI you can get performance gain of cause. And you should take into account that browsers have some limitations for parallel requests.

Another case if getting some data is fast but another is slow you can return the first data and on UI show loading image and load the second data when it will come. It will improve user experience showing the page as fast as possible.

The second approach is more flexible as you can use some requests from other pages. But it comes with price - logic with making these requests (gathering information) you need to move to UI code making it more complex. And if you need the same data on another app like mobile you have to copy this logic. As a rule creating such code on backend side is easier.

You can also take a look at this pattern which allow you to locate business/domain logic inside one service and “frontend friendly” logic to another service (orchistration service).

Community
  • 1
  • 1
Vasyl Zvarydchuk
  • 3,789
  • 26
  • 37
  • Thanks for your answer. Yes I mean code redundancy.By the way this is all on the backend side, as the UI will be talking to the website backend, not to the API backend directly. So I guess both options will get to the same result browser-wise. If the backend talks to another backend, does that change what you think about the second option ? – Steve Chamaillard Jan 17 '17 at 09:05
  • Backend-to-backend is good if of cause some logic is behind this and if it will improve your system. There are some Microservices patterns based on this like I provided in the answer. Or, for instance, when you have a message bus and one backend app pushes messages to it and another reads them - it's server-to-server communication but via some message protocol - not http. – Vasyl Zvarydchuk Jan 17 '17 at 14:31