Add support for WebSocket clients

[fmvilas]

Reason/Context

Currently, Glee only supports creating a WebSocket server. That makes it unusable when someone wants to build a WebSocket client to connect to an existing WS server.

Description

We already have support for WebSocket but it's always assuming we want to create a server, and that's plain wrong. Instead, Glee should default to creating a WS client and only create a server when we mark the server definition in the AsyncAPI file as "local".

For instance:

asyncapi: 2.3.0
servers:
  myWebsiteWebSocketServer:
    url: 'ws://mywebsite.com/ws'
    protocol: ws
    x-kind: local
  someProductWSServer:
    url: 'ws://someproduct.com/ws'
    protocol: ws

The server myWebsiteWebSocketServer is a WS server we want to create with Glee but the server someProductWSServer is a remote server we want to send/receive information to/from. The former is what's already implemented and the latter is what we should be implementing as part of this issue. Notice the x-kind: local on the myWebsiteWebSocketServer server. Only when this is found, we should create a server, otherwise, we should default to a client. Another allowed value for x-kind is remote.

Notes

x-kind is an extension we're creating as part of this issue, this is not defined anywhere yet so we have some freedom defining how we want it to be. I'm trying to make it as similar as possible to the Remotes and local servers issue on the spec. In v3, we may end up having two root keys: servers (local servers) and remotes (remote servers or brokers). For v2.x (the current version), I think it's just fine if we add the x-kind extension but I'm happy to listen for alternatives.

[deepanshu44]

Hello @fmvilas , I just want to ask that can I work on this issue? Is it difficult to solve this issue?
Thanks

[fmvilas]

Hey @deepanshu44! I'd say just go ahead but this issue is marked to be part of GSoC (Google Summer of Code) so I'm not sure how to proceed here. @derberg you are our GSoC expert, is it a problem? @deepanshu44 do you plan to participate at GSoC this year?

[deepanshu44]

@fmvilas thanks for replying, unfortunately I'm not a college student 🤔

[fmvilas]

No problem. Let's wait for @derberg to reply. I'm happy to remove the GSoC label from this issue if it's a problem. Don't want to leave anyone out :)

[derberg]

it is definitely ok to remove the label and move under https://www.asyncapi.com/blog/openforce-2022 and if you complete it in March we can at least send you an AsyncAPI t-shirt

[derberg]

just remember to update mentioned blog post with link to this issue if you want to commit to Open Force

[deepanshu44]

Thanks, @derberg, I will send a PR to the website with the link to this issue.
Sorry for the late reply, BTW.

Hello @fmvilas, I think I should get started on this issue. :-)
Edit: I would be glad if you direct me to a starting point.

[fmvilas]

@deepanshu44 I removed the gsoc label, meaning you can get started :)

Edit: I would be glad if you direct me to a starting point.

Absolutely. Glee supports different protocols via adapters. We already have a ws that is always assuming we want to create a WebSocket server. We should probably rename this adapter to ws-server and create another one called ws-client. After that, you have to edit the registerAdapters.ts file and add some logic there based on the AsyncAPI server definition, i.e., if it finds the x-kind: local property, it should register the ws-server adapter. Otherwise, it should register the ws-client adapter.

Notice how the server implementation also supports Socket.IO. So we'd also have to support creating a Socket.IO client. Also, notice that the config file supports customizing the WS implementation via the websocket property. We should also split this into client and server configurations. Or simply separate by websocket-client and websocket-server. Leave it up to you :)

Let me know if this is a good starting point. And in any case, I'm happy to help as you make progress. My recommendation is that you start a Draft PR as soon as you have a small/stupid change and I can help you there. Thanks a lot for taking the initiative 🙏

[deepanshu44]

Just an update, I wrapping my head around this problem which is taking some time.

[deepanshu44]

@fmvilas I sent a PR here with not so great changes 😅

[Souvikns]

@deepanshu44 are you still working on this? If you are and you are stuck I can help you and if not, let me know I would love to take it from your hand.

[deepanshu44]

@Souvikns Thanks for expressing interest. As I find it a bit difficult to work in this issue right now and it would take a bit more time to get back on this, I would like to handover this issue to you as don't want to act as a bottleneck for this issue to get into production.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[fmvilas]

We're working on it on #319

[asyncapi-bot]

🎉 This issue has been resolved in version 0.12.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