I know that karate has a built-in support for WebSocket, but there is anyway that can use socket.io on karate?
I would like to sent a message into a microservices that comunicate with socket.io, and wait the response for asserting that the message is as expected.
No, you can't use arbitrary JavaScript libraries from Karate, and there is typically never a need to.
EDIT: if you explain what exactly you are trying to do (you can edit your question) that would make for a much more productive discussion. Karate is a testing framework. if you see a gap in the WebSockets implementation, the right thing to do is ask for a fix, see example: https://github.com/intuit/karate/issues/775
Or maybe all you need to do is use the Java inter-op. I know teams using this to test gRPC, JMS messaging and chat-bots that do bi-directional / async flows: https://twitter.com/KarateDSL/status/1128170638223364097
Related
I have a NestJS microservice using socket.io, but I need to know if it's possible to implement it in the same gateway WebSockets (WS). I need to send some requests at the same namespace from different clients (socket.io and ws). The actual implementation works only with socket.io.
Socket.IO uses Websockets but it is doing much more than it appears on first glance.
You should see it as a different protocol.
Maybe you have a chance with a workaround but it will probably get messy. I found something here that might help.
No, it is not possible according to the developers at socket.io. Here: https://socket.io/docs/#What-Socket-IO-is-not
I've just finished working through a book and RxJava, and whilst it answered a lot of questions I had, one still remains. How do I take a stream and allow a client to subscribe to it over HTTP (i.e. keep an open connection and stream events as they occur upstream)?
I'm content with the server-side details, but sending that to a client via HTTP seems to be a challenge. Whilst gRPC could be a great option, it's not supported in browsers. The Streams Spec looks like a good option once it is implemented. However, at this point in time, those are not viable options.
To achieve streaming functionality (e.g. from a, I presume, REST/JSON API to a client web-site), am I looking at SocksJS / websockets? Or is there some other protocol that can be harnessed?
I know that ActiveMQ supports the JMSXUserID property:
http://activemq.apache.org/jmsxuserid.html
I'm trying to use Apollo (an ActiveMQ sub-project) instead of ActiveMQ, and at the moment I'm stuck trying to figure out to replicate that same behavior in Apollo.
I'm not picky about the mechanics, but in a nutshell I need some way to tag every incoming message from an authenticated user with an identifier that lets me know which user sent which message, but in a way that users can't spoof by setting themselves. This is basically exactly what JMSXUserID is used for by ActiveMQ, but I can't seem to figure out how to do the same thing in Apollo.
What am I missing?
I'm finding this especially difficult to Google for, since ActiveMQ links to Apollo on every single one of its pages so most of my search results are unhelpful.
Thanks in advance.
Apollo's user manual describes how you can configure apollo to automatically add a user header which is set to the sending user's id.
Basically you want to configure the connector's stomp protocol with something like:
<connector id="tcp" bind="tcp://0.0.0.0:61613">
<stomp>
<add_user_header separator=",">JMSXUserID</add_user_header>
</stomp>
</connector>
Unfortunately the Openwire protocol does not support this yet. Issue APLO-213 is open to address it.
Does Apollo even support JMS?
from web page: http://activemq.apache.org/apollo/
In it’s current incarnation, Apollo only supports the STOMP protocol but just like the original ActiveMQ, it’s been designed to be a multi protocol broker. In future versions it will be adding OpenWire support so it can be compatible with ActiveMQ 5.x JMS clients.
To solve your very problem at hand, can't you simply add a header with the userid in the code?
Just grab it from the OS, say you are using Java, then you could perhaps use something like
System.getProperty("user.name")
and attach it to a STOMP header. This is, however, an issue for the client lib (stomp library, if any is used) rather than the server itself.
Socket.IO seems to be the most popular and active WebSocket emulation library. Juggernaut uses it to create a complete pub/sub system.
Faye is also popular and active, and has its own javascript library, making its complete functionality comparable to Juggernaut. Juggernaut uses node for its server, and Faye can use either node or rack. Juggernaut uses Redis for persistence (correction: it uses Redis for pub/sub), and Faye only keeps state in memory.
Is everything above accurate?
Faye says it implements Bayeux -- i think Juggernaut does not do this -- is that because Juggernaut is lower level (IE, I can implement Bayeux using Juggernaut)
Could Faye switch to using the Socket.IO browser javascript library if it wanted to? Or do their javascript libraries do fundamentally different things?
Are there any other architectural/design/philosophy differences between the projects?
Disclosure: I am the author of Faye.
Regarding Faye, everything you've said is true.
Faye implements most of Bayeux, the only thing missing right now is service channels, which I've yet to be convinced of the usefulness of. In particular Faye is designed to be compatible with the CometD reference implementation of Bayeux, which has a large bearing on the following.
Conceptually, yes: Faye could use Socket.IO. In practise, there are some barriers to this:
I've no idea what kind of server-side support Socket.IO requires, and the requirement that the Faye client (there are server-side clients in Node and Ruby, remember) be able to talk to any Bayeux server (and the Faye server to any Bayeux client) may be deal-breaker.
Bayeux has specific requirements that servers and clients support certain transport types, and says how to negotiate which one to use. It also specifies how they are used, for example how the Content-Type of an XHR request affects how its content is interpreted.
For some types of error handling I need direct access to the transport, for example resending messages when a client reconnects after a Node WebSocket dies.
Please correct me if I've got any of this wrong - this is based on a cursory scan of the Socket.IO documentation.
Faye is just pub/sub, it's just based on a slightly more complex protocol and has a lot of niceties built in:
Server- and client-side extensions
Wildcard pattern-matching on channel routes
Automatic reconnection, e.g. when WebSockets die or the server goes offline
The client works in all browsers, on phones, and server-side on Node and Ruby
Faye probably looks a lot more complex compared to Juggernaut because Juggernaut delegates more, e.g. it delegates transport negotiation to Socket.IO and message routing to Redis. These are both fine decisions, but my decision to use Bayeux means I have to do more work myself.
As for design philosophy, Faye's overriding goal is that it should work everywhere the Web is available and should be absolutely trivial to get going with. I'ts really simple to get started with but its extensibility means it can be customized in quite powerful ways, for example you can turn it into a server-to-client push service (i.e. stop arbitrary clients pushing to it) by adding authentication extensions.
There is also work underway to make it more flexible on the server side. I'm looking at adding clustering support, and making the core pub-sub engine pluggable so you could use Faye as a stateless web frontend for another pub-sub system like Redis or AMQP.
I hope this has been helpful.
AFAIK, yes, apart from the fact Juggernaut only uses Redis for Pubsub, not persistence. Also means client libraries in most languages have already been written (since it just needs a Redis adapter).
Juggernaut doesn't implement Bayeux, but rather has a very simple custom JSON protocol
I don't know, but probably
Juggernaut is very simple, and designed to be that way. Although I haven't used Faye, from the docs it looks like it has a lot more features than just PubSub. Being built on top of Socket.IO has it advantages too, Juggernaut's supported in practically every browser, both desktop and mobile.
I'll be really interested in what Faye's author has to say. As I say, I haven't used it and it would be great to know how it compares to Juggernaut. It's probably the case of using the best tool for the job. If it's pubsub you need, Juggernaut does that very well.
Faye certainly could.
Another example of a similar project on top of Socket.IO:
https://github.com/aaronblohowiak/Push-It
EDIT: I forgot to include the prime candidate for web applications: JSON over HTTP/REST + Comet. It combines the best features of the others (below)
Persevere basically bundles everything I need in a server
The focus for Java and such is definitely on Comet servers, but it can't be too hard to use/write a client.
I'm embarking on an application with a server holding data, and clients executing operations which would affect this data, and thus require some sort of notification across all interested/subscribed clients.
The first client will probably be written in WPF, but we'll probably need to add clients written in other languages, e.g. a Java (Swing?) client, and possibly, a web client.
The actual question(s): What protocol should I use to implement this? How easy would it be to integrate with JS, Java and .NET (precisely, C#) clients?
I could use several interfaces/protocols, but it'd be easier overall to use one that is interoperable. Given that interoperability is important, I have researched a few options:
JSON-RPC
lightweight
supports notifications
The only .NET lib I could find, Jayrock doesn't support notifications
works well with JS
also true of XML-based stuff (and possibly, even binary protocols) BUT this would probably be more efficient, thanks to native support
Protobuf/Thrift
IDL makes it easy to spit out model classes in each language
doesn't seem to support notifications
Thrift comes with RPC out of the box, but protobufs don't
not sure about JS
XML-RPC
simple enough, but doesn't support notifications
SOAP: I'm not even sure about this one; I haven't grokked this yet.
seems rather complex
Message Queues/PubSub approach: Not strictly a protocol, but might be fitting
I hardly know anything about them, and got lost amongst the buzzwords`-- JMS? **MQ?
Perhaps combined with some RPC mechanism above, although that might not be strictly necessary, and possibly, overkill.
Other options are, of course, welcome.
I am partial to the pub/sub design you've suggested. I'd take a look at ZeroMQ. It has bindings to C#, Java, and many other platforms.
Bindings list: http://www.zeromq.org/bindings:clr
I also found this conversation on the ZeroMQ dev listing that may answer some questions you have about multiple clients and ZeroMQ: http://lists.zeromq.org/pipermail/zeromq-dev/2010-February/002146.html
As XMPP was mentioned, SIP has a similar functionality. This might be more accessible for you.
We use Servoy for this. It does automatic data broadcasting to web-clients and java-clients. I'm not sure if broadcasts can be sent to other platforms, you might be able to find an answer to that on their forum.
If you want to easily publish events to clients across networks, you may wish to look at a the XMPP standard. (Used by, amongst other things, Jabber and Google Talk.)
See the extension for publish-subscribe functionality.
There are a number of libraries in different languages including C#, Java and Javascript.
You can use SOAP over HTTP to modify the data on the server and SOAP over SMTP to notify the subscribed clients.
OR
The server doesn't know anything about the subscription and the clients call the server by timeout to track updates they are interested in, using XML-RPC, SOAP (generated using WSDL), or simply HTTP GET if there is no need to pass back complex data on tracking.