Loopback: websocket connector for loopback

[joshua1]

will be nice to be able to specify REST or web sockets as the channel API to expose.for instance using socket.io or a loopback socket connector.
if there is a websockets-connector kind of plugin for loopback that will access the same methods exposed via the rest api via web sockets.

An important thing to consider: support in native SDKS - iOS, Android, Xamarin.

See also https://github.com/strongloop/strong-remoting/issues/139

[dbryand]

+1

[michael-lee]

+1

[altsang]

duly noted, this is actually pretty high on our backlog and we hope to spike on it after our July release

[fotoflo]

+1

[telemakhos]

+1 for websockets support, and I think Primus would be a much better option since it allows you to effortlessly switch between real-time frameworks (Socket.io, Faye, SockJS, Engine.io, etc)

[gyss]

+1

[sandeshdamkondwar]

+1 I am excited to see websocket support

[dkarigithu]

• 1

[vovabezdna]

+1

[luckymancvp]

I'm sorry. But currently we can't create realtime service with loopback.io. Is that right ?
Please tell me

[telemakhos]

@luckymancvp Well, you can, but you have to bake it yourself... see https://groups.google.com/forum/#!topic/loopbackjs/6qpQwggf2_c

[HansHammel]

+1

[steve8708]

+1

[nikita-leonov]

It was scheduled for 2.0 milestone. 2.0 released, did I get it right that it was rescheduled for further versions?

[bajtos]

Yes, I have removed the issue from the 2.0 milestone.

[yagobski]

+1

[coodoo]

I just started working on a lightweight real-time notifier based on loopback model, will post here when it's done.

[yagobski]

Thanks When you think it will be released?

[vvhh2002]

+1

[johnwook]

+1

[altsang]

sounds great @coodoo , there's a spike on @ritch 's plate to do a websocket integration to strong-remoting. Keep in mind this is where we have protocol pluggability starting with REST for making APIs in the flavor and transport that you're expecting. Once that spike actually gets scheduled in our sprint I'll be sending a heads up to LoopBackJS

thx again!

[robotiko]

+1

[valentinkostadinov]

+1

[raymondfeng]

I think we should start a wiki page to better understand the use cases and capture the expectations of the programming model. Let's say we want to develop a chat server api over websocket, how would the api look like and how would you write a Node.js class/model to back the apis.

[bajtos]

IMHO, chat server is not the most important use case. A real time replication of changes between the server and an isomorphic client is a more interesting one.

[thomasvanlankveld]

+1

[raymondfeng]

There is a good summary at http://www.javaworld.com/article/2071232/java-app-dev/9-killer-uses-for-websockets.html:

1. Social feeds
2. Multiplayer games
3. Collaborative editing/coding
4. Clickstream data
5. Financial tickers
6. Sports updates
7. Multimedia chat
8. Location-based apps
9. Online education

I would also like to highlight IoT use cases.

[thomasvanlankveld]

For me specifically: IoT combined with a reservation system

[coodoo]

I'm with @bajtos here, the main use for me is "A real time replication of changes between the server and an isomorphic client is a more interesting one.", plus, a socket-based change notifier for thin client that doesn't need sync functionality (meaning no lbclient on the client side).

I actually had spec'd out the socket-adaptor and figured out how to hook it into the loopback system, currently working on a POC, should be a fun side project.

[raymondfeng]

@coodoo Would you like to share your PoC?

[coodoo]

@raymondfeng Sure, once it gets into shape I will put it up on github.

Here's what I got so far:

1. A simplified version of loopback-example-full-stack, using only jquery on the client side so it's easier to understand.
2. A lightweight notifier-sender/receiver for thin client use cases
3. A lightweight notifier-sender/receiver for fat client use cases (running lbclient in the browser, this is close to what @bajtos meant, but only the change notification is communicated in real-time, not the model itself)

Next I'm starting out to build the socket-adaptor so we have a real-time transport, mostly based on @ritch's implementation about one year ago.

[surfjedi]

+1

[bajtos]

The connector implementation should consider native SDKs too, the design should make it possible to implement a realtime client in loopback SDKs for iOS, Android and Xamarin.

[kevinsproles]

+1

[matgnt]

+1

[psi-4ward]

+1

[altsang]

see strongloop/strong-remoting#127

[bajtos]

@raymondfeng @ritch I wrote down a simple example that covers both chat-server and change-replication, we can use it as a guide on what has to be implemented.

https://gist.github.com/bajtos/b7e001423e17fad457ae

[voitau]

Great and desired feature. May I friendly ask whether there are some plans to introduce it anytime soon?

[danil-z]

+1

[gagan-bansal]

+1

[bdjibril]

+1

[thomasvanlankveld]

Maybe interesting to look at DDP? This protocol is the reason I ended up using Meteor for my realtime application. It really simplifies your communication by combining the PubSub and Remote Procedure Call patterns.

PubSub is great for keeping your client object model up to date, and it scales really well in terms of increasing complexity. Conceptually, this fits really well on any resource-based backend, but I'm not sure how easy it is to implement, considering the server will need to keep track of the client object models.

The Remote Procedure Calls are great at bringing intent into your communication. It's always bothered me about REST that strictly, it doesn't support named functions, which really takes the intent out of your communication. I really like that Loopback actively promotes creating named functions on resources. These could all be implemented as RPC. I also tend to find it easier to implement access control on named function to sort out what kind of action a certain POST or PUT request really is.

A big weakness for now is that hardly anyone uses DDP except for full-stack meteor developers. You're entering a kind of weak-support grey zone if you want to use it in native Android or iOS apps, any popular non-meteor browser client, or even if you want any kind of non-meteor backend.

