1
votes

I'm working on an Erlang project which has a number of different Erlang applications bundled into a single release. Each application has a pretty simple structure - a top level app file, then a single supervisor managing a single gen_server. It uses rebar/reltool to build the release; as a release noob I'm pretty horrified by the amount of strange configuration options that have to go in rebar.config and reltool.config to make the whole thing work.

Then I discover erlang.mk and relx, which seems a much saner/simpler way of building a release. It does however seem that erlang.mk only works with a single top- level application (that is, one application with the same name as the underlying project). Which got me wondering, is my original structure really optimal, given the simplicity of each application ? Might it not make more sense to have a single application with a single top- level supervisor, then a second layer of supervisors underneath this, each managing one of my gen_servers ? Then I can use erlang.mk and hopefully remove a whole load of rebar- related complexity into the bargain.

So: any advice on the pros/cons of using multiple applications on the one hand, versus using a single application with an extra layer of intermediate supervisors on the other ?

1

1 Answers

1
votes

Application in Erlang is a reusable component, that can be started or stopped as a whole. It may be a library, that doesn't need starting or stopping. I like to ask myself a question:

"Can I put this application on github, so that someone else could use it?"

  1. If it is general enough and the answer is "yes" or it is only loosely coupled with rest of the system, then make it an application.
  2. If it can be used only in your project, than don't bother.

I don't know erlang.mk so well, but it should be able to handle more applications at top level. If not, then rebar3 has relx integration. And here you have project page.