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
Related
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
I am trying mostly for learning purposes to implement a module similar to SignalR(still a beginner in SignalR) using raw websockets. (I am already very familiar with websockets)
Is there any guide or something that explains what functionality does SignalR have on top of websockets? (so that i know what features i need to implement) ? .
From what i understood it keeps a persistent connection , and can fallback to other protocols if websockets are not supported (long polling ...etc).
I have already checked this video but i need something more in detail.
I had written one article regarding SignalR one year back. It contains SignalR basic information and code example.
Following is the link of it -
https://medium.com/#aparnagadgil/real-time-web-functionality-using-signalr-ba483efcb959
Hope this helps you!
I've been reading about websockets and SaaS like Pusher and Socket.io recently, while working on my Laravel chat practice application. What I don't understand is, why do we need external software to establish a websocket connection? Can't the server code like Laravel just directly establish the connection with the front-end like Vue.js? Why does it have to go through the middleman like Pusher and Socket.io? Sorry for the noob question.
It doesn't have to.
Those pieces of software just happen to make it trivial to work with the Websocket protocol.
Remember, Laravel is an opinionated framework. This means that it will pick and choose its own libraries to abstract away these kinds of concepts for you so that you don't have to worry so much about what's going on under the hood.
Basically, there are two components that you need in order to be able to work with Websockets:
A Websocket Server
A Websocket Client
The reason Laravel doesn't communicate directly with the front-end using Websockets is because Laravel itself isn't a Websocket server. At least, not really. And while PHP does have support for working with the Websocket protocol - and even some libraries to leverage it a little more nicely - it just isn't used to handle long-lived processes as often as other languages.
Instead, Laravel uses the Pub/Sub functionality that Redis provides to listen to events that occur through Redis and the Predis library. The reason why it does this is because Laravel is better-suited as a middle-man for the websocket server, and all connected clients.
In this way, Laravel can both pass information up through to the Websocket server using Broadcasting Events, as well as receive event information from the Websocket server and determine if users have the ability or authorization to receive them.
If you don't want to use Pusher, there is a library that will allow you to run your own Websocket Server specifically for Laravel called Laravel Echo Server.
Under the hood, this library still uses Socket.io and Redis in order for all moving parts to communicate with each other seamlessly in a Laravel web application. The benefit here is that you won't need to worry about the number of messages being sent by the server.
The downside is that you now have to know how to manage and maintain this process on your server so that the Websocket Server will know to turn on every time you restart your server, or if a failure happens, etc.
Check out PM2 to learn more about running and maintaining server daemons.
If you don't agree with Laravel's opinions on how to handle Websockets, then you could theoretically use any other server-side language to handle the websocket protocol. It will just require a greater working knowledge of the protocol itself; and if Laravel needs to work with it, you'll have to know how to write the appropriate Service and Provider classes to be able to handle it.
Short answer? You don't have to use them. Knock yourself out writing your own server and client side websocket implementation.
Longer answer.
Why use Laravel? I can do all that with straight up PHP.
Why use Vue? I can do all that with vanilla javascript.
We use libraries and frameworks because they abstract away the details of implementation and make it easier to build products. They handle edge cases you don't think of or things you don't even know that you don't know about because they are used by thousands or millions of developers and all the knowledge and bugs they have encountered and fixed are baked into the implementation.
This is one of the hallmarks of software engineering, code reuse. Don't repeat yourself and don't write any software you don't have to. It allows you to focus on building a solution for your particular requirements, and not focus on building a bunch of infrastructure before you can even build your solution.
I've never used Pusher, but it looks like, yes, it is a SaaS product. But Socket.io is open source.
I've taken a look at the basic websocket capabilities in Dart, using this simple example:
https://github.com/financeCoding/chat-websocket-dart
But I was wondering if there's a nice library I could use to build a realtime online game using websockets. I've had experience in this using node.js with socket.io, which worked out quite well. I need to be able to have "rooms", join rooms, leave rooms, broadcast to clients in a room, etc. as well as some nice notion of connection "health", reconnection etc. So what I'm asking is if there's a nice library for dart that has similar functionality? Even cooler would be a library on top of that library that could enable nice RPC functionality with variable syncing etc. such as http://nowjs.com/ which achieves this using socket.io. But I guess that might be too ambitious.
If anyone's had any experience or found a project which is similar to what I'm talking about, let me know :)
Duct is clone of Socket.IO in Dart which aims to be protocol-level compatible with the original implementation.
https://github.com/petrhosek/duct
Sorry, at the time of this writing, I'm not aware of a socket.io port for Dart. socket.io is nice because it has a bunch of implementation options for browsers that don't support Web sockets.
Sounds like a good idea for a hackathon project!
In our project our server must know as quickly as possible if a client gets disconnected.
Is there a effective way to implement this? Maybe with the GWTEventService or a powerfull framework?
You have a few options:
You can check out Comet. Comet was designed for this kind of behavior, where you intend to push data to the client without the client explicitly requesting it. Check out Wikipedia's article about Comet for more information. There's a GWT implementation of it here: gwt-comet.
Alternatives: You could use something like Spring Framework to keep tabs on your clients. You could also implement a heartbeat-style approach, where you force the client to hit a given page every X seconds so you know they're still connected.
Honestly, there are countless ways to do what you're looking for here. I'd say Comet would be your best bet if you don't mind implementing a whole framework.