Support sending via the ARI Proxy Messaging Protocol

[danjenkins]

I'd love to be able to use this library with the ARI Proxy messaging protocol and send/recieve via a message bus such as RabbitMQ rather than via Websocket/HTTP.

The ARI is great except that it really limits us to a 1:1 relationship.

Both the .NET and Go ARI Clients don't rely on getting a resource list from the API on startup which makes utilising the Proxy easier. The other issue is that everything utilises the swagger-client to generate request bodies etc from what I can see - which again limits the clients use as its tied to swagger.

I'd love to have a chat about the best way to implement this so that I don't come to put a PR in and have it rejected. @samuelg @erinspice @matt-jordan

I'd prefer to just have the one ARI client on npm but I'm starting to wonder if I should just fork the project, remove all the swagger cleverness and go down the route of what .NET and Go did - generate all the functions etc from the resources file whenever Asterisk changes - don't do it on every startup (which must add time to all app startup times) and not using swagger to do the HTTP/Websocket calls etc.

Let me know your thoughts!

[samuelg]

I think it would be great to support the ARI proxy as an additional connection option.

My main concern is to ensure that we do not break the library for existing users. We should continue to support the single Asterisk/WebSocket model we have today along with the library niceties that were added on top of the swagger client such as:

channel.hangup();
channel.on('event', function() {
  // only gets called for this channel
});

As far as Swagger building the request I don't think that's actually a problem here. We wrap all ARI operations with our own functions so it is possible to make it so a client connected to a proxy uses some other mechanism for building and sending requests. I don't see a reason to completely do away with Swagger in order to support another protocol.

The only remaining sticky point is how to manage the fact that the client is loaded at runtime currently (minimal addition to startup times in our experience) using a hosted Swagger definition file. One option would be to host a copy of the latest Swagger definition file for ARI locally within the library and point the client at it when using the ARI proxy as the protocol. The definition file can be configured to point somewhere other than where the file is hosted so that's not a problem. The other option would be to generate a static client from the latest Swagger definition file for ARI at build time that is capable of using both the current model and the ARI proxy. Here I would actually recommend looking at how we wrap the current API using Swagger at runtime. Swagger provides all the required metadata to generate a client along with an implementation of the client itself. This could be used to generate a static client much more quickly than building yet another Swagger parser. Both options have their tradeoffs. I'm not sure which would be best for us at this time.

[danjenkins]

Completely agree with you @samuelg; and yes the main concern for me is, I don't want any change in behaviour - a user should just be able to give some different credentials and it should all carry on working as expected; being able to say develop on a 1:1 relationship and then move to the proxy in production.

I'm currently exploring swagger-api/swagger-codegen as they've recently added support for generating a javascript library - I'm hoping its a complete match to the dynamically generated one.

[danjenkins]

So the code generator from swagger seems like it may be a dead end; I'm just hitting too many issues in the fact we're still using spec version 1.1. So I'd like to look at using a local copy of the swagger specification file and letting it auto generate code on application startup. However; the resources.json file purely points at other files that it needs to go and get and I think if I point the library at a local file, it won't know where to go get the other files....

[samuelg]

Ah yes. The multi-file definition. I suppose it would be possible to serve each file locally along with the root definition but it does add complexity.

[danjenkins]

So I've just come back to this, created a single file definition but it seems as though I'm going to have to create a http server to serve up the single file swagger definition as the swagger client doesn't seem to be able to handle us passing in a JSON file as it expects to go and get it from a URL

So I'm going to carry on, let the swagger stuff call a local http server to get the swagger definition, and then get it to talk over AMQP... see where we get from there.

[lewisf2001uk]

Sorry to resurrect an old issue, but has there been anymore movement on this? Looking into this project and for production / scalability we need someway of getting around the 1:1 relationship issue.