search

loopbackio / loopback-next

LoopBack makes it easy to build modern API applications that require complex integrations.
https://loopback.io
Other
4.96k stars 1.07k forks source link

WebSocket connector support #1883

Closed pktippa closed 4 years ago

pktippa commented 6 years ago

Description / Steps to reproduce / Feature proposal

@bajtos rising here. Original request in LB3

https://github.com/strongloop/loopback/issues/327#issuecomment-431006523#

Current Behavior

Expected Behavior

See Reporting Issues for more tips on writing good issues

bajtos commented 6 years ago

@pktippa thank you for opening the issue. Could you please clarify whether you are looking for a websocket client (allowing your LB4 server app to connect to another WebSocket server), a websocket server (allowing an LB4 server to accept incoming websocket connections e.g. from a single-page HTML5 applications) or both?

If both, which part is more important to you? 1. accept incoming websockets 2. connect to 3rd party services via outgoing websockets.

raymondfeng commented 6 years ago

I would like to include this discussion into a broader one - how to support messaging/eventing style APIs with corresponding transports. I'll open a new issue to cover various use cases and possible solutions.

raymondfeng commented 6 years ago

See https://github.com/strongloop/loopback-next/issues/1884

pktippa commented 6 years ago

@bajtos I have seen the issue description of @raymondfeng , it serves the purpose of what we are looking for. thanks

raymondfeng commented 5 years ago

See a PoC at https://github.com/raymondfeng/loopback4-example-websocket

ElHupeke commented 5 years ago

@bajtos, like with Fireloop and LB3, my clientapps got automatically the updates from server app of Fireloop. I think realtime database are a must have. Fireloop isn't developed anymore and would be fantastic to have in LB4!

jgwinner commented 5 years ago

It's so true. People expect this behavior. They watch the screen, new data comes in and they just see it expand. No refreshes.

That's my problem even with the LB3 samples; most of them seem to be "Chat apps" that show a totally different API than access any data through LB. If you're going to do that, you don't need LB in the middle.

One of the reasons I chose LB is that I thought the work we did to obtain data and display it wouldn't be lost when we went to real time. Now, there's more architecture work than I expected.

One of my guys did something pretty neat, he just implemented a periodic "Get" on the data; same code does the initial page reload as the subsequent updates. However, I'd prefer a server driven push than polling. At least it's working.

I agree about LB4. That's one of the dilemmas; along with ACL's, realtime really is important.

We're looking at Fireloop. At least the code is there, but seems like a big task to take on. Onixjs.io seems to be down too.

    == John ==
raymondfeng commented 5 years ago

For inbound, https://github.com/raymondfeng/loopback4-example-websocket should be a good starting point. I'm considering to refine it into @loopback/socketio so that:

  1. We can expose websocket endpoints
  2. We can implement logic in controllers with websocket specific decorators

For outbound, we also had a PoC at https://github.com/strongloop/loopback4-example-kafka. I'm expecting to build connectors/service-proxies for messaging (especially pub/sub) backends.

jgwinner commented 5 years ago

Thanks Raymond, I'll check them out.

To be clear, the use case I was looking at is something like this:

1) Client side, obtain some data via Loopback 2) Process it, display on screen. If something writes to the database then: 3) The server pushes the data if the socket still open; the client then updates the data in the same code used in 2, and updates the screen display.

The code could be slightly different, as a first time 'get' would be straight forward, whereas updated data would have some formatting decisions ... sorting, filtering, pagination, etc. In principal, mostly the same.

The client would do this on an API by API basis; not everything needs to be real time.

    == John ==
stale[bot] commented 4 years ago

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

stale[bot] commented 4 years ago

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.