Re: Websockets for graph data streaming

[Zala Pierre GOUPIL]

Good morning,

Would you mind sharing that library with us, please?

Regards,

Pierre Goupil



Le 8 mars 2017 09:28, "Gonzalo Aguilar Delgado"  a
écrit :

> Hi Martin,
>
> Thank you a lot. I'm almost done!!!
>
> It's so great. I made a clientside library that allows widgets to register
> for data streams. And the Websockets library integrated with Wicket
> subscribe delivers the specific data to each subscriptor.
>
> It takes just one connection. And I loove it!
>
> Best regards,
>
> El 07/03/17 a las 21:45, Martin Grigorov escribió:
>
> Hi,
>
> On Tue, Mar 7, 2017 at 10:07 AM, Gonzalo Aguilar Delgado 
>  wrote:
>
>
> Hi Martin,
>
> I must say I was working with websockets yesterday. And it's delightful
> experience. Have to check how it does scale but it seams just great.
>
> I have a doubt. Since I'm doing fully async I'm doing fully async request
> with WebSocketResource. I suppose that there's no way to update the
> interface from there. I mean, if we are sending a message because a model
> changed on server. Can I trigger the repain of a widget? I suppose this
> option is only available if using behavior right?
>
>
> Correct!
>
>
>
> I saw the broadcast example you did. But does it worth mix WebSocketResource
> and WebSocketBehavior?
>
> What is best, more scalable?
>
>1. Doing a WebSocketResource with 1 connection that via Javascript
>notifies all components in page.
>2. Use WebSocketResource + 1 WebSocketBehavior per component, and then
>broadcast to all.
>
> Even if you have many WebSocketBehaviors in your components Wicket will
>
> create only one WebSocket connection per page. A web socket message sent by
> the browser will be delivered to all behavior instances. You have to decide
> whether the message is applicable for a given behavior or should be
> discarded.
>
> The drawback of using WebSocketBehavior is that during the processing of a
> message the Page instance will be locked, so WS messages are processed
> sequencially and any Ajax requests at the same time will wait for the page
> to be unlocked.
>
>
>
>
>
> As I told what I'm doing is a Javascript hub that receives messages (via
> WebSocketResource) and sends to the widgets async so they can update. But
> I suppose that following this approach it's quite difficult update
> components from Javascript. And so the opposite. If a component updates
> it's internal model on server, there's no way to push to the interface.
>
> Can I have both? The ability to update components (graphs mainly) from
> javascript datasource, but from time to time, update components on wicket
> and send updates to the UI (html)?
>
>
> You can use org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster to
> repaint Wicket components initiated at the server side. You will need to
> preserve the page id to able to notify a specific page. Or
> WebSocketBehavior should keep some extra information, e.g. userId, to
> decide whether a given PushMessage is for it or not.
>
>
>
> Best regards,
>
>
>
> El 06/03/17 a las 09:08, Martin Grigorov escribió:
>
> Hi,
>
>
> On Mon, Mar 6, 2017 at 3:57 AM, Gonzalo Aguilar Delgado 
>   wrote:
>
>
> Hello,
>
> I'm using the fantastic Decebals dashboard, adding a widget json
> registry and some other improvements. The idea is to provide data
> streaming functionality like the one provided by graphana, kibana and
> friends.
>
> So the server will contain the datasources. And the dashboard will apply
> to one or more datasources on the server.
>
> But I don't know what's the best way to go with wicket.
>
> My first idea is to provide a websocket connection with a DataManager
> for each user dashboard (only 1 at a time active), subscribe to
> datasources, and receive the streaming over the websockets. The
> DataManager then will keep track of what topic each chart wants to
> receive and multiplex the result to each chart via Javascript.
>
> This way there's only 1 connection to the server. But data can be shared
> among widgets. I suppose it's not easy task.
>
> The other way is do ajax with each chart. But I think this would make a
> lot of calls to the server and I suppose it's not scalable.
>
> S. What's the best way to go?!
>
>
> I'd use WebSockets for this!
>
>
>
> Any good chart integration on wicket apart of highcharts? D3js or
> similar...
>
>
> The demo app forhttp://wicketinaction.com/2012/07/wicket-6-native-websockets/ 
> uses Google
> Charts library without any Wicket component integration.
>
>
>
> Preview of the current work is this link:
>
> https://pbs.twimg.com/media/C6M_hG6WYAEeysz.jpg
>
>
>
> --
> [image: Gonzalo Aguilar Delgado] *Level2 CRM*
>   Gonzalo Aguilar Delgado
>   Consultor CRM - Ingeniero en Informática
>
> M. +34 607 81 42 76 <+34%20607%2081%2042%2076> <+34%20607%2081%2042%2076>
> T. +34 918 40 95 78 <+34%20918%2040%2095%2078> <+34%20918%2040%2095%2078>
> E. 

