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!
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
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
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
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)
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.
So I explored the pipeline thing. It’s definitely possible to do something like
use PlugAndPlay.Router do
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:
I also introduced a child_spec to make things easier:
children = [