Not all all.
I’m suggesting separating lifecycle concerns from functional concerns within the same codebase, that’s all.
pragdave
Author of Programming Elixir
sasajuric
Author of Elixir In Action
Right, and this is what I believe the whole industry has been doing for decades, and it’s still doing it now with the mainstream microservices approach. Thus, I actually think that the Erlang way, despite its age, is in fact avangarde, and the Elixir way with childspecs is even more progressive.
4
pragdave
Author of Programming Elixir
Fl4m3Ph03n1x
So, just to see if I understand both points of view clearly:
@pragdave defends we should split functional concerns from lifecycle concerns. In his opinion, such can be achieved by separating the start_link, init and callback functions from GenServer into a separate file, while keeping the API that is actually used, in another file.
@sasajuric defends that both lifecycle and functional concerns belong together in the same file, because you need both to make effective use of an API. It is not clear to me if @sasajuric likes the micro-services approach we have seen recently, but it looks like he prefers the way Elixit’s community is dealing with the way APIs are organized anyway.
I apologize if I have miss interpreted any comments, but I feel this is a succinct summary of both points of view.
0
peerreynders
Perhaps the former emphasizes the client point of view (related to interface segregation); the latter emphasizes the maintenance point of view - being able to see everything the process needs to function in one place to make it easier to reason about the whole - up to a point. When the capabilities of the process grow large enough it is time to push those into separate modules (or perhaps even separate processes), in effect composing the capabilities to realize the process.
3
sasajuric
Author of Elixir In Action
Roughly speaking yeah. My position is that lifecycle functions (childspec and optional start_link) are a part of the component/service API. I’m not saying this should always be in the same file though. I do concede that lifecycle can be thought of as a separate API concern, so in the case of a larger API, we might decide to move lifecycle and some other API concerns into separate modules (in which case I’d try to keep lifecycle in the top-level module). In this particular example, I feel that the module is too small, and IMO splitting it causes more confusion with little to no tangible benefits.
I feel that the mainstream microservices approach (i.e. the approach based on one OS process per microservice) is an improvisation around deficiencies in the first chosen technology (the language of choice + runtime). I’m happy to discuss this in further details, but it’s probably better done in another thread.
5