Re: Websockets for graph data streaming

[Martin Grigorov]

You made my day, Gonzalo!
Awesome!


On Wed, Mar 8, 2017 at 9:10 AM, Gonzalo Aguilar Delgado <
gagui...@level2crm.com> wrote:

> Hi Martin,
>
> Thank you a lot. I'm almost done!!!
>
> It's so great. I made a clientside library that allows widgets to register
> for data streams. And the Websockets library integrated with Wicket
> subscribe delivers the specific data to each subscriptor.
>
> It takes just one connection. And I loove it!
>
> Best regards,
>
> El 07/03/17 a las 21:45, Martin Grigorov escribió:
>
> Hi,
>
> On Tue, Mar 7, 2017 at 10:07 AM, Gonzalo Aguilar Delgado 
>  wrote:
>
>
> Hi Martin,
>
> I must say I was working with websockets yesterday. And it's delightful
> experience. Have to check how it does scale but it seams just great.
>
> I have a doubt. Since I'm doing fully async I'm doing fully async request
> with WebSocketResource. I suppose that there's no way to update the
> interface from there. I mean, if we are sending a message because a model
> changed on server. Can I trigger the repain of a widget? I suppose this
> option is only available if using behavior right?
>
>
> Correct!
>
>
> I saw the broadcast example you did. But does it worth mix WebSocketResource
> and WebSocketBehavior?
>
> What is best, more scalable?
>
>1. Doing a WebSocketResource with 1 connection that via Javascript
>notifies all components in page.
>2. Use WebSocketResource + 1 WebSocketBehavior per component, and then
>broadcast to all.
>
> Even if you have many WebSocketBehaviors in your components Wicket will
>
> create only one WebSocket connection per page. A web socket message sent by
> the browser will be delivered to all behavior instances. You have to decide
> whether the message is applicable for a given behavior or should be
> discarded.
>
> The drawback of using WebSocketBehavior is that during the processing of a
> message the Page instance will be locked, so WS messages are processed
> sequencially and any Ajax requests at the same time will wait for the page
> to be unlocked.
>
>
> As I told what I'm doing is a Javascript hub that receives messages (via
> WebSocketResource) and sends to the widgets async so they can update. But
> I suppose that following this approach it's quite difficult update
> components from Javascript. And so the opposite. If a component updates
> it's internal model on server, there's no way to push to the interface.
>
> Can I have both? The ability to update components (graphs mainly) from
> javascript datasource, but from time to time, update components on wicket
> and send updates to the UI (html)?
>
>
> You can use org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster to
> repaint Wicket components initiated at the server side. You will need to
> preserve the page id to able to notify a specific page. Or
> WebSocketBehavior should keep some extra information, e.g. userId, to
> decide whether a given PushMessage is for it or not.
>
>
>
> Best regards,
>
>
>
> El 06/03/17 a las 09:08, Martin Grigorov escribió:
>
> Hi,
>
>
> On Mon, Mar 6, 2017 at 3:57 AM, Gonzalo Aguilar Delgado 
>  
>  wrote:
>
>
> Hello,
>
> I'm using the fantastic Decebals dashboard, adding a widget json
> registry and some other improvements. The idea is to provide data
> streaming functionality like the one provided by graphana, kibana and
> friends.
>
> So the server will contain the datasources. And the dashboard will apply
> to one or more datasources on the server.
>
> But I don't know what's the best way to go with wicket.
>
> My first idea is to provide a websocket connection with a DataManager
> for each user dashboard (only 1 at a time active), subscribe to
> datasources, and receive the streaming over the websockets. The
> DataManager then will keep track of what topic each chart wants to
> receive and multiplex the result to each chart via Javascript.
>
> This way there's only 1 connection to the server. But data can be shared
> among widgets. I suppose it's not easy task.
>
> The other way is do ajax with each chart. But I think this would make a
> lot of calls to the server and I suppose it's not scalable.
>
> S. What's the best way to go?!
>
>
> I'd use WebSockets for this!
>
>
>
> Any good chart integration on wicket apart of highcharts? D3js or
> similar...
>
>
> The demo app forhttp://wicketinaction.com/2012/07/wicket-6-native-websockets/ 
> uses Google
> Charts library without any Wicket component integration.
>
>
>
> Preview of the current work is this link:
>
> https://pbs.twimg.com/media/C6M_hG6WYAEeysz.jpg
>
>
>
> --
> [image: Gonzalo Aguilar Delgado] *Level2 CRM*
>   Gonzalo Aguilar Delgado
>   Consultor CRM - Ingeniero en Informática
>
> M. +34 607 81 42 76 <+34%20607%2081%2042%2076> <+34%20607%2081%2042%2076>
> T. +34 918 40 95 78 <+34%20918%2040%2095%2078> <+34%20918%2040%2095%2078>
> E. gagui...@level2crm.com
>
>
>
>
>
> --
> [image: Gonzalo Aguilar Delgado] 

