Add supervised API

[oubiwann]

One of the things I've noticed when working with the Erlang RabbitMQ library is how easy it is to crash a process (usually through a fault of my own, e.g., by calling a function improperly -- wrong types or wrong number of parameters). Regardless, abuse like this results in a bad user/developer experience and makes writing applications that much more finicky.

What I propose we do is provide a unifying API in the kanin module that, when started, creates a supervised kanin server that maintains connection options, connection(s), and channel(s) as state and when child processes die, new connections, channels, etc., are created automatically.

Furthermore, we could provide a default channel that is used implicitly making the API even easier to use.

Features/tasks:

• Archtect a supervision tree for kanin - Archtect a supervision tree for kanin #5
• Provide kanin server for failure+state management - Provide kanin server for failure+state management #7
• Provide a high-level API that uses supervised kanin - Provide a high-level API that uses supervised kanin #8
• Add an example that uses this new API - Create an example for the new, high-level kanin API #29
• Update documentation - Update documentation #13

Part of release v0.7.0

[oubiwann]

I'll set this task as an epic and create features/tasks

[oubiwann]

@arpunk: Would this sort of thing be of interest/help to you?

[arpunk]

@oubiwann Yes, I use this sort of strategy all the time (I work with RabbitMQ on a daily basis). In my experience all the pooling strategies are very opinionated. However these are my ideas:

• Use sbroker based pools. Writing pooling strategies is very hard and it ends up being opinionated and not flexible for various use cases.
• Provide backpressure mechanisms. Being able to rate-limit producers/consumers is very convenient. I've suffered a lot from these on very high throughputs. As above you will want to go with a standard solution (pobox, fuse, sbroker, etc.)

I currently use GenStage based consumers at work using wabbit and/or custom AMQP wrappers.

I tend to wrap very lighly on the standard RabbitMQ Erlang clients. Sometimes I use turtle for simplicity when working on small PoC/MVP in Erlang.

[oubiwann]

@arpunk This is great feedback -- thanks!

[oubiwann]

@arpunk I'm much happier using this new API in the kanin module that the old one (which mirrors the native Erlang client). Still WIP, but making good progress. Default supervision tree is up next.

Compare examples:

• https://github.com/lfex/kanin/blob/release/0.7.0/docs/wrapper/examples.md vs.
• https://github.com/lfex/kanin/blob/release/0.7.0/docs/otp/examples.md

After this release, one tedious (to implement) improvement that could be made would be to convert calls like this:

    (kanin:call
      (make-queue.bind
        queue example-queue
        exchange example-exchange
        routing_key example-key))

into this:

    (kanin:bind-queue
      queue example-queue
      exchange example-exchange
      routing-key example-key)

Much better developer experience ... but that's more than I want to tackle right now ;-)