-1

I'm working (for the first time) on developing a PHP application driven by a PHP RESTful API (probably using peej/Tonic). Coming from an application with direct access which might make 20 different database calls during the course of a page load, I am trying to reconcile the fact that 20 API calls = 20x handshakes (which can be improved by Guzzle persistent connections) but also 20x connections to the database.

I believe that with better programming and planning, I can get my required API calls down to 4-5 per page. At this point:

a) Is it not worth considering the latency of 5x database connections + 5x handshakes per page load on account of all the other available optimisations?

b) Is there an existing method by which this can be mitigated that I've thus far failed to find?

c) I believe it violates the principles of RESTful programming but if I had a single API method which itself gathered information from other API endpoints (for instance, GET suppliers WHERE x=y then GET products for supplier), is there a documented method for internal API interaction (particularly within peej/Tonic or other frameworks).

Improve this question
2
  • You could implement a batch request endpoint like Facebook does. developers.facebook.com/docs/graph-api/making-multiple-requests, or allow inclusion of related data like Fractal does (fractal.thephpleague.com/transformers - see "Including data") Commented Jul 19, 2016 at 12:58
  • If you back-end DBMS supports it, make sure that its query cache is enabled. On my stack, a Qcache hit returns faster than any other complex component I could add to improve query response times. Commented Jul 19, 2016 at 13:10

1 Answer 1

Reset to default
1

Remember that the client should be "making 'a request' of the server," which is obliged to fulfill "that request." The server might "execute 20 different database queries" to prepare its response, and the client need not know nor care.

The client's point-of-view becomes, "I care what you tell me, not how you did it."

If you did wish to send query-responses directly to the client, for the client to "do the dirty-work" with these data, then you could still design your server request so that the server did many queries, all at once, and sent all of the result-sets back ... in just one exchange.

Your first priority should be to effectively minimize the number of exchanges that take place. The amount of data returned (within reason) is secondary.

Also consider that, "when the server does it, the work is naturally synchronized." When the client issues multiple asynchronous requests, those requests are, well, "asynchronous." Consider which strategy will be easier for you to debug.

If the server is given "a request to do," it can validate the request (thus checking for client bugs), and perform any number of database operations, perhaps in a TRANSACTION. This strategy, which puts the server into a very active role, is often much less complex than an interaction that is driven by the client with the server taking a passive role.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.