This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
[Question] Websocket Support? #528
Comments
|
That would be a killer feature, if opening Websockets, reading the stream and sending messages through the UI would be possible. |
|
To be honest, I currently have no plans to support websockets, but I also don't work with them so don't understand how the workflow would be different from regular HTTP requests. I'm also not sure if Are there any awesome websocket debugging tools out there? I would love to be enlightened both about existing tools and what your ideal workflow would look like. |
gschier
changed the title
insomnia likely to support websocket?insomnia likely to support websocket?
gschier
changed the title
insomnia likely to support websocket?
|
Hi gschier. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Probably one of the major differences would be that websocket, like most messaging protocols, isn't required to be designed around the request/response paradigm. Websockets can stream events, and messages either way might not elicit responses. The connections are much more likely to persist beyond the length of the request. So you'd probably want some type of persistent connection management. Either with predefined endpoints that you could reference, or with endpoint templates. Honestly, I'd love a few more dimensions in the configuration templating anyway. There are times when I want to flip more switches and turn more knobs than the base and sub-environments allow for. Sub-environments really only let you change one set of values, so you end up with more sub-environments than necessary, or you end up manually changing some values in different environments. For request/response messages, the interface could be very similar to what it is now. If you're sending your messages slowly and synchronously, it'll work fine. But it's probably not a bad idea to consider an additional websocket data pane that streams the messages as they come in. It'd be handy for things like event subscriptions, Maybe you could check the URI for the With Websocket, you can send several messages at once and be waiting for responses to all of them. Generally users who need to directly relate responses to the original requests over websocket, they'll have some means of doing so in the message itself. For structured messages like JSON and XML, you'd add a property that matches one provided in the request. This could be pretty tricky to implement, as you might need two filters: one for the request and one for the response to pair them. Websockets can also send strings and binary data, which could require more complex logic to parse the messages. For complex binary messages (e.g. protobuf), you might need plugins that understand the logic and can load the definition files. But honestly, just JSON/XML/string support would be a huge step forward. Binary support is a much lower priority, And initial implementations could leave all parsing to the user. Once you've got a basic configuration interface for event streaming, people could look into adding alternate messaging implementations like socket.io, SignalR or STOMP. Binary message support and protocol definitions (e.g. .proto files) could be another thing to start working into plugins (e.g. gRPC, but implemented over HTTP). |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Can we reopen this? It's still a valid request. |
|
I agree. I think this would be a great idea, and would really help with my testing. |
|
+1 |
|
+1 |
9 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
Please refrain from leaving Thanks! ❤️ |
|
People are leaving +1s because the stale bot keeps wanting to deprecate the issue and everyone's really interested in the feature. If it wasn't at risk of being closed, you'd probably have a lot less drive-by +1s. Also, Lizhooh and I provided some feedback at the end of last year/beginning of this one, but we got no response or acknowledgement of it. And, to add to the feedback, apparently curl does support some basic WS functionality if you set the headers properly to upgrade the connection from HTTP to WS. I'd imagine that might also be available in libcurl, but there's also other libraries available that can provide better interfaces when working with websockets. If libcurl isn't going to cut it, than maybe it's worth investigating/documenting a generic interface for requests/responses so other people can implement it with different libraries while not breaking too many things. That way you can pave the way for others to implement this. As it stands, it's probably too invasive for others to attempt it as it might not get merged after completion. If you're not interested in implementing the feature personally, that's fair. But letting it auto-close as stale doesn't seem to be the right approach, as it's a known feature that's very popular and in-demand. Plus, if you close it, people are just going to pop in and add new issues on the same topic. Have you considered adding an "Up for grabs" label indicating that others are free to implement it and telling the stale bot to leave issues with those tags alone? |
|
No help for me, the GraphQL server is not on the internet. Sent with GitHawk Besides if I did want something to test internet sites, I would use https://postwoman.io/graphql which has a beautiful interface. (reminds me of insomnia). |
|
I would also like to have support for GraphQL subscriptions (I realize that entails more than just websocket support, but the only other issue I found for it was closed). The other options for testing subscriptions aren't great right now. Postman also has GraphQL support, but supporting subscriptions would be a great way to differentiate Insomnia. |
|
Postwoman claims subscribe support. But it is internet only. Sent with GitHawk |
|
any idea about the timeline for the release of WebSockets support on Insomnia? (ps: I like this tool a lot! great job building it). |
|
I actually implemented my own (shitty and ugly) one-page WebSocket client for the application I'm testing (using stackoverflow, MDN, W3Schools, etc.), though with blackjack, and hookers! 😁 Here is the gist of it...ws = new WebSocket(url);
ws.onopen = () => {
console.log('Opened web socket');
connectionStatus.className = 'connected';
connectButton.style.display = 'none';
closeButton.style.display = '';
this.setMessageEditEnabled(true);
connectButton.removeAttribute('disabled');
for (const e of this.elementsToUndisable)
e.removeAttribute('disabled');
connected = true;
commands = null;
removeChildren(commandList);
document.getElementById('messageFormSection').style.display = 'none';
this.onMessage = this.onMessageWaitCommandDescriptions;
ws.send('{"some":{"initial":"request"}}');
};
ws.onclose = (e) => {
console.log('Closed web socket');
ws = null;
connected = false;
connectButton.style.display = '';
closeButton.style.display = 'none';
wsUrl.removeAttribute('disabled');
connectionStatus.className = 'disconnected';
this.setMessageEditEnabled(false);
for (const e of this.elementsToUndisable)
e.setAttribute('disabled', '');
};
ws.onmessage = (event) => {
this.onMessage(event);
};
ws.onerror = (event) => {
console.log('Failed to connect to web socket');
connectButton.removeAttribute('disabled');
};Not rocket science at all. |
|
OK, I decided that my shitty one-page WS client is polished enough (ha!) to share, with the hope it is useful for someone. I hope you can figure it out. As neat features there are indication of timestamps for messages, and calculation of time differences to previous and selected messages (hover messages to see the popup):
you can send selected message by clicking selected JSON message is shown as a tree on the right, you can search the tree with RegEx; it is written so that on connection we ask for the command descriptions: ws.onopen = () => {
console.log('Opened web socket');
//...
this.onMessage = this.onMessageWaitCommandDescriptions;
ws.send('{"request":"command_descriptions"}');
};
//...
onMessage: null,
onMessageWaitCommandDescriptions: function (event) {
const timestamp = Date.now();
if (event.data.lastIndexOf('{"request":"command_descriptions"}') != -1) {
try {
var response = JSON.parse(event.data);
this.commands = response.payload;
setCommands(commandList, this.commands);
this.onMessage = function (event) {
this.addMessage(event.data, 'in', Date.now());
};
return;
}
catch (e) {
console.log(e.message);
}
}
this.addMessage(event.data, 'in', timestamp);
},upon receiving the descriptions, commands appear on the left and show a form when clicked:
you can use the form to send requests or copy the resulting message to the editor by clicking If you don't want this functionality, just replace ws.onopen = () => {
console.log('Opened web socket');
//...
this.onMessage = function (event) {
this.addMessage(event.data, 'in', Date.now());
};
ws.send('{"request":"command_descriptions"}');
};Uncomment the dummy command description and messages to check out how it works. (click to expand)I'm really happy with it for the purposes of testing the app I'm working on, though I wish it is implemented in insomnia with all these features. Anything less than in this prototype will not be appealing to me anymore. Hope it's useful for someone. Please tell if it's not working for you, though don't expect immediate reply. Also feel free to use the code however you want. |
|
Also would like to see this feature in Insomnia, and in case it would help anyone - the best websocket client I've found so far is chrome extension WebSocket King Client |
|
It's very barebones but should work as inspiration if this feature is to be implemented using node-libcurl itself. |
Wow, that's awesome! There has not been much investigation into how WS support might be implemented yet, so this will be very useful when the time comes. In terms of UI, the gRPC feature-set (next in the pipeline) should provide many of the assets required for Websockets as well. |
|
@JCMais that would be great! I love Insomnia and i hope this feature will be added soon |
|
Socket Wrench has been helpful for me when testing websockets |
|
GraphQL subscription support in Insomnia would be great. So far the best tool I've found for testing GraphQL subscriptions is GraphQL Playground. It's pretty easy to enable inside of a node application using Apollo Server. |
Yeah but it is pretty messy if you are testing stuff in a lot of tabs |
True, I would much rather have subscription support in Insomnia. But Playground is the best I've found so far. |
I have Insomnia subscription from the begining of a project and I vote for websocket support, because we are using them a lot in our work.
|
|
Websocket support is a killer feature, even in most basic form it would be a life saver. |
|
i mean... it's not like the most requested feature or something... |
|
so I'm a developer on the insomnia team and I, too, would love this. While I haven't read every single sentence in the messages above, what I have read confirms a few things:
If nothing else, I'm gonna keep this in mind and see if I see a window to make some of the above challenges easier to tackle. Needless to say, this is on my radar - however I do not set product priorities. |
|
FYI, postman has supported it: https://blog.postman.com/postman-supports-websocket-apis/ |
|
@davix postman still does not allow saving websocket calls but Firecamp does |
|
Recent post from libcurl's author related to WebSockets support https://daniel.haxx.se/blog/2021/09/16/you-wanted-websockets/ |
|
This is the most upliked issue here (you can sort by Thumbs Up in the issue list). It's also the only reason which keeps me away from using Insomnia as our team API client. Would love to see this feature. |
|
Has there been any progress from 2017 to now? I saw that postman has already implemented support for websocket. |
|
anti stale bot bump |
|
Is this a feature that is coming to Insomnia any time soon? |
|
https://daniel.haxx.se/blog/2021/09/16/you-wanted-websockets/ GraphQL Subscription.... |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
and others
Is
insomnialikely to supportwebsocket?The text was updated successfully, but these errors were encountered: