9.0.0 and Primus

[djkilg...@gmail.com]

Hi,

We were previously using 8.0.8 using websockets / faye.
Our client application is not hosted by the node.js / actionhero server, but is independent and so has a different URL and port. We were previously connecting to Faye directly and sending commands there.

I am attempting to migrate our project to 9.0.0:

I have the server up and running and am attempting to use the actionheroClient.js remotely rather than learning Primus and modifying our client script accordingly.

I set the clientUrl in config/servers/websocket.js to https://ourdomain:8080

After I issue client.connect() I tried to send a
client.action("actionsView", function(data){ console.log(data); }) like in your example,

however the browser console shows that the command is being sent to

https://ourdomain/NaN?action-actionsView&

Am I doing something obviously stupid here?
Being unfamiliar with the actionheroClient library is probably not helping me.

I am also curious if the commented out options in config/servers/websocket.js from 9.0.0 are supposed to be that way. For instance, uncommenting "transformer: 'ws'," throws the following error:

Primus:
Primus: Unsupported transformer: "ws"
Primus: We only support the following transformers:
Primus:
Primus: websockets, engine.io, socket.io, browserchannel, sockjs
Primus:

Thanks,
Dj

[djkilg...@gmail.com]

Adding the following to config/servers/websocket.js in the client section allowed us to issue an action although I am not sure this is the right way to do it

apiPath: '/api',
host: 'https://ourdomain:8080',

I do not see these options in my freshly generated test project, so I am wondering if I am supposed to set this stuff up elsewhere, or am I going about this the wrong way?

[Evan Tahler]

Updates from your comments: https://github.com/evantahler/actionhero/commit/7c2f8c1bee5ae495b8733770f68373844ebc1be4 + https://github.com/evantahler/actionhero/commit/92d2361053f6e1ef4dcd3331f6f7b497fdc3b8fa

If you are getting to the part of the client that uses apiPath, that means you are not connected via websockets, and the client is falling back to an HTTP POST request for actions, and your client is not actually connected. Primus claims to be cross-domain compatible.  Are you certain that the actionheroClient.js is being generated and is loadable by the browser?  Try socksJS as the underlying transport, as being cross-domain is one of their main selling points. 

[djkilg...@gmail.com]

I can load both the regular and minified versions from my browser, and it seems to be a freshly generated copy, so I don't think the problem is there.

To see if it was a cross domain issue, I updated to 9.0.1 and moved my client to be hosted in the public folder of actionhero rather than externally and I am not having much of a different experience with either websockets or sockjs transports, neither of them seem to connect by ws and does the fallback method.

I see a readyState of 3 for the connection and then switch protocol notice in the network console, so I assume thats where its failing the wss connection and falling back to post.

I am going to continue to see if I can get it working, my post was basically I just wanted to know if I am doing anything obviously wrong with regards to using the client library as I mentioned we had our own client library previously.

I am not sure what all needs to be uncommented with regards to the server options for Primus in websocket.js config. Does anything need to be uncommented for basic functionality?

I had assumed the commented out options were the defaults, however if I uncomment "headers: false" for instance, the server will not start with this error:

/server2/node_modules/actionhero/node_modules/primus/node_modules/access-control/index.js:62
, headers = options.headers.toLowerCase().split(',')
^
TypeError: Object false has no method 'toLowerCase'

[Evan Tahler]

Thanks for trying all this out.

First, the websocket config options.  I thought a good was to make folks aware of the potential options Primus can take would be to list them commented out.  This also makes it clear how to pass variables into actionhero you want to trickle down to Primus.  The list of defaults came from https://github.com/primus/primus#getting-started and https://github.com/primus/primus#connecting-from-the-browser.  For example, as you point out `headers` is listed as `false`, even though it eventually seems to expect a string-list of headers.

Do you think it would be best listing no options, and liking to the Primus documentations?  

Now on to your more specific questions:

Nothing needs to be uncommented for Primus + Websockets to work out of the box, including cross-domain.  Here's my simple test with a fresh actionhero project:

- npm install actionhero

- ./node_modules/.bin/actionhero generate

- npm install

- npm start

- visit http://127.0.0.1:8080/chat.html in a few browsers and see that you can websocket chat between them

- edit your /etc/hosts file to alias 127.0.0.1 site1.com and 127.0.0.1 site2.com so you can have a few domains to test

- change api.config.servers.websocket.clientUrl to 'http://site2.com:8080'

- visit both http://site1.com:8080/chat.html and http://site2.com:8080/chat.html in separate browsers, and confirm you can still chat between them.  This also shows that when loading HTML from site1.com, you can still connect to the WS server on site2.com.

Does the above not work for you?  

--
 Evan Tahler
 412.897.6361
 evant...@gmail.com

--
You received this message because you are subscribed to the Google Groups "actionHero.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to actionhero-j...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[djkilg...@gmail.com]

We ultimately got it working.

I think the consensus was that some of the naming from your client script was conflicting with internal stuff from our project as ultimately our original client library was based on your old faye library so it had some of the same naming conventions.

I did want to make a note in "fallback" mode, I think something is still missing from the options, as I would have like domain/undefined/action?whatever in the request.

In reference to your comments above, I think you should leave the commented out options, however as I mentioned above, I was expecting the commented out options to be *working* defaults. Uncommenting a line and having the project break was a bit confusing having no previous knowledge of Primus.

The whole reason I chose to use the built in client library was so I didn't have to learn Primus in the first place. I like this project because its easy to get up and going and add new actions and initializers, so I don't think the majority of people that use this client library want to go read a bunch of Primus documentation just to figure out why their project breaks when something in the generated project is uncommented is all.

[Evan Tahler]

The namespace collisions are really worrisome! Looking at the generated JS, it looks like the following top-level variables are claimed:

- EventEmitter 

- defaultUrl

- Primus (and the transport you choose lives in Primus.client)

- Stream

- parse

- actionheroClient

Were any of these colliding with what you had?

The fallback URL is built from (api.config.servers.websocket.clientUrl) + (api.config.servers.websocket.apiPath) + QS, where QS is the GET query strung, IE ?action=myAction&key=value.  What so you want the 'undefined' part for?  If you need a deeper route for this fallback, you can make apiPath whatever you want, IE '/thing/stuff/api'.  Only the fallback uses apiPath.

Yeah, I'm not really sure what to do with the Primus commented-out defaults.  Do we maintain consistency with the provider, or do we make up some defaults on our own to match what we *think* most actionhero users will want.  If you want to test all of Primus' defaults and come up with more sensible defaults, please submit a PR! 

--
 Evan Tahler
 412.897.6361
 evant...@gmail.com