If anyone has an opinion on this, I'd love to hear it!

[HilkoLantinga]

+1

[bajtos]

Maybe interesting to look at DDP? This protocol is the reason I ended up using Meteor for my realtime application. It really simplifies your communication by combining the PubSub and Remote Procedure Call patterns.

IMO, we should modify strong-remoting to make it easy to use any custom transport (adapter) and provide at least basic documentation how to implement a custom transport.

That should empower the community to experiment with different transports, be it DDP, CoAP, SPDY, or anything else.

---

At the moment, both strong-remoting and LoopBack support RPC pattern only. We need to enhance both modules with PubSub semantics, preferably in a way that is transport-agnostic and thus support multiple PubSub protocols. This is our homework that must be done inside strong-remoting and loopback.

[johanvanark]

+1

[buxel]

Have you guys seen this? http://swarmjs.github.io/

[temp3l]

+1

[makersu]

Here's my Loopback with socket.io chat example.
https://github.com/makersu/loopbackchat

[HilkoLantinga]

Makersu, that's not what we are after. We want to use it to communicate to API's build with loopback.

[psi-4ward]

I ended up using sails.js cause getting the model create/update/delete notifications in my angular app is essential

[lukeliu9]

+1

[fusionstrings]

:+1:

[ilianaza]

+1

[makersu]

Is salis.js implementation like 3-way data binding with firebase and angular.js?
BTW, How to implement 3-way data binding with loopback?
Thanks!

[psi-4ward]

Back on loopback :smirk:

Heres my idea / implementation to mimic the sails-way: anguloop-example using
express-websocket and angular $httpSock service

@makersu theres no 3-way binding and for most usecases you dont want that but it should not a big deal to implement it. Keep in mind, this would result in many requests and database actions

[ritch]

At the moment, both strong-remoting and LoopBack support RPC pattern only. We need to enhance both modules with PubSub semantics, preferably in a way that is transport-agnostic and thus support multiple PubSub protocols. This is our homework that must be done inside strong-remoting and loopback.

@bajtos Instead of doing this in strong-remoting I'd prefer to leave strong-remoting as is and introduce a new module loopback-messaging. This will support things like bi-directional messaging, pub sub, etc. On top of this I'd like to build Model.subscribe() which would notify observers of model changes.

[arik-so]

+1

[telemakhos]

Is there an ETA for sprint65? can't wait to see this implemented... :grin:

[altsang]

@Telemakhos whoops - we are insprint 65, and it is slated to end 3/10, we run 2 week sprints that start on a Tuesday and end on the Monday the week after

[ghost]

+1

[jorgeramos]

+1

[mrbatista]

+1

[movibe]

+1

[rajaraodv]

+!

[lennybr]

+1

[Ijmir]

so it is not going to be in sprint 65?

[mattaylor]

+1 for https://github.com/gritzko/swarm

[altsang]

@ljmir - this capability has actually been rolled into a pub-sub feature that @ritch has been putting the finishing touches on, we're working on examples and docs at the moment - getting there folks! thx for your patience

[movibe]

thanks @altsang !

[altsang]

boy if you guys only knew how long this has been sitting in our backlog - :stuck_out_tongue: , proof though that we really do keep tabs on stuff wanted/needed and try to work on them when we're not having to meet customer reqs

been a long time coming...

[telemakhos]

Fantastic! Going to try this is an financial ticker we're building rather soon... Thanks to the StrongLoop team! I guess these are the packages...

https://github.com/strongloop/strong-pubsub
https://github.com/strongloop/strong-pubsub-primus
https://github.com/strongloop/strong-pubsub-mqtt

thanks for the MQTT addition btw! this is an unexpected surprise

[altsang]

that is correct, I'm really glad we were finally able to get this in, we're very close

a lot of the use cases are driven by our exposure to early IoT customers, aside from websocket with a Primus interface, MQTT, we're looking at STOMP next and others

[altsang]

closing this issue, folks please see strongloop/strong-pubsub#7, @ritch is putting the finishing touches on it!

[theblang]

@altsang Wonderful news! Like @psi-4ward, this is essential for my application.

[altsang]

@mattblang - it's out there, @ritch blogged out what it does, the next step is to marry it up with our replication capabilities to better support use cases like offline sync w/o having it be client initiated, what are you building if I may ask?

[0x7b1]

+1

[theblang]

@altsang I am building a tracking system with Angular that uses WebSockets to stay synced across clients.

[theblang]

@altsang Is it correct if I say that right now MQTT is the only protocol supported for pubsub?

[altsang]

@mattblang strong-pubsub is protocol and transport independent. You can use your own protocol or the MQTT module we built. We're considering supporting STOMP next up depending on customer demand. For transport, you might be interested in Primus to take advantage of wrap around websocket support. You could even do MQTT packets through websocket using Mosquito adapter. For more info - https://strongloop.com/strongblog/introducing-strongloops-unopinionated-pubsub/.

[colceagus]

+1
What is the status on this issue development ?

[cyclops24]

+1

[vpedrosa]

+1

[pktippa]

+1 Much needed feature in loopback, atleast take this up in
https://github.com/strongloop/loopback-next

[bajtos]

@pktippa thank you for chiming in. Could you please open a new issue in https://github.com/strongloop/loopback-next to discuss the WebSocket server and/or client, depending on what you are looking for?

[pktippa]

@bajtos done!.

[bajtos]

Thanks. Let's move further discussion to https://github.com/strongloop/loopback-next/issues/1883 then.