2017-06-07 Meeting notes

Date: 07 Jun 2017

These notes are based on discussion of the end of the Core team's Sprint Showcase as well as discussion immediately after it.

Some performance-related work was done in Sprint 27. Specifically, the size of individual requisitions return to the UI was cut by about 30 - 40 percent. Additionally, becasue the requisition /seach endpoint now exclusively returns IDs, its return size has been cut drastically (perhaps 99%).

In descending order of priority, ideas for further continuing to improve performance include:

Remove the default inclusion of non-full-supply products from responses

Currently, every endpoint which returns a RequisitionDTO includes all non-full-supply products along with it. In Malawi's case, there are over 1,000 of them, and each requires a dedicated lookup. The UI doesn't typically use these non-full-supply products, and it's not clear that other clients need them either. Removing them from automatic inclusion along with the RequisitionDTO would vastly improve performance for nearly all of our requisition-related endpoints.

Each endpoint which retunrs RequisitionDTO could potentially coorespond to a new one which would be added. The new ones would act just like the originals, but wouldn't return the non full supply data.

Alternatively, a mechanism could be added throughout the API which would allow client to specify that certain which result properties should be included/excluded. This would likely look and behave like Hibernate's lazy loading feature.

If the core team were to decide on API changes, the Malawi team can likely implement them.

Amalgamate Endpoints

As described here, we could "stop using search endpoint on the Create/Authorize view. Currently two endpoints are used to create appropriate period list on UI. It would be good to move this on the server side and create a single endpoint (or modify existing one) that would return a list of available periods for the given facility and program."

Discussion during the showcase suggested a preference for creating a new endpoint to combine functionality rather than for modifying the existing endpoints.

If the core team decides on these API changes, the Malawi team can likely implement them.

Fine-Tune the UI

As described here, the UI seems to make a redundant GET request to /api/requisitions/<id>. In this scenario and perhaps others, the application would benefit from client-side caching.

Move pagination from application to database layer

Loading n number of items into memory and returning just a small subset of them seems inefficient. It's done, however, because we application-logic is necessary in order to check user permissions on each object to determine whether they're candidates for being returned to the client. These checks determine:

A) Which individual objects should be returned within a paged dataset
B) The total size of the dataset potentially available to the user. (This datum is included along with each paged response)

Determining how to move this logic to the database layer would require a dedicated spike: OLMIS-2681 - Getting issue details... STATUS .

Using "Exists" methods to alleviate the need for object retrieval

Adding something like an exists(ID) method to the base class of every entity would probably be easy. It could be overloaded to take names or codes where need be. Because we're using Hibernate's lazy loading feature to pretty good effect, though, the performance improvement would likely be marginal.

Additional areas to explore

General caching strategies.
Providing GET endpoints which accept sets of IDs and return all corresponding object which exist.
OLMIS-2680 - Getting issue details... STATUS