Re: Websockets for graph data streaming

[Gonzalo Aguilar Delgado]

Hi Martin,

Thank you a lot. I'm almost done!!!

It's so great. I made a clientside library that allows widgets to
register for data streams. And the Websockets library integrated with
Wicket subscribe delivers the specific data to each subscriptor.

It takes just one connection. And I loove it!

Best regards,


El 07/03/17 a las 21:45, Martin Grigorov escribió:
> Hi,
>
> On Tue, Mar 7, 2017 at 10:07 AM, Gonzalo Aguilar Delgado <
> gagui...@level2crm.com> wrote:
>
>> Hi Martin,
>>
>> I must say I was working with websockets yesterday. And it's delightful
>> experience. Have to check how it does scale but it seams just great.
>>
>> I have a doubt. Since I'm doing fully async I'm doing fully async request
>> with WebSocketResource. I suppose that there's no way to update the
>> interface from there. I mean, if we are sending a message because a model
>> changed on server. Can I trigger the repain of a widget? I suppose this
>> option is only available if using behavior right?
>>
> Correct!
>
>> I saw the broadcast example you did. But does it worth mix WebSocketResource
>> and WebSocketBehavior?
>>
>> What is best, more scalable?
>>
>>1. Doing a WebSocketResource with 1 connection that via Javascript
>>notifies all components in page.
>>2. Use WebSocketResource + 1 WebSocketBehavior per component, and then
>>broadcast to all.
>>
>> Even if you have many WebSocketBehaviors in your components Wicket will
> create only one WebSocket connection per page. A web socket message sent by
> the browser will be delivered to all behavior instances. You have to decide
> whether the message is applicable for a given behavior or should be
> discarded.
>
> The drawback of using WebSocketBehavior is that during the processing of a
> message the Page instance will be locked, so WS messages are processed
> sequencially and any Ajax requests at the same time will wait for the page
> to be unlocked.
>
>>
>>
>> As I told what I'm doing is a Javascript hub that receives messages (via
>> WebSocketResource) and sends to the widgets async so they can update. But
>> I suppose that following this approach it's quite difficult update
>> components from Javascript. And so the opposite. If a component updates
>> it's internal model on server, there's no way to push to the interface.
>>
>> Can I have both? The ability to update components (graphs mainly) from
>> javascript datasource, but from time to time, update components on wicket
>> and send updates to the UI (html)?
>>
> You can use org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster to
> repaint Wicket components initiated at the server side. You will need to
> preserve the page id to able to notify a specific page. Or
> WebSocketBehavior should keep some extra information, e.g. userId, to
> decide whether a given PushMessage is for it or not.
>
>> Best regards,
>>
>>
>>
>> El 06/03/17 a las 09:08, Martin Grigorov escribió:
>>
>> Hi,
>>
>>
>> On Mon, Mar 6, 2017 at 3:57 AM, Gonzalo Aguilar Delgado 
>>  wrote:
>>
>>
>> Hello,
>>
>> I'm using the fantastic Decebals dashboard, adding a widget json
>> registry and some other improvements. The idea is to provide data
>> streaming functionality like the one provided by graphana, kibana and
>> friends.
>>
>> So the server will contain the datasources. And the dashboard will apply
>> to one or more datasources on the server.
>>
>> But I don't know what's the best way to go with wicket.
>>
>> My first idea is to provide a websocket connection with a DataManager
>> for each user dashboard (only 1 at a time active), subscribe to
>> datasources, and receive the streaming over the websockets. The
>> DataManager then will keep track of what topic each chart wants to
>> receive and multiplex the result to each chart via Javascript.
>>
>> This way there's only 1 connection to the server. But data can be shared
>> among widgets. I suppose it's not easy task.
>>
>> The other way is do ajax with each chart. But I think this would make a
>> lot of calls to the server and I suppose it's not scalable.
>>
>> S. What's the best way to go?!
>>
>>
>> I'd use WebSockets for this!
>>
>>
>>
>> Any good chart integration on wicket apart of highcharts? D3js or
>> similar...
>>
>>
>> The demo app 
>> forhttp://wicketinaction.com/2012/07/wicket-6-native-websockets/ uses Google
>> Charts library without any Wicket component integration.
>>
>>
>>
>> Preview of the current work is this link:
>>
>> https://pbs.twimg.com/media/C6M_hG6WYAEeysz.jpg
>>
>>
>>
>> --
>> [image: Gonzalo Aguilar Delgado] *Level2 CRM*
>>   Gonzalo Aguilar Delgado
>>   Consultor CRM - Ingeniero en Informática
>>
>> M. +34 607 81 42 76 <+34%20607%2081%2042%2076>
>> T. +34 918 40 95 78 <+34%20918%2040%2095%2078>
>> E. gagui...@level2crm.com
>>
>>
>>
>>
>>

-- 
Gonzalo Aguilar Delgado *Level2 CRM*
  Gonzalo Aguilar Delgado
  Consultor CRM - Ingeniero en Informática

M. +34 607 81 42 76
T. +34 918 40 95 78
E. 

Re: Websockets for graph data streaming

[Martin Grigorov]

Hi,

On Tue, Mar 7, 2017 at 10:07 AM, Gonzalo Aguilar Delgado <
gagui...@level2crm.com> wrote:

> Hi Martin,
>
> I must say I was working with websockets yesterday. And it's delightful
> experience. Have to check how it does scale but it seams just great.
>
> I have a doubt. Since I'm doing fully async I'm doing fully async request
> with WebSocketResource. I suppose that there's no way to update the
> interface from there. I mean, if we are sending a message because a model
> changed on server. Can I trigger the repain of a widget? I suppose this
> option is only available if using behavior right?
>
Correct!

>
> I saw the broadcast example you did. But does it worth mix WebSocketResource
> and WebSocketBehavior?
>
> What is best, more scalable?
>
>1. Doing a WebSocketResource with 1 connection that via Javascript
>notifies all components in page.
>2. Use WebSocketResource + 1 WebSocketBehavior per component, and then
>broadcast to all.
>
> Even if you have many WebSocketBehaviors in your components Wicket will
create only one WebSocket connection per page. A web socket message sent by
the browser will be delivered to all behavior instances. You have to decide
whether the message is applicable for a given behavior or should be
discarded.

The drawback of using WebSocketBehavior is that during the processing of a
message the Page instance will be locked, so WS messages are processed
sequencially and any Ajax requests at the same time will wait for the page
to be unlocked.

>
>
>
> As I told what I'm doing is a Javascript hub that receives messages (via
> WebSocketResource) and sends to the widgets async so they can update. But
> I suppose that following this approach it's quite difficult update
> components from Javascript. And so the opposite. If a component updates
> it's internal model on server, there's no way to push to the interface.
>
> Can I have both? The ability to update components (graphs mainly) from
> javascript datasource, but from time to time, update components on wicket
> and send updates to the UI (html)?
>
You can use org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster to
repaint Wicket components initiated at the server side. You will need to
preserve the page id to able to notify a specific page. Or
WebSocketBehavior should keep some extra information, e.g. userId, to
decide whether a given PushMessage is for it or not.

>
> Best regards,
>
>
>
> El 06/03/17 a las 09:08, Martin Grigorov escribió:
>
> Hi,
>
>
> On Mon, Mar 6, 2017 at 3:57 AM, Gonzalo Aguilar Delgado 
>  wrote:
>
>
> Hello,
>
> I'm using the fantastic Decebals dashboard, adding a widget json
> registry and some other improvements. The idea is to provide data
> streaming functionality like the one provided by graphana, kibana and
> friends.
>
> So the server will contain the datasources. And the dashboard will apply
> to one or more datasources on the server.
>
> But I don't know what's the best way to go with wicket.
>
> My first idea is to provide a websocket connection with a DataManager
> for each user dashboard (only 1 at a time active), subscribe to
> datasources, and receive the streaming over the websockets. The
> DataManager then will keep track of what topic each chart wants to
> receive and multiplex the result to each chart via Javascript.
>
> This way there's only 1 connection to the server. But data can be shared
> among widgets. I suppose it's not easy task.
>
> The other way is do ajax with each chart. But I think this would make a
> lot of calls to the server and I suppose it's not scalable.
>
> S. What's the best way to go?!
>
>
> I'd use WebSockets for this!
>
>
>
> Any good chart integration on wicket apart of highcharts? D3js or
> similar...
>
>
> The demo app forhttp://wicketinaction.com/2012/07/wicket-6-native-websockets/ 
> uses Google
> Charts library without any Wicket component integration.
>
>
>
> Preview of the current work is this link:
>
> https://pbs.twimg.com/media/C6M_hG6WYAEeysz.jpg
>
>
>
> --
> [image: Gonzalo Aguilar Delgado] *Level2 CRM*
>   Gonzalo Aguilar Delgado
>   Consultor CRM - Ingeniero en Informática
>
> M. +34 607 81 42 76 <+34%20607%2081%2042%2076>
> T. +34 918 40 95 78 <+34%20918%2040%2095%2078>
> E. gagui...@level2crm.com
>
>
>
>
>

Re: Websockets for graph data streaming

[Gonzalo Aguilar Delgado]

Hi Martin,

I must say I was working with websockets yesterday. And it's delightful
experience. Have to check how it does scale but it seams just great.

I have a doubt. Since I'm doing fully async I'm doing fully async
request with WebSocketResource. I suppose that there's no way to update
the interface from there. I mean, if we are sending a message because a
model changed on server. Can I trigger the repain of a widget? I suppose
this option is only available if using behavior right?


I saw the broadcast example you did. But does it worth mix
WebSocketResource and WebSocketBehavior?

What is best, more scalable?

 1. Doing a WebSocketResource with 1 connection that via Javascript
notifies all components in page.
 2. Use WebSocketResource + 1 WebSocketBehavior per component, and then
broadcast to all.


As I told what I'm doing is a Javascript hub that receives messages (via
WebSocketResource) and sends to the widgets async so they can update.
But I suppose that following this approach it's quite difficult update
components from Javascript. And so the opposite. If a component updates
it's internal model on server, there's no way to push to the interface.

Can I have both? The ability to update components (graphs mainly) from
javascript datasource, but from time to time, update components on
wicket and send updates to the UI (html)?


Best regards,



El 06/03/17 a las 09:08, Martin Grigorov escribió:
> Hi,
>
>
> On Mon, Mar 6, 2017 at 3:57 AM, Gonzalo Aguilar Delgado <
> gagui...@aguilardelgado.com> wrote:
>
>> Hello,
>>
>> I'm using the fantastic Decebals dashboard, adding a widget json
>> registry and some other improvements. The idea is to provide data
>> streaming functionality like the one provided by graphana, kibana and
>> friends.
>>
>> So the server will contain the datasources. And the dashboard will apply
>> to one or more datasources on the server.
>>
>> But I don't know what's the best way to go with wicket.
>>
>> My first idea is to provide a websocket connection with a DataManager
>> for each user dashboard (only 1 at a time active), subscribe to
>> datasources, and receive the streaming over the websockets. The
>> DataManager then will keep track of what topic each chart wants to
>> receive and multiplex the result to each chart via Javascript.
>>
>> This way there's only 1 connection to the server. But data can be shared
>> among widgets. I suppose it's not easy task.
>>
>> The other way is do ajax with each chart. But I think this would make a
>> lot of calls to the server and I suppose it's not scalable.
>>
>> S. What's the best way to go?!
>>
> I'd use WebSockets for this!
>
>
>>
>> Any good chart integration on wicket apart of highcharts? D3js or
>> similar...
>>
> The demo app for
> http://wicketinaction.com/2012/07/wicket-6-native-websockets/ uses Google
> Charts library without any Wicket component integration.
>
>
>>
>> Preview of the current work is this link:
>>
>> https://pbs.twimg.com/media/C6M_hG6WYAEeysz.jpg
>>
>>
>>

-- 
Gonzalo Aguilar Delgado *Level2 CRM*
  Gonzalo Aguilar Delgado
  Consultor CRM - Ingeniero en Informática

M. +34 607 81 42 76
T. +34 918 40 95 78
E. gagui...@level2crm.com 

Re: Websockets for graph data streaming

[Martin Grigorov]

Hi,


On Mon, Mar 6, 2017 at 3:57 AM, Gonzalo Aguilar Delgado <
gagui...@aguilardelgado.com> wrote:

> Hello,
>
> I'm using the fantastic Decebals dashboard, adding a widget json
> registry and some other improvements. The idea is to provide data
> streaming functionality like the one provided by graphana, kibana and
> friends.
>
> So the server will contain the datasources. And the dashboard will apply
> to one or more datasources on the server.
>
> But I don't know what's the best way to go with wicket.
>
> My first idea is to provide a websocket connection with a DataManager
> for each user dashboard (only 1 at a time active), subscribe to
> datasources, and receive the streaming over the websockets. The
> DataManager then will keep track of what topic each chart wants to
> receive and multiplex the result to each chart via Javascript.
>
> This way there's only 1 connection to the server. But data can be shared
> among widgets. I suppose it's not easy task.
>
> The other way is do ajax with each chart. But I think this would make a
> lot of calls to the server and I suppose it's not scalable.
>
> S. What's the best way to go?!
>

I'd use WebSockets for this!


>
>
> Any good chart integration on wicket apart of highcharts? D3js or
> similar...
>

The demo app for
http://wicketinaction.com/2012/07/wicket-6-native-websockets/ uses Google
Charts library without any Wicket component integration.


>
>
> Preview of the current work is this link:
>
> https://pbs.twimg.com/media/C6M_hG6WYAEeysz.jpg
>
>
>

Websockets for graph data streaming

[Gonzalo Aguilar Delgado]

Hello,

I'm using the fantastic Decebals dashboard, adding a widget json
registry and some other improvements. The idea is to provide data
streaming functionality like the one provided by graphana, kibana and
friends.

So the server will contain the datasources. And the dashboard will apply
to one or more datasources on the server. 

But I don't know what's the best way to go with wicket.

My first idea is to provide a websocket connection with a DataManager
for each user dashboard (only 1 at a time active), subscribe to
datasources, and receive the streaming over the websockets. The
DataManager then will keep track of what topic each chart wants to
receive and multiplex the result to each chart via Javascript.

This way there's only 1 connection to the server. But data can be shared
among widgets. I suppose it's not easy task.

The other way is do ajax with each chart. But I think this would make a
lot of calls to the server and I suppose it's not scalable.

S. What's the best way to go?!


Any good chart integration on wicket apart of highcharts? D3js or similar...


Preview of the current work is this link:

https://pbs.twimg.com/media/C6M_hG6WYAEeysz.jpg