Javascript subscriber about propono

[malcyL]

Hi Christian

I've been working on a side project to create a javascript version of Propono. The idea is that it's completely compatible with the ruby version. I started it last year - and the commit history shows I haven't committed to the project since December - so it is still very much a work in progress. I do intend to get back to it when I can.

It does publish messages which can be read by a ruby listener. You can also listen for messages in javascript too. When listening, it doesn't have all the features the ruby version has. For example, failed queues.

The repo is here: https://github.com/malcyL/proponojs

Your welcome to take a look and use it if it will help.

Malcolm

[chriso0710]

Hi Malcolm,

sounds good, thank you for the hint! I will definitely take a look at your repo and give it a try.

My usecase would be to use propronojs for listening to messages.
Does it use a timer for polling or is there another method of receiving messages from SQS?

Christian

[malcyL]

Hi Christian

I think both propono and my javascript version both use the aws libraries to read from sqs queues. These will be making http api calls under the hood.

Do you really want to do that in the browser though? You would have to expose your AWS keys etc to the world to do that, wouldn't you?

I wonder if you would be better using something like websockets to push updates to the browser? Maybe from a rails or node backend which was itself listening to propono?

Malcolm

[iHiD]

In a different lifetime, I think @malcyL and I built a Sinatra app that received propono messages then pushed them to the browser via websockets, which worked well.

If you don't mind your SNS channel being publicly accessible, you could have permissions that let anyone consume it, so you don't expose your keys, but then anyone could steal messages. So that would depend lots on your business case.

Long-polling should work through any AWS client or you could do it through an http call. Long polling means that the connection will stay open until there is a message, then handle it and immediately open a new connection to wait. It's means that it's pretty much instant and doesn't need constant pinging.

[chriso0710]

Thanks guys!
I must admit I haven't thought this through. Exposing AWS keys or making a channel public is certainly not best practice. Websockets (or even simple SSE as I only need unidirectional messaging) might be the way to go then...

[iHiD]

Hi @chriso0710 - are you happy for me to close this or do you want to discuss further?

[chriso0710]

Yes, sure, thank you!