grails-events, events-push, spring-websocket and everything pushy or eventy

[Aaron]

Awhile back we started using the events-push plugin with the platform-core events, everything was good and happy and the world made sense.

However, with Grails 2.3 we had to move to the reactor version of events-push, which didn't seem to work right for many of the cases. I know Stephane has been trying to carve out time to work on the plugin and I can appreciate having other priorities.

Now zyro has put out a first RC of the websocket plugin and that raises other issues about how to integrate front-end and back-end events. It seems like, going forward, using the spring-websocket support and bridging the reactor events is probably the right approach.

I really wanted to just start a discussion (in the right place) on the future of this synergy. I wasn't sure if zyro was considering any work towards the events-push direction and I'm not sure where smaldini is on the other side of that. All I know is that using events on the backend that can make it to the browser was super nice and I want to continue to see that integration get better and better.

Thoughts?

-Aaron

[Graeme Rocher]

As far as I understand, Stephane deprecated events-push in favour of http://grails.org/plugin/events

[Aaron]

I think they solve two different problems. The events plugin integrates reactor based events on the server side. Events-push was a bridge to propagate those events to the browser via atmosphere. AFAIK, the events plugin doesn't have any client side support.

-Aaron

[zyro]

hi,

first of all i think it is important that this topic is brought to
attention again and that we get a "common" understanding of what we are
dealing with, especially in the context of a grails-app.

i had some correspondence with smaldini regarding the
platform-core/events-push/grails-events/spring-websocket evolution and
the current state is (as i am currently aware of, please correct me if
something seems not correct):

- grails-events replaces the event part of platform-core
- events-push (newer versions) use grails-events now and leverage the
atmosphere framework for push messages
- spring-websocket is currently independend of the plugins above

when talking about websocket messaging i do not mean websockets
exclusively but more in general bidirectional and/or push communication
with (browser-) clients. frameworks like atmosphere and sock.js (which
is used by spring websocket) provide fallback options to
streaming/long-polling/etc. for servers/clients not yet fully capable of
websockets.

to avoid confusion regarding the technologies that are in use, i think
it is important to distinguish between
- event-processing (in terms of reactive programming) and
- websocket-messaging

now, given there is a multitude of technologies available for each of
those, my personal, opinionated selection (for use in a grails-app) is this:
- reactor for event-processing (possibly with the grails-events plugin)
- spring websocket messaging (possibly with the spring-websocket plugin)

because of a grails-apps underlying spring-stack that is there anyway,
reactor and spring websocket just fit _extremely_ good in my opinion and
both are very actively developed.

going back to the question of grails-events <--> spring-websocket
integration.

for me, the main question is if this layer of integration is necessary
(or provides enough benefits).

e.g.
- sending a push message from anywhere in the app is just a simple call
to brokerMessagingTemplate.convertAndSend(...) (instead of events-push
former browser: true flag)
- receiving a websocket-message is now working a bit different
(annotated controller method vs. former events-push annotated service
method). but imho, this is a very good thing because its a clear
separation of concerns. client messages, just like requests, hit the
controller layer, and not directly a service method. from there, sending
a reactor/grails-events event is just another call to reactor.notify()
respectively event()

also, there might be apps where people decide to use the following
combinations (neither would ):
- plain reactor without plugin / spring-websocket plugin
- grails-events plugin / spring-core websocket messaging without plugin

bottomline, this means even without special integration here, it is
perfectly possible (even simple i would say),
- to send push-messages to clients from anywhere (including event handlers)
- to trigger reactor events from anywhere (including received websocket
messages)

however, im very open to suggestions on
- what features a potential grails-events <--> spring-websocket
could/should contain
- what you liked about how grails-events <--> events-push worked and
what of that should be adapted

last but not least, smaldini: would be awesome if you chime in providing
your point of view :)


zyro

> --
> You received this message because you are subscribed to the Google
> Groups "Grails Dev Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to grails-dev-disc...@googlegroups.com
> <mailto:grails-dev-disc...@googlegroups.com>.
> To post to this group, send email to grails-de...@googlegroups.com
> <mailto:grails-de...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grails-dev-discuss/1574cf74-6dc5-4f7a-ba50-518600d33ba4%40googlegroups.com
> <https://groups.google.com/d/msgid/grails-dev-discuss/1574cf74-6dc5-4f7a-ba50-518600d33ba4%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[zyro]

thinking a bit more about this, maybe a first step (and if its just as a
basis for further discussion) would be a (not too simple) demo app
(grails-2.4/grails-events/spring-websocket)...

so new users as well as those migrating from a platform-core background
could use that sample to get an idea of how the pieces can work together...

what you say?

[Graeme Rocher]

A sample app would be great yeah

> email to grails-dev-disc...@googlegroups.com.
> To post to this group, send email to grails-de...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/grails-dev-discuss/536E1912.9070108%40zyro.net.

>
> For more options, visit https://groups.google.com/d/optout.

--
Graeme Rocher
Grails Project Lead
SpringSource

[Iván López]

I agree with Graeme, with a sample app all the different concepts will stay clear.

Regards, Iván.

