Simplify route configuration

[williamthome]

Currently, routes are plain Cowboy routes, but they should be simplified for the Arizona use case. For example:

% {Path, Handler, Args}
[
    {"/favicon.ico", cowboy_static, {priv_file, _AppName = foo, "static/favicon.ico"}},
    {"/", arizona_live_handler, {_View = foo, _Fun = render, _Macros = #{}}}
]

Maybe it should be:

[
    % Static should pick the current OTP app for the priv dir
    {static, "/favicon.ico", "static/favicon.ico"},
    % Live route sets the render function and empty macros by default
    {live, "/", _Mod = foo}
    % Or, without the defaults:
    % {live, "/", {_Mod = foo, _Fun = render, _Macros = #{}}}
]

[paulo-ferraz-oliveira]

Since we rely heavily on cowboy I'm wondering if you wanna massage the input, or even restrict it. And what would your initial idea for this be (?)

[williamthome]

If I understand you correctly...

In the "original" Arizona project, I introduced an "adapter" concept for stuff like this, but first, we need to define an interface/business rules.

Please take a look here. The json, router, server, and template directories contain adapters:

The idea was to keep these settings generic and "pluggable". I see it as a good approach, but it requires more work. Please let me know what you think or what your suggestion is.

[paulo-ferraz-oliveira]

I think we should impose as least as possible, on routes, file structure, etc. We should have "concepts" around which the consumer works, like "modules representing templates", but also "file representing templates", etc. The only thing cowboy imposes, for example, are the behaviours (and, of course, the way the routes are config.'ed), but there's no concept of "adapter" or stuff like that and I think to begin with we can make do without those. If stuff evolves we can later add these elements, but maybe as "out-of-the-box helpers" and not straight out components the consumer has to be forced on.

[paulo-ferraz-oliveira]

In any case it's possible I got some of what was done wrong. A good initial approach might be to think about "How do we want to express the routes in the config.?" and then the solution (adapters, massages, etc.) would come in later to fill that gap.

[williamthome]

the solution (adapters, massages, etc.) would come in later to fill that gap

I agree. In any case, the issue is related to routing simplification, which is simple to implement.

I do not have a formed opinion about the interface, but I'll write a suggestion that comes to my mind right now:

[
    {static, "/favicon.ico", "static/favicon.ico"}, % relative to the priv dir
    % EDIT: Or {serve, "/favicon.ico", "static/favicon.ico"},
    {render, "/", foo, #{}} % which calls `foo:render(#{})` 
                            % EDIT: I'm using render here to avoid the `live` word
]

EDIT

The consumer should be able to implement REST routes, like get, post, and friends. Therefore, a custom handler must be able to be defined.