I’m starting this topic in response to the recent work related to performance improvements that we are doing. I’d like to discuss the options that we have and should consider when it comes to performance improvements to endpoints that return very large datasets. A good example are FacilityType Approved Products. Per non-functional requirements analysis, a country may be managing up to 10000 FTAPs in a single program, so that’s a number of them that requisition initiate is supposed to fetch. A single FTAP contains a whole representation of an orderable (+ ProgramOrderables) and facility types with all related resources. This is making the representation even of a one approved product quite big.
Of course, the long term plan is to have the orderables versioned and cached on the UI. This is a valid approach, but since it is a solution that we won’t be able to implement in the nearest future, let’s not focus on that in this topic. Let’s discuss what options we have to deliver the best performance boost in the next months (v3.6 - v3.7).
One thing that we are currently doing is adding the expanded resource pattern (http://docs.openlmis.org/en/latest/conventions/codeStyleguide.html#restful-interface-design-documentation) This helps us limit the size of the response, while still allowing clients to get the full representation where needed (or only parts they are interested in).
Of course, we are also looking into any other query improvements/optimization that we can make, but the biggest problem with resources like FTAPs is the size of the response, the time required to convert that response into JSON, send it over the wire and then deserialize on the client side. All of this takes a considerable amount of time if the representation is several megabytes big.
What I’m looking forward to in this topic are any additional solutions/ideas that we can consider for the upcoming weeks, and that we can deliver in the performance work.