Aura emitted message id

[mprinc]

I am wondering what is the best way of syncing messaging between aura modules (widgets); consumer modules and producer module; the exactly scenario where we are in with our aura project.

Let say that consumer module A sends message requesting from a producer module B a particular product. While the producer module B is still producing (i.e. REST request to the server), the consumer module A or some other consumer module C asks for a new product. When finally requested products are ready, producer module B can send them "back".

If I am correct, producer can send "back" two messages of a type which both consumers will listen on and they have to filter out whom belongs which product contained in messages.

Well, consumer can together with message request send an ID that will be sent "back" by producer and help to map request messages with response messages. However that requires unnecessary agreeing on a consumer-producer protocol between modules. Correct me if I am wrong.

The most healthy solution in my opinion is to extend aura's sandbox.emit method to return a unique message id to the message sender and propagate the same id to the all "sandbox.on" listener functions in all modules.

Is there a better solution with existing aura infrastructure?

Thanks,
Sasha

[sbellity]

Hi @MPRIC, thanks for your question. The issue that I see in your description is that it introduces tight coupling between your Aura widgets.

If I understand correctly, the way I would have done it is : expose via a custom extension a wrapper to your API to be able to make Ajax requests directly from your widgets.

I'm replying from my phone right now... Let me get back to you with examples when I have access to my computer ;)

In the meantime, can you provide a simple code example of your problem ?

[PaulLeCam]

I think it is the kind of use case where events are too limited, and the command pattern fits better.
I suppose you could define an extension that would handle setting and executing commands through the sandbox, so that other extensions could set specific commands, and widgets could call them if they exist or silently fail if they don't, avoiding to break everything.

[rspindel]

If you are interested in a good command bus for Backbone, look into
Geppetto https://github.com/ModelN/backbone.geppetto

On Tue, Jun 4, 2013 at 6:51 AM, Paul Le Cam [email protected]:

I think it is the kind of use case where events are too limited, and the command
patternhttp://addyosmani.com/resources/essentialjsdesignpatterns/book/#commandpatternjavascriptfits better.
I suppose you could define an extension that would handle setting and
executing commands through the sandbox, so that other extensions could set
specific commands, and widgets could call them if they exist or silently
fail if they don't, avoiding to break everything.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/256#issuecomment-18901779
.

R'phael Spindel
704-SPI-NDEL (774-6335)
347-410-WEBS (9327)
http://www.linkedin.com/in/rspindel
http://www.twitter.com/webspin http://www.twitter.com/#!/webspin
SMS: text "webspin" to 50500

[mprinc]

Hi guys, I have a good excuse for not responding, it was my birthday yesterday :)

Yes @sbellity it introduces tight coupling between our Aura modules (i prefer it more over widgets, because of the nature of our abstraction on the top of Aura) but the worse is that we also make aura architecture non-interoperable by introducing a non-standardized (in aura scope) solution.

Custom extension for merely API wrapping is not what we want, since that was just a current instance of our needs among many and generic consumer-producer pattern fits our purposes much better (see the Figure 1).

@PaulLeCam, we are aware of command pattern but it shifts focus from a data flow to an execution flow and we want to keep out as much non-aura core solutions as we can.

Thanks @rspindel I will keep it in my bookmark :)

---

To elaborate a bit more, as a graduate student at Oslo University I am the main architect of a novel layered architecture over a mashup heterogeneous SOA infrastructure which we try to unify (homogenize :) ) from the users' business/social-processes perspective. It is one of the highest important interests of our research team. After an initial period of our requirements description and our own short development phase, we became aware of aura. It seemed as a very well matching framework/architecture for our needs and we decided to use the aura as a middle layer of our architecture.

Our layered architecture among other features should promote dataflow programming languages paradigm (http://en.wikipedia.org/wiki/Dataflow_programming) (see the Figure 2) where the aura should serve as an abstract-architecture-bus of our programming-in-the-large language (http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small).

Therefore, introducing any extension like (API wrapper, consumer-producer/command/... patterns) would feel more like reducing an importance of (standardized) aura and its core inter-module/inter-widget messaging/event (sandbox.emit/sandbox.on) component that if I am right was intentionally developed to signal, but also to exchange data between modules (because it support sending data and there is no better core aura support).

I hope we can either extend it (by adding a simple unique message emit ID) or introduce an additional native mechanism for data exchange between modules and keep aura solution standardized and in center of functionality, as it deserves :)

Thanks again for your help,
Sasha

---

"University in Oslo, Department of Informatics" diagrams:

(Figure 1)

(Figure 2)

[sbellity]

@mprinc thanks for sharing. The current mediator implementation in Aura is very simple and is based on EventEmitter2 but I've been thinking a lot about having a richer API for our messaging subsystem... I played a little bit with postal.js which is a extensible messaging library to support more powerful messaging patterns.

Would you be able to share some code examples ? I would love to try to come up with a good API that supports your use case...

[addyosmani]

@sbellity when you have a chance, could you talk a little more about what you liked in postal.js that could provide us with a richer API for messaging? I'm weighing the pros and cons of using it vs implementing something more custom ourselves.

+1 to sharing more code @mprinc. That would be really nice to walk through.