- All Repo calls are isolated to the context’s within your application
I have lots of context methods that several parts of my phoenix applications use. Depending on what I’m doing with resources I may need different relationships preloaded on it. Is it common to just preload all resources on the context methods with whatever everything needs access to?
Or are people using
Repo.preload outside of context’s to load up the additional data they may need when and where they need it?
What I have right now is lots of data that is being queried and loaded and sometimes that data isn’t even being used. A few alternatives I’ve thought about over the past few weeks:
Add additional public functions for each different way data is being used. I’m not a huge fan of this idea only because the surface area of the public API into your system becomes large. Though it’s tame-able with using ecto composable queries to reuse a lot of internal building of the queries.
Expose public composable functions that the “clients”(code needing the data) put together with whatever data they need. This is nice in that the clients are able to ask for only what data they need, what I don’t like is now you need to pass the query back to the context for it to execute ( assuming that all
Repocalls are isolated to the context modules).
id |> Users.with_id() |> Users.get()
id |> Users.with_id() |> Users.with_accounts() |> Users.get()
id |> Users.with_id() |> Users.with_accounts() |> Users.with_posts() |> Users.get()
with_posts/0are all composable queries that return the ecto query and
Users.get/1would take a
queryand basically call
I haven’t looked that far into GraphQL but it would be interesting to see if that concept where the client could ask for what it needs and the server would just hand it back could be brought into this situation. Where my “client” another module could give a graphql query to my context and it would give back what it’s asking for. I’m not sure if this is possible now?
How are you handling this in your elixir applications?