@jeroenbourgois: Here are my ideas:

1. Add Logger backend, see: “Custom backends” section.
2. Add controller field.
3. Fetch controller and action name from conn, see: Phoenix.Controller.action_name/1 and Phoenix.Controller.controller_module/1
4. Fetch header using: Plug.Conn.get_req_header/2 instead change all headers to map.

Note: You could save controller like:

alias Phoenix.Controller
# ...
controller_module = Controller.controller_module(conn)
"Elixir." <> module_string = Atom.to_string(controller_module)
# so we could do something like:
controller = String.to_existing_atom("Elixir." <> ex_activity_log.controller)
# do something with controller ...

Look at this case>
You could change it in to ways:

case headers[header] do
  nil -> ""
  value -> value # note do not call fetch again!
end
# or even simpler:
headers[header] || "" # because nil || "" returns: ""

For more information see: Kernel.||/2

In this line - you should have full call, please see: Avoid needless pipelines like the plague. code style rule by @lexmag.

Funny, but you could add pipe to another line

Here you have credo style guide and here its library that will look at your code with simple mix task.

Let me know what do you think about it.

@Eiji thanks for your input! We are very new to the Elixir game so your styleguide comments are very welcome. I will look into it to make the library better!

Just a small reply, your proposals 2, 3 and 4 make a lot of sense. The first one, not so much to is. Here is why: we created the lib just for that specific reason: we did not want to use Logger, we had it at first (logging to a papertrail backend) but while this is great for all the out-of-the-box logs you get with Phoenix, we did not want that for ‘in controller’ logs.

That being said, after looking into the docs for custom backends, it might just be what we wanted in the first place Do the logs you sent with Logger also happen in a different process, do you know that? If so, it might just be worthwhile to develop it as a custom backend which will make it much more portable and pluggable.

Again: thank you for your input!

PS: just because I am curious, if we were to get more info from the conn that is Phoenix specific, will we have Phoenix as a dependency? Not that it would be a big problem since we are using it in a Phoenix app to start from…