Single Responsibility Principle - what does it mean to you and your Elixir apps?

[AstonJ]

@peerreynders

From the horses mouth NDC 2012 Norway: Robert C. Martin - The Single Responsibility Principle

He talks about splitting things into roles/who might need them - so separate code that’s related to a designer, code that generates reports for a clerk, code responsible for reports for a manager etc. He also suggests that’s ok to repeat code as it may change for one or the other, for example, a clerk and manager may need the same code to begin with but one of their needs might change in the future - so this kind of separation allows that kind of change easily.

Would you agree that’s the gist of it?

For me I think that adds quite a bit of mental overhead, and that it may be simpler to just think in terms of what something does, and create functions and modules focused on that one thing (which would then also allow things to be reused). Perhaps I am being a bit too lazy… or just need a few other examples to better picture it.

@ericgray

I also really really like Microservices. Of course you shouldn’t go crazy with it but apps being split into components makes a lot of sense to me. I’ve worked on monolithic apps where things were just out of control and unmanageable. I think Elixir is tailor made for SRP and microservice style development.

You should definitely check out the video in @peerreynders’s post here:

Rocky Mountain Ruby 2016 - Kill "Microservices" before its too late by Chad Fowler

####Dan North: Software that Fits in Your Head - Goto Amsterdam 2016-June-14 The talk essentially drives to the conclusion that a Replaceable Component Architecture is one of the “Big Ideas” behind Microservices - i.e. it is important to optimize for replaceability.

Where Dan talks about the Replaceable Component Architecture (see Peer’s links in the post as they jump right to the appropriate parts).

@ericgray

One thing I’m unsure about is the database layer. I know Dave thinks Phoenix should only be a web interface and know nothing about the database but databases can be complicated to configure and use as a microservice.

I’m in the same boat. I hope Dave does another course but this time jumps right into the application (rather than teaching the language basics) and covers databases. I’m going to email him with the suggestion once I’ve finished the course

In the meantime, check out my post and the link in it here (again thanks to Peer for that link!)

I’m glad you are enjoying Dave’s course too - I love it! Am 90% through it now - can’t wait to finish it

@hubertlepicki

In Elixir & Erlang, modules group together the related functions. That’s it, there’s no big theory behind it.

I think this is one of the reasons why people are so excited about Elixir (and similar languages) because they make it so easy to follow good principles like the SRP

@hubertlepicki

These functions may perform one or multiple things, but as long as it makes sense to keep them in the same module - they are kept there.

One of the things that surprised me in Dave’s course is when he got to a Phoenix view and said that it was about 35 lines which seemed a bit large to him (I was like, you should see my Rails models ) and said that’s normally a good indication that there is a group of code related to one thing, and sure enough there were 22 lines related to one thing (state) and we extracted that out into a dedicated _state helper.

This also falls in line with the ‘fits in my head’ mantra, where you shouldn’t be looking at code that is bigger than your head (i.e no scrolling!). “If you have to page up and down - it’s probably too complicated”.

I love that talk btw - so many good ideas presented in it (Thanks Peer!)