PlugAndPlay: Set up Plug apps with less boilerplate

I love the concept, and it looks like it could be a good fit for many apps. However, not being able to customize the port via regular application configuration unfortunately leaves it dead in the water for my purposes

While we do, in some cases, use OS environment for configuration, we also like Conform, and having a nice little config file managed by Puppet. Even if that weren’t an issue, PORT seems to be a little too generic, and doesn’t scale beyond a single endpoint in the same application We often have a main application endpoint, then another endpoint for monitoring, listening on a different port and responding with metrics in JSON format.

Using application config for PlugAndPlay would still enable the OS environment scenario with a simple one-liner, and also enable any other convention within the Elixir / Erlang ecosystem.

I appreciate that this might be intended as a very simple scaffolding helper for a specific convention; in that case, please just ignore what I’m saying

Thank you so much for the feedback!

I considered application configuration for ports but it wasn’t necessary for my use case – good to know it is for someone else! I’ll see what I can come up with.

Alright, I’ve made it possible to set the port number in app config. Please let me know what you think – does this work well for your use case?

Commit: [Backwards incompatible] Can set port via app config · henrik/plug_and_play@2554182 · GitHub

It’s a tricky balance, trying to minimise boilerplate without making things unworkably implicit. Passing in the application module and deriving the router and config from it feels like it’s close to that limit, but hopefully does not cross it.

So now we have

use PlugAndPlay.Application, mod: HelloWorld

I also considered something like

use PlugAndPlay.Application,
  router: HelloWorld.Router,
  port: Application.get_env(:hello_world, :port)

But I feel that for a boilerplate-reduction library, that’s too much boilerplate…

Depends.. the port: config would only be needed if you actually must configure the port that way, and since that kind of falls into the “custom requirements” category I’d say that an extra line of code isn’t too bad.

The regular use, if you’re happy with OS environment or the 8080 default port, would just be:

use PlugAndPlay.Application, router: HelloWorld.Router

The explicitness on the router specification feels a lot better to me at least.

Nice thing is the router + port options could be consistent in both PlugAndPlay.Application and PlugAndPlay.Supervisor, so if I had multiple endpoints, it would look like:

defmodule HelloWorld.Application do
  use Application
  import Supervisor.Spec

  def start(_type, _args) do
    children = [
      supervisor(PlugAndPlay.Supervisor, [HelloWorld.Web.Router, 8080]),
      supervisor(PlugAndPlay.Supervisor, [HelloWorld.Monitoring.Router, 8090]),
    ]

    Supervisor.start_link(children, strategy: :one_for_one)
  end
end

Thank you, that’s good feedback. I’ve experimented a bit with that now.

Seems if the same supervisor module is used multiple times, you also need to specify an id, something like:

children = [
  supervisor(PlugAndPlay.Supervisor, [HelloWorld.Web.Router, 8080]. id: make_ref()),
  supervisor(PlugAndPlay.Supervisor, [HelloWorld.Monitoring.Router, 8090], id: make_ref()),
]

Even after that I’m getting some issues where it fails to start the second app; I’ve yet to figure out why. My process-fu is not very strong yet. The core of the error seems to be:

{:error, {:shutdown, {:failed_to_start_child, {:ranch_listener_sup, HelloWorldOne.Router.HTTP}, {:shutdown, {:failed_to_start_child, :ranch_conns_sup, {:badmatch, false}}}}}}

I’ll keep trying – this is beyond my own use case, but I’m learning a lot.

Hmm.. interesting; with Phoenix, it “just works” when you define an extra Endpoint, so it’s probably doing something under the covers to make that play nice with Cowboy.

Just a quick observation: I think another issue is that the scaffolding won’t allow you to add custom plugs into your builder pipeline, since those need to go between use Plug.Router and plug :dispatch in the Router.

Ah, excellent point. Thank you very much!

So I explored the pipeline thing. It’s definitely possible to do something like

use PlugAndPlay.Router do
  plug Foo
after
  plug Bar
end

or whatever, but it’s cryptic enough, and reduces boilerplate by such a small amount, that I would rather just state in the README that you shouldn’t use PlugAndPlay.Router if you want to customise the pipeline.

Figured out why I got that error: it was simply that I tried running the same router twice on different ports, which does not work. I think Cowboy by default assumes it can refer uniquely to each one based on its module name.

When I specified two different routers, it worked fine. So now I’ve pushed that change:

https://github.com/henrik/plug_and_play/commit/076e69b3df3f7ac871a0c7094737ccd1b99c27fd

I also introduced a child_spec to make things easier:

children = [
  PlugAndPlay.Supervisor.child_spec(HelloWorld.RouterOne, 1111),
  PlugAndPlay.Supervisor.child_spec(HelloWorld.RouterTwo, 2222),
]