inaka / cowboy-trails Goto Github PK

Or otherwise start CI'ing only using Ubuntu versions mentioned here (valid until Ubuntu latest becomes something else again).

something like…

trails:api_root("/api").

…which would result in all trails built with trails:trail(Path, …) to actually have "/api" ++ Path as their path.

The idea is that you can do…

ok = trails:api_root("/api"),
"/api" = trails:api_root(),
Routes = [trails:trail("/things", the_handler)],
trails:single_host_compile(Routes). % returns [{'_',[],[{[<<"api/things">>],[],the_handler,[]}]}]

As a matter of fact, invoking trails:api_root("/api") should be equivalent to application:set_env(trails, api_root, Path).

Example can not be run with 'make shell' command as it depends on unavailable https://github.com/inaka/sync.git

• implement trails:store(atom(), trails()) that acts like trails:store/1 but it let's the caller store more than one server on the same node assigning a different name for each one.
• implement trails:store(atom(), [{cowboy_router:host_match(), trails()}]) that acts like trails:store/2 but it let's the caller store more than one host for the same server.

• create opaque type in trails called trail() and export it
• Modify trails:trail/1,2,3,4 and create trails:trail/5 by adding a Metadata::map() parameter, and they should return trails:trail() now.
• Make the internal representation for the opaque type trails:trail() include the metadata field
• Change the compiling functions so that they can now also receive a trail() and produce the expected output

Hi,

Using cowboy, withou cowboy-swagger I used to pass an Option to cowboy handlers. Like this:

 Opts = get_handler_options(HttpConfig),
Dispatch = cowboy_router:compile([
                                      {'_', [ {"/nodes/[:type]", location, Opts},
....

How to achieve the same using trails ?

Thanks.

Add a function trails(module() | [module()]) -> [trail()] that, given a module or a list of modules, it retrieves the list of trails from those modules by calling Module:trails() for each one of them and concatenates them

Currently, when trails:store/1 is invoked, list of trails/routes are stored into an ETS table (in a set structure), so it breaks the order how routes comes in the list, and due to this trails:all/0 returns the list in different order.

One option could be use an ordered_set structure for ETS table, BUT will be necessary add an additional argument (for example a consecutive integer) in order that the tree can be sorted in the right way.

Executing this line takes sometimes a minute. The store function is called and soon after that remove is also called. It does not take always one minute but in a lot of cases I can see execution is stopped there. When I comment this line out everything works well.

Actually the list in the second parameter of do_store/2 can be huge. Is there a reason why application:ensure_all_started is called million times? Would not it be enough to start those applications only when trails starts?

Migrate to rebar3 as described here.

This is requested by esl/TODO#62

Introduction

This is the list of things to check for every open-source project that we create

Usage

Each project should have a github repo with github issues enabled. As the main dev in that project, you should make sure to have the corresponding items from the lists below reported as issues there and work on having them implemented/done before releasing the 1.0 version of your product.

General Items

• It has a github repo
• It has a proper Apache2 LICENSE file
• It's has a clear and useful README.md
• It's documented (with examples)
• It's tested
• It's hooked to a the open-source hipchat room
• It has a link to the open-source hipchat room in its README
• It has a link to inaka.github.io in its README and/or landing page

Exhibition

• There is a blog post about it
• It's shared on social networks
• It's shared on reddit
• It's shared on hacker news with a title like Show HN: description
• It has a landing page built in github pages

For Libraries

• It provides a sample application
• Examples of use are documented in the README or linked from there

For Erlang Projects

• It's checked with Gadget
• It's shared on Erlang Central

Add our usual meta-testing suite here

For example:

 Trails = 
    [
      {"/api/resource3/[:id]", trails_test2_handler, []}
    ],
trails:store(Trails).

It's currently

-spec store([trail()]) -> ok.

It should be

-spec store(trails()) -> ok.

Create a trails:compile function that's compatible with cowboy_router:compile

• metadata field in trails map should be of type metadata() :: #{method() => map()}.
• method() :: get | put | post ...
• add inaka's default dialyzer options and run make dialyzer

esl/TODO#60

Turn it into an actually kinda useful service that sets/gets the env for the app

The currently-published Hex package depends on katana-0.2.18, which depends on inaka_mixer-0.1.4, which isn't published.

Please publish a new version with the dependencies fixed. Hopefully just upgrading Katana to the latest published release would do it.

Hi,

As I see the examples folder contains a soft link to ../../. : https://github.com/inaka/cowboy-trails/blob/master/example/_checkouts/trails

Using a quite old version of rebar3 (3.13.3) sometimes rebar3 as prod tar works, sometimes don't (I don't know what causes the problem, on some machines it works, but on some other Jenkins agents we got this error):

 ===> error (eloop) accessing file /var/Jenkins/workspace/Upgrade_Release/our_app/_build/prod/lib/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/example/_checkouts/trails/.github

Looks like the problem is also related not only to rebar3 but to the OS / filesystem under the engine.
So basically the softlink pointing back to the root directory causes an infinite loop under some conditions.
Would it be possible to delete this softlink, or was it intentionally committed in : ec2fe6f ?

call the app trails

Currently, all/0 gives you all the trails from all servers/hostmatches and all/1,2 allow you to retrieve the list of trails for a particular one, but there is no function to retrieve the list of servers and hostmatches themselves.
So, we need to add the following functions to the trails module:

• servers() -> [ranch:ref()]. - to retrieve the list of servers
• host_matches(ranch:ref()) -> [route_match()]. - to retrieve the list of host matches for a server.

add:

• trail(cowboy_router:route_match(), module()) -> cowboy_router:route_path() which equiv to trail(Match, Module, []).
• trail(cowboy_router:route_match(), module(), any()) -> cowboy_router:route_path()
• trail(cowboy_router:route_match(), cowboy_router:constraints(), module(), any()) -> cowboy_router:route_path()

add a rebar.config file with the appropriate configuration

Particularly to cowboy 2.3.0

I'm curious if someone already worked on it. Otherwise would you accept a patch for it? What could be the best way to handle both cowboy 1.0x and cowboy 2.0x ?

Would it be possible to tag a release, here and in Hex.pm?

Many thanks.

add functions to trails:

• store([trail()]) -> ok.
• all() -> [trail()]
• retrieve(path()) -> trail()

These functions should store and retrieve trails from an ets table.