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

**URL:** <https://discuss.dgraph.io/t/should-i-store-results-uids-of-the-nodes-from-a-resource-eating-recommendation-dql-function-which-fetches-e-g-instagram-news-feed/16065>\
**Category:** Dgraph\
**Tags:** kind:question\
**Created:** [November 16, 2021, 4:13am UTC](https://discuss.dgraph.io/t/should-i-store-results-uids-of-the-nodes-from-a-resource-eating-recommendation-dql-function-which-fetches-e-g-instagram-news-feed/16065 "2021-11-16T04:13:26Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Juri](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/juri/32/8872_2.png) [@Juri](https://discuss.dgraph.io/u/Juri)\
**Post date:** [November 16, 2021, 4:13am UTC](https://discuss.dgraph.io/t/should-i-store-results-uids-of-the-nodes-from-a-resource-eating-recommendation-dql-function-which-fetches-e-g-instagram-news-feed/16065/1 "2021-11-16T04:13:26Z")

</div>

`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](http://discuss.hypermode.com/t/build-a-realtime-recommendation-engine-part-2-dgraph-blog/1702):
>
> This is part 2 of a two-part series on recommendations using Dgraph. Check our [part 1 here](https://blog.dgraph.io/post/recommendation/). 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 …

---

<div class="post-metadata">

**Author:** ![dpk](https://avatars.discourse-cdn.com/v4/letter/d/ea5d25/32.png) [@dpk](https://discuss.dgraph.io/u/dpk)\
**Post date:** [November 17, 2021, 5:04pm UTC](https://discuss.dgraph.io/t/should-i-store-results-uids-of-the-nodes-from-a-resource-eating-recommendation-dql-function-which-fetches-e-g-instagram-news-feed/16065/2 "2021-11-17T17:04:53Z")

</div>

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.