--
El Blog de Iván López - http://lopezivan.blogspot.com
Twitter - http://www.twitter.com/ilopmar

To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/CAO_wNodt3_44%3DCroAV5K%3DsGbeKnvzjp1r-c5RYUMyma9BdkV2Q%40mail.gmail.com.

[Aaron]

One of the first basic usages that we found was a progress bar for long running background processes. We have a ProcessService that wraps execution of background processes (using executor) and fires progress events. A simple grails tag on the front end is used to subscribe to the progress events and update the status.

That seems like a simple, common use case that might make for a good example.

-Aaron

[Graeme Rocher]

Indeed seems like a good example, the tag as well sounds like
something useful to be part of one of the plugins :)

Cheers

[zyro]

hi,

a very basic first example dispatching reactor events every 5s which
then a listener forwards as websocket messages to clients:

https://github.com/zyro23/grails-spring-websocket-sample-events

besides further functionality, or even sth nice-to-look-at ;) - the main
issue is that i am using plain reactor without grails-events currently
in that sample. reason being that it seems like there is no working
release available currently.

waiting for smaldini feedback here:
https://github.com/reactor/grails-events/issues/3

feedback and also discussion very welcome.

zyro

-------- Original Message --------
Subject: Re: grails-events, events-push, spring-websocket and everything
pushy or eventy

[Aaron]

Weird, I don't recall having any issues with the grails-event 1.0.0.M1 in either 2.3 or 2.4. We are using it successfully in 2.3.8 at the moment with a (mostly working) test run in 2.4.0.RC1.

In your example, could you have just annotated the broker method with @Selector?

    @Selector("appEvents")

    @MessageMapping("/hello")

    @SendTo("/topic/hello")

    protected String hello() {

        return "hello from controller!"

    }

Wouldn't that just effectively bridge the reactor event to the /hello topic without having to inject the broker explicitly?

I might fork and add some client side stuff to the example to play around with it.

-Aaron

[zyro]

hi,

grails-events: strange... do you use grails forked mode?

@Selector: never thought about making a exposed controller method a
listener... just give it a try. however i guess this would mean if that
method had arguments, those would have to be provided when called via a
websocket message as well as when called via a reactor event...
also, groovy default values for arguments may be a gray area, if not
totally unsupported...

one thing to keep in mind is that currently @MessageMapping, @SendTo,
etc. are only working on controller methods. but again, i think this is
a healthy separation of concerns between the application layers.
additionally (at least from a quick peek into spring src), it looks like
if @SendTo, @SendToUser, etc. only work in combination with
@MessageMapping, @SubscribeMapping, etc.

and ofc - fork it, turn it upside down or do whatever allows you to
build an opinion.

zyro

-------- Original Message --------
Subject: Re: grails-events, events-push, spring-websocket and everything
pushy or eventy

From: Aaron <lon...@gmail.com>
To: grails-de...@googlegroups.com

> --
> You received this message because you are subscribed to the Google
> Groups "Grails Dev Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to grails-dev-disc...@googlegroups.com
> <mailto:grails-dev-disc...@googlegroups.com>.
> To post to this group, send email to grails-de...@googlegroups.com
> <mailto:grails-de...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/grails-dev-discuss/2bf85031-19dc-48fa-859a-36e8a7b7aff5%40googlegroups.com
> <https://groups.google.com/d/msgid/grails-dev-discuss/2bf85031-19dc-48fa-859a-36e8a7b7aff5%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Aaron]

zyro,

I finally got around to using the websocket plugin in our production application and it seems to be working exactly like I want.

I essentially just followed your example to create a ReactorWebSocketBridge which uses @Selector('/**') to subscribe to all events and then checks against a whitelist to decide what to propagate to the browser via the broker. I take the original Event.key, prepend '/topic' and voila.

Converting my original grailsEvents.js code to use the new stomp.js stuff was pretty simple as well.

Thanks for all the work on the plugin. Now if we could just get a release version of grails-events, I'll be happy.

-Aaron

[Sam Teasdale]

I'll second Aaron on this one: the Grails Websocket Plugin is the way to go for Websocket messaging.  It worked exactly as advertised right out of the box.  Creating an annotated service to broker messages was straightforward and intuitive as was the stomp.js code on the GSP side.  After spending many fruitless hours trying to get messaging working with the Atmosphere plugin, the Grails Websocket Plugin was an absolute godsend.  For Grails developers, it's easily as important a creation as fire, penicillin and DVR.

I've got a basic chat/WebRTC sample app on Github that makes use of the plugin if anyone is interested.  Zyro was even kind enough to contribute a pull request to cleanup some of the messaging code.  Zyro, you're a classy individual.

[Ken Siprell]

Sam,

 

Were you experimenting with the atmosphere or atmosphere-meteor plugin? If you tried the atmosphere-meteor plugin, please summarize your problems in an issue (https://github.com/kensiprell/grails-atmosphere-meteor/issues), and I will fix them.

 

I agree that spring-websocket is the future of Grails messaging, but I plan on maintaining the atmosphere-meteor plugin. Although it requires more configuration and work than simply using annotations, it should not be frustrating.

 

Ken