Support sending via the ARI Proxy Messaging Protocol about node-ari-client HOT 6 OPEN

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.

from node-ari-client.

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.

from node-ari-client.

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.

from node-ari-client.

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....

from node-ari-client.

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.

from node-ari-client.

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.

from node-ari-client.