0

I'm trying to understand what is the best way of migrating a website that works in a single layer and gets all the data via an ORM, to one that uses multiple layers, using an API backend to get the information needed to display a page.

In the project I'm working on, we have code like this, where data is retrieved via a Doctrine ORM:

$accountAddress = $sfUserProfile->getCustomer()->getAccount()->getAddress();

Doing a naive translation of that to an set of API calls would result in 4 api calls. Although they may not be that slow individually, if we made one api call for each DB access that we currently have it would be incredibly slow.

That could be changed to a far more specific call like:

$backendAPI->getAddress($sfUserProfile);

which would reduce those 4 API calls down to a single one, which is better. But it still leaves all the other queries that would need to be run for that page to be converted to separate API calls. I could write an api call that gets all of the user information required to display the user account information page in one go:

$info = $backendAPI->getInfoForAccountPage($sfUserProfile); Where $info contains a set of simple entities (not ORM entities) e.g. : $info = array( 'customer' => $customer, 'account' => $account, 'accountAddress' => $accountAddress ); (Or probably I'd create for each page a specific 'info' class to enforce clarity on what info is available).

Is it 'correct' to write really specific API calls? Or what is the preferred method for avoiding having to have too many API calls to display a page?

The specific API call way seems sensible when there is a small known set of data that needs to be retrieved to display a page, but it seems like it might lead to having to write a lot of API end-points, so is there a better way of handling the problem?

1 Answer 1

1

It sounds like your API is too granular; that is, you're retrieving chunks of data that are too small.

This code

$accountAddress = $sfUserProfile->getCustomer()->getAccount()->getAddress();

would all run on the server, behind your service, so it's not four service calls, necessarily. Rather than returning an account address from your service, you should return the entire customer object.

2
  • Obviously one benefit of an ORM is that you can traverse across different objects e.g. from 'customer' to 'item bought' to 'seller'. Is there a good way of delineating where one composite object ends and the next begins?
    – Danack
    Oct 9, 2014 at 15:47
  • 1
    Your functional software requirements and resulting design dictate that. Think about the information that an Invoice contains. If you were to construct a single ViewModel object to hand to a web page for display, what data would that ViewModel object have to contain? Oct 9, 2014 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.