Balancing Elixir Context Design with Flexible Web API's

I’m not following how you think Phoenix Contexts increases coupling. It seems like they make sense because they decrease coupling. That inherently involves abstraction. list_users abstracts the Ecto API (which is itself already an abstraction over the SQL or whatever you’re using as a Repo) and this abstraction has made your list_users function a bit complex.

In a Rails app you’d probably use a new Class to handle the complexity, in Elixir I would start by using arity and pattern matching to keep the logic separated within the context, rather than using a single function. If necessary you could add another module to your API context.

def list_users, do: User |> list_users
def list_users(%{filters: filters}), do: filters |> build_filtered_query |> list_users # this could also go in the API context so this always works on a query
def list_users(query), do: query |> Repo.all

If you had to do a lot of that for a lot of schemas I would probably consider a macro.

I use the following pattern…

# context
def list_users(queries \\ & &1) do
  from(User)
  |> queries.()
  |> Repo.all()
end

# controller

Accounts.list_users(fn query ->
  query
  |> Accounts.include_user_profile()
  |> Accounts.filter_non_executive_users()
  |> Accounts.filter_users_by_company(company)
  |> Accounts.order_users_by_first_name()
end)

All of the needed queries are publicly exposed from the context. This is very explicit, dependency-free, and dead simple to find the call sites where you might be using a specific query.

I previously experimented with a more dynamic method via a package, but found it to be a little more difficult to maintain and more magic than needed. That dynamic method is wrapped up in the TokenOperator package. There is a good bit of discussion on some of the things you mention in the thread for TokenOperator and another for the QueryBuilder package.

Nice and straightforward. The only suggestion I’ve is to import Accounts either at module level or at function level to save some typing.

I’ve tried to avoid importing in a lot of cases for explicitness/searchability, but import is totally an option to slim down those queries.

Thanks for your input, I probably didn’t word if well but I agree contexts decrease coupling, not increase it. I think if you are referring to the part where I reference the json ecto builder library I built, what I was meaning to say was that library I created couples the Web api with ecto/db.

In terms of your solution, it makes sense to me and its how I’ve approached it in the past, the part which has felt slightly icky about it was that for complex sets of filtering, for example operator types (gt, lt, eq etc) and nested filtering. You end up in the context function having to parse a fairly complex query, which sometimes seems a bit bloated for whats trying to be achieved.

If taking in dynamic query parameters is more the rule than the exception for your app you might also take a look at packages like filterable, filterex, inquisitor, ex_sieve, rummage_ecto. I haven’t had the need for them, but they are catered to that sort of thing.

Very informative list, thank you!

Thanks for your feedback, that’s a nice pattern, I do like the fact that it gives extendability to a query, without exposing the inner details of the list_users function.

I think my only criticism would be that, where it doesn’t expose the repo etc, the callback function is still essentially telling the caller of the code that we are using ecto queries in the inner workings of the function.

Perhaps I’m reading too much into things, to me what seems to the ideal solution would be one where the list_users (or any context function) allows extendability through some kind of parameter format, but the internal function usage is hidden from the caller, therefore we could parse the parameters into an ecto query, however if it it ended up being some different method of data retrieval, say a separate call to another API etc it still wouldn’t matter to the caller of the function, and the inner function could format the request to the specific data retrieval method it is using.

It seems like the libraries you added achieve this. In fact, I have I’ve seen the QueryBuilder library before, it’s probably something I will look at further.

Thanks.

My TokenOperator package includes that extra level abstraction that you might be looking for. I like the resulting clean interfaces, but it didn’t really improve my day-to-day clarity and maintenance of the codebase. Here are some goals of that project that might jibe with a library you use or something you write.

I would only note that the aforementioned package-less pattern is, at its core, just a context function that takes an optional argument. That argument is expected to be a function (anonymous or otherwise) that takes one argument (an Ecto query or otherwise). You can do anything in that function. In practice, it has always been an Ecto query for me, but there is nothing precluding you from injecting something else there, to the extent it provides you with an interface you like.

This is an interesting pattern. I’ve actually been writing my context’s function to return query objects and then just piping them like this:

# controller

query =
  Accounts.User
  |> Accounts.include_user_profile()
  |> Accounts.filter_non_executive_users()
  |> Accounts.filter_users_by_company(company)
  |> Accounts.order_users_by_first_name()

users = Repo.all(query)

This is something where I don’t feel like I understand what is recommended by the Phoenix team / community regarding contexts. Your solution hides Repo inside of the context, and I could see the advantage of that, I guess, though practically it hasn’t been much of a problem, yet.