CODEWITHSUNDEEP
apirestmobilearchitecturewebserver
saw
saw

Reputation: 175

Who talks to API (REST) ? Web client vs server?

In my app architecture, I have the following components:

The mobile is talking to the api, that is obvious. However, I was wondering which one of the web components should talk to the api.

At the beginning, I started making it server-side. And then I realized the server is simply calling the api, which the client can do as well - so why not delegate those calls to the client? that is:

  1. request: client -> server -> api
  2. response: api -> server -> client

we get:

  1. request: client -> serevr + client-> api
  2. response: server -> client, api -> client.

It has the advantage that our server has to make fewer network calls, hence reduced bandwidth. Now the client may need a bit of increased bandwidth, but it doesn't need to deal with all the users. Also, the client overall loading time isn't increased (I think?), since the client will have to wait for the api response anyway; whether it comes through the server or not.

Hence currently, my web client is talking directly to the web. However, it feels a bit weird, specially regarding authentication.

  1. Is that the right choice?
  2. Is there a better choice between the two?
  3. Are there more advantages or disadvantages for this choice

Upvotes: 6

Views: 6322

Answers (2)

Carlos C
Carlos C

Reputation: 677

This question has been out there for a while but I'll add an answer just as a reference.

Client side rendering affects the initial load because the client (browser in this case) first has to receive all the javascript code from the web server and then make another request, this time to the API server, to get the data.

The other problem is SEO. Web crawlers don't handle javascript rendering (Google is the only claiming improvements in the matter). They just expect html as a response to their requests and a page with no data is useless for indexing purposes.

To mitigate this problems a mixed approach can be taken, the so-called universal (formerly known as isomorphic) app. This is an application that can be rendered on both, the client and the server. It will have the benefit of client-side apps, but the server-side rendering will feed the web crawlers and will take care of the first load. The universal approach is very feasible nowadays because JavaScript can run on both the server and the client. Thus, most of the code can be shared.

There's a really good blog entry in airbnb that talks about it: http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/

Upvotes: 1

allen-smithee
allen-smithee

Reputation: 671

Configuring your client to operate through an intermediate web server is not a bad setup and probably preferable.

If your web server is just serving static content and piping API requests to the backend then it can probably support the traffic of many API instances. This means you could add capacity by having multiple API instances and have the web server load balance across them.

In addition you can reduce the attack surface of your hosting environment by having the API only accessible on the internal network and route calls through the publicly accessible web server. This way you can also choose how much of the API interface to publish.

And lastly you can handle authentication in one place. If authentication is handled by the web server, and it checks the authentication of each call before routing it to the API server, your API server has one less thing to worry about (this assumes your API server is only accessible on your internal network as above.) You can even implement authentication schemes at this point so that users only have access to a subset of the API server interface.

Upvotes: 2

Related Questions