Best way to propagate state/dependencies?

pmjoe

I’m having some questions regards state propagation and making the cost testable. The application is structured in a way that the concurrency comes from the HTTP requests, so the webserver will create a new process for each request. Once the request hits my code the code doesn’t have any parallel execution or things like GenServers at all. It’s plain functions calling functions.

And now is the question, imagine that I have 3 layers:

handler/http
service
persistence

The handler calls the service and the service calls the persistence. But to avoid hardcoding the dependencies I need to have some way to pass these values around. My first try was with a centralized state agent, it works but not ideal, I can’t even run parallel tests because they all depend on the same global state agent. My next approach would be to do something like a context that is propagated through all the requests. What do you guys think of this approach?

I should always depend on the services that are passed to my function, so my signature would be something like this:

def send_link(%{user_service: user_service, expiration: expiration}, email) do
end

Instead of this code have a hard dependency on some service, like the user service, it can simply receive it as the first argument.

Wait for some opinions, is this good? should I do something different? Any recommendation of docs to learn more about state management with Elixir?

1 comment

#state

0 696 1

2021-01-17 16:21:13 UTC

Showing Posts 1 to 1

Show Best Posts
Show All (oldest first)
Show All (newest first)

al2o3cr

It’s arguable whether dependency injection in this style makes code “more testable”, but it’s not debatable that it makes it much harder for the compiler and other tools. Code like:

user_service.some_function(arg1, arg2)

can’t be checked at compile time for correctness like ActualUserService.some_function(arg1, arg2) can.

I’ve seen this cause failures more than once in applications with strongly-injected “unit tests” that featured mocks that didn’t have the correct signatures. 100% code coverage, all green, 100% broken in production.

Instead of injecting a module for “persistence” into the functions in the “service”, consider approaches like defunctionalization that would instead make the “service” and “persistence” functions that are chained together by the integrating code (in the handler):

# real code should do a lot moar error handling
{:ok, result, commands} = ServiceModule.do_stuff(args)
:ok = Persistence.execute(commands)

Here commands might be a list of tuples like {:update, some_id, new_value} or more structured things like {:insert, %Ecto.Changeset{}}.

This allows each module to be tested cleanly in isolation - the output of ServiceModule.do_stuff can be inspected, pattern-matched, and asserted on in tests without any implementation of Persistence at all.

Post #1

— All posts loaded —