I've been recently learning about vertx and websocket.
What I understood that you can have real-time application using them, but I didn't understand the difference between them
A websocket lets you push messages from server to client and vice-versa, encouraging the publish-subscribe methodology. Then what is vertx doing? It acts as an event bus and also encourages publish-subscribe model.
I can be completely wrong in my analysis, hence please correct me and I'll be glad. thanks.
WebSockets is a stateful protocol, usually used to communicate between clients and servers.
Vert.x is a server-side framework, which has a very good support for WebSockets.
You don't have to use WebSockets with Vert.x. But if you do want to use WebSockets, Vert.x is a great option.
Here's an article I wrote a few months ago about both:
https://medium.com/#alexey.soshin/playing-ping-pong-over-websockets-with-vert-x-447c634c6c87
Related
I'm playing around with Spring WebFlux and how to do async I/O in Java but it seems I need to set up a lot of boilerplates for managing websockets. For example, very common operations need to be re-implemented by hand:
websocket connect/disconnect
message broadcasting (to a list or all connected sockets)
gathering websockets in rooms
Is there any library (mature or in-development) to abstract complexity of managing websockets with
Spring WebFlux ? I'm looking for similar capabilities/API of the wonderful socket.io.
I took a (very brief) look at RSocket, it looks promising but still at a lower-level than socket.io for NodeJS.
Any help/guidelines would be greatly appreciated.
Does anybody has an example how to connect ActiveMQ OpenWire protocol using go please?
I used stomp & amqp with ActiveMQ for now and both are ok (testing), but our it architect will probably push for OpenWire as almost all our applications are Java based and that is standard for our company. So I would be happy for nay example, suggestions how to do it and not loose go service only because OpenWire protocol
thanks
Take a look at the ActiveMQ OpenWire documentation. It has a link to a handful of Java classes which are used to generate C, C#, C++, & Java client code. You could probably use those as examples to create your own files to generate Go client code which can speak OpenWire.
That said, you're probably better served by using the Go AMQP or STOMP clients as ActiveMQ was designed to be used by multiple protocols.
Thank you for answers. I agree with stomp & amqp as sufficient for task and agree that write OpenWire client just for sake of it is not good option. I have to convince our architects now
AMQP and OpenWire clients can co-exist and is by far the best solution for you, even though you have a Java-stack.
Your second best bet is to write some glue code in Java/C#/C++ that connects an OpenWire AMQ client with something that GO can speak to (like another ActiveMQ using AMQP or STOMP ;-) ).
If you really really really need OpenWire support, the best bet is to try to use the C++ client and call it using swig or whatnot.
Writing a native OpenWire-client in Go is a major effort and there is no point, except as a "fun" task.
Recently I am working with along with IOT department, right our project is on discussion and creating core architecture of an application. client specification is we must use MQTT protocol to communicate between device and java application (eclipse paho client).
its a web application based on spring boot and microservice architecture. but I an not able to find any good solution for API gateways that provide MQTT support.
I found zuul is good but do we have any alternative like kong..
MQTT is a TCP stream based protocol, so API Gateways that operate on the HTTP / Layer 7 are not going to fit the bill.
There are extensions to commercial API Gateways available, such as the Axway MQTT Proxy described here.
While not an API Gateway, Confluent also have a MQTT proxy that allows simple integration with Kafka, however if you have already written an application that implements the backend then Kafka is going to require some re-architecting.
The other options are really going for a simple TCP stream reverse proxy like nginx or HAProxy.
If I was asked to build something like this, I'd go straight to Kafka. It and MQTT are a very neat architectural fit and also operate very well together but it really depends on your requirements.
We are thinking about having a micro service architecture in our business application. We think about having the communication via ampq. With this researches that i made for that, the question comes up: How to standardise the communication while programming?
For example: If you do some database requests you can use spring-data-jpa that creates for you the code to send those requests.
Isn't there a way to use something like that for AMQP requests if you need an object from another service, something like an AMQPRepositories to have this standardised way?
Does someone has some other ideas or made some experiences with that?
Our current implementation has an abstraction layer separating out (quite) a few interface apis like start, close, etc., essentially following the Template Pattern.
Is there a better way to do so?
Not an expert on Spring, but could Spring be our answers?
Short answer: No.
Longer answer: The APIs and protocols are different. Spring or similar frameworks won't help you. A common abstraction layer would be a subset, feature wise, of both AMQ(JMS) and RMQ (AMQP).
In theory, you could try to connect to RMQ with JMS (like the client JMS lib of Apache QPid). It won't support all features of AMQP, and last time I tried, I merly got a connection running. So don't go there. Or go by some common supported wire protocol, such as MQTT (very limited).
I think you are on the right way - write your own abstraction that supports the subset of features you need.