Using GenServer to Reduce Database Calls in Phoenix

Background: I’m looking to build an app that calculates a user’s “friends”, “friends of friends”, and “friends of friends of friends” - basically on every HTTP request.

Question: If this list if associated users could get really long (only grows over time) - would it be more performant to perform a database query each time, or use an approach where each user has their own process/GenServer where the list lives? If the second, any resources or direction on how to best think about / architect this?


You could cache the results in an ets, for one.

Do you need list of that friends or you just count them? If you need only count them, then you can denormalise your DB or create materialised views that you will refresh periodically.

1 Like

This is more the realm of graph databases. You can ‘do’ it in postgresql by adding a graph extension or more slowly faking it via path encoding (though that will require 9 extra fields to do efficiently I think?) or slightly less performant by row-caching in postgresql the known friends with triggers to update over time.

1 Like