Along the current line on the dev branch of formulating graph transformations as Treatments, we can think of "building the recommendation graph" as just another treatment.
Once the treated graph is built, we could then apply a Recommend treatment which removes the lower-weighted edges for each add-on, and stores a _recommendation_graph in the recommender instance. The recommend() function would then just look up from the precomputed graph, rather than sorting at runtime as it does now.
This makes most sense if the number of recommendations (limit) is considered a static property of the service. If we intend for clients to be able to request different numbers of recommendations at runtime, recommend() should compute the recommendation list dynamically, as it does now (excluding the tie-breaking computation as per #48).
Along the current line on the
dev
branch of formulating graph transformations asTreatment
s, we can think of "building the recommendation graph" as just another treatment.Once the treated graph is built, we could then apply a
Recommend
treatment which removes the lower-weighted edges for each add-on, and stores a_recommendation_graph
in the recommender instance. Therecommend()
function would then just look up from the precomputed graph, rather than sorting at runtime as it does now.This makes most sense if the number of recommendations (
limit
) is considered a static property of the service. If we intend for clients to be able to request different numbers of recommendations at runtime,recommend()
should compute the recommendation list dynamically, as it does now (excluding the tie-breaking computation as per #48).