PlugAndPlay: Set up Plug apps with less boilerplate

Your Libraries & OS Mentoring Libraries
1

I just made a small library to reduce boilerplate when making a new Plug app:

https://github.com/henrik/plug_and_play

I started rewriting a Sinatra app in Plug a while back and got a little frustrated by having to figure out a lot of boilerplate just to get a basic app running. So this is my way of maybe reducing that friction.

I’ve tried to keep it low on magic, and layered – you can have PlugAndPlay own the whole supervision tree, or provide your own with PlugAndPlay.Supervisor as a child.

It might be convenient to have something like this built into Plug itself. But I suspect Plug wants to be mostly low-level and leave these concerns to other libraries.

Would love feedback and thoughts. Try it out the next time you set up a Plug app!

5 Likes
2

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 :pensive:

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 :wink: 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 :smile:

2 Likes
3

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.

1 Like
4

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: https://github.com/henrik/plug_and_play/commit/25541821758a092de2d9f84f8a4cb6eb89c9f5de

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…

1 Like
5

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
2 Likes
6

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.

1 Like
7

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.

2 Likes
8

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.

1 Like
9

Ah, excellent point. Thank you very much!

1 Like
10

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.

2 Likes
11

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:

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),
]
3 Likes