Where should complexity live?

[jinjagit]

Currently, our api has the most complex operations related to delegations in the core layer. E.g. creating delegations involves upserting participants, voting_methods and delegations, and selects some, all or none of these depending on different contexts (global vs proposal specific, for example) all within the lib/liquid_voting/delegations.ex file - within what I call the 'core' level.

Conversely, we have the most complex operations related to votes in the absinthe layer. E.g. creating votes involves upserting participants, etc. (many similar complexities to creating delegations, with some differences), mostly within the lib/liquid_voting_web/resolvers/voting.ex file.

This seems like a somewhat arbitrary choice, that has been developed in both directions.

In the interests of making our codebase easier to understand and develop, I think we should decide on the best layer to locate the more complex logic. I don't, however, feel the resulting refactoring is urgent at this point.

Thoughts?

[oliverbarnes]

Good question :) in principle the business logic layer on Phoenix is the Context: https://hexdocs.pm/phoenix/contexts.html - so the absinthe/resolvers layer should forward to a Context to take care of the nitty gritty.

This issue from a few months ago is related to this, too: #155

[niklaslong]

I like this question! First off, I'd agree that the refactor isn't urgent. The code is fairly readable and there's only a slight blurring of concerns at this point imo. The simple "endpoints" are calling on the standard CRUD functions in the Voting module, no real issues there as there's no error handling involved (e.g. listing votes). Create vote could indeed be refactored, the case statement feels like business logic to me, especially the call to create the vote and could be moved to another module as @oliverbarnes pointed out ☝️.

But again, this isn't a crucial refactor as the separation of concerns is still fairly clear and the code is quite readable.