Should I store results(uid's of the nodes) from a resource-eating recommendation DQL function which fetches e.g instagram news feed?

[Juri]

var(func: uid(sc), orderdesc: val(sc), first: 50) @filter(not uid(user)) {

if I have a big recommendation DQL function (which consumes much performance/resources because it touches many nodes) that generates personalized content, for my example: an Instagram news feed

I of course don’t want to fetch directly 300 posts.
But I also can’t do after the first fetch this:

var(func: uid(sc), orderdesc: val(sc), offset: 50, first: 50) @filter(not uid(user)) {

because that would re-run the whole function. So, what’s the best practice handling that? Immediately returning the 300 uid’s, and then the client can just fetch these 300 posts through get queries? or is there a better solution?

---

---

---

source:

Build a Realtime Recommendation Engine: Part 2 - Dgraph Blog

This is part 2 of a two-part series on recommendations using Dgraph. Check our part 1 here. In the last post, we looked at how many applications and web apps no longer present static data, but rather generate interesting recommendations to users. There’s a whole field of theory and practice in recommendation engines that we touched on, talking about content-based (based on properties of objects) and collaborative (based on similar users) filtering techniques based on a chapter from Stanford …

[dpk (Ehhh)]

That’s probably close to the best solution. You could store those 300 uids in redis, or similar, and then make another request to get all of the data from Dgraph for a subset of those 300 (say the top 10, or whatever you’d show the user on first page). When the user reaches the end, they send a request for the next page, and you’d just get that subset of uids from redis and ask Dgraph for all of the data about those specific nodes.