{"id":2434,"date":"2015-02-19T13:15:07","date_gmt":"2015-02-19T11:15:07","guid":{"rendered":"http:\/\/www.webcodegeeks.com\/?p=2434"},"modified":"2015-02-16T00:23:14","modified_gmt":"2015-02-15T22:23:14","slug":"real-time-communication-angularjs-qorlate","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/javascript\/angular-js\/real-time-communication-angularjs-qorlate\/","title":{"rendered":"Real-time Communication in AngularJS with ($Q)orlate"},"content":{"rendered":"

This post introduces the lightweight ($Q)orlate<\/a> library.<\/p>\n

A popular type of engagement that iVision<\/a> is hired for is the architecture assessment. For assessment projects we analyze the existing system, weigh our own experience, industry standards and best practices against what we find, then provide feedback and a potential road map to iterate towards a desired solution.<\/p>\n

I\u2019ve participated in everything from an over-arching analysis of the entire technology stack with associates from our data center, converged networking, and infrastructure practices to provide a business\/IT roadmap for cloud readiness to a very targeted analysis of AngularJS implementations.<\/p>\n

Recently I worked with a customer that built a very mature proof-of-concept using Angular in a system that had what I call \u201cdisconnected asynchronous processes.\u201d These are processes that are truly \u201cfire and sort of forget\u201d because the message goes through message queues and workflows prior to a response being generated through a different channel. Although my first step is always to challenge this type of architecture (sometimes it\u2019s implemented with the belief it is automatically faster or more scalable when there are other approaches that can achieve the same results with less complexity), in this case it truly seemed like the right architecture needed by that system.<\/p>\n

I am constantly looking for opportunities to simplify and\/or refactor code to reuse common components, algorithms, and strategies. This makes it easier to maintain and understand the code and provides developers with a toolbox to use so they can plug in the repeatable pattern and focus on what is unique about their part of the application. This led to me brainstorming what I\u2019ve seen in these types of systems with Angular and I came up with three very distinct scenarios that I felt could be addressed with a lightweight Angular service.<\/p>\n

1. Cached Requests<\/h2>\n

Angular has its own built-in mechanisms for controlling a cache. It is a common pattern for a service to asynchronously request information that is used by other components. Sometimes your app may get caught in a chicken-egg scenario when a component relies on a central service for information but must wait for that information to appear. For example, it may be necessary to retrieve security information from the server prior to building a menu or servicing requests.<\/p>\n

There are a few ways to deal with this in Angular. One is to create the promise on the route, which will delay loading a view until the promise is satisfied. This isn\u2019t an option if you aren\u2019t using routes and sometimes your services may not be specific to a route. Another mechanism is simply to return a common promise<\/a>. Multiple callbacks can be registered, so if the service keeps track of a single promise it can keep providing it, and even if it was resolved in the past the promise will be satisfied.<\/p>\n

To see what I mean, take a look at this jsfiddle<\/a>. Notice the second call happens long after the list was already populated, but the promise still fires and populates the second list (the list is populated after 1 second, and the second promise is requested after 2 seconds). The same promise is always returned.<\/p>\n

The following figure shows this scenario (you can assume the server simply calls out to the database, the queue and handlers will make more sense for the other scenarios).<\/p>\n

\"cachedrequests_thumb[2]\"<\/a><\/p>\n

To enhance this scenario, ($Q)orlate provides an option to track multiple requests with timeouts. If timeout isn\u2019t a concern or is handled locally, the straightforward use of $q<\/a> will suffice. What ($Q)orlate does is provide a mechanism to automatically timeout and expire the request, so it keeps track of multiple requests even if you satisfy them with a single call.<\/p>\n

The call to ($Q)orlate is passed an id that uniquely identifies the correlation (it will generate one for you if you do not pass one in). In this example<\/a> a timeout is used to emulate the delayed response. Notice the resolution has an extra parameter for the correlation.<\/p>\n

\r\n$timeout(function () { \r\n\t_this.list = [1, 2, 3, 4, 5];\r\n\t_this.qorlate.resolve(_this.id, _this.list);\r\n\t}, qorlate.defaultTimeout + 100\r\n);\r\n<\/pre>\n
The service always returns a correlation. This is because qorlate will immediately return the last promise that was resolved or rejected, so any values (success or error) will be satisfied in the promise.<\/p>\n
return this.qorlate({ id: this.id }).promise;<\/pre>\n
The consumers simply call the service with a standard promise, and it will either be satisfied once the data is loaded or rejected when it times out (in the example<\/a>, the initial call times out but the subsequent call works because the data has been loaded). ($Q)orlate guarantees the promise, so even if a request is rejected from a timeout and the original call returns, later requests will be resolved immediately with the result.<\/p>\n
Although this is one use case, ($Q)orlate is more suited to two other scenarios.<\/p>\n
2. Discrete Disconnected Messages<\/h2>\n
I am purposefully using the label \u201cdisconnected\u201d instead of \u201casynchronous\u201d because a direct AJAX call can be asynchronous while it is still \u201cconnected\u201d in the sense there is a clear path from the call to the resolution of the promise. What is less clear is when the message is sent to be processed, then returns through another channel such as a websocket. The top section of the following figure demonstrates this:<\/p>\n
\"CorrelatedRequests_thumb[1]\"<\/a><\/p>\n
I call this a correlated event because even though the return event is surfaced independently of the request (i.e. via a Web Sockets connection), it is correlated to the initial request. For example, you might have a form that submits to a queuing system, is validated by a handler on the backend, then the response is routed back. In these cases, you still want to keep track of the message (i.e. if it times out it is probably good to inform the user) but the API might not be so clear. Consider something like this that you may be used to:<\/p>\n
\r\nvar id = 1;\r\nfunction sendRequest() {\r\n\tservice.on('response', function (response) {\r\n\t\tif (response.id === id) {\r\n\t\t\t\/\/ do something\r\n\t\t\t\/\/ and don't forget to unregister\r\n\t\t}\r\n\t} service.send(id, request);\r\n}\r\n<\/pre>\n
Basically you must keep track of your correlation and register to listen to all returned events, parse out the one you are interested in, then remember to unregister from the event (or just let it fire assuming the identifier won\u2019t repeat), then finally fire off your message.<\/p>\n
One of the nice things about the promise specification is that it helps make code cleaner and easier to read. What if you could do something like this instead:<\/p>\n
\r\nservice.request(id, request).then(\r\n\tfunction success(response) {\r\n\t\t\/\/ yes!\r\n\t},\r\n\tfunction error(err) {\r\n\t\t\/\/ nope!\r\n\t}\r\n);\r\n<\/pre>\n
This is a straight promise. Is that possible, even when the mechanisms are disconnected? The answer is, \u201cYes.\u201d The service simply needs to establish the promise with a correlation:<\/p>\n
\r\nvar correlation = this.qorlate();\r\nreturn correlation.promise;\r\n<\/pre>\n
When the message comes in, the correlation is notified:<\/p>\n
this.qorlate.resolve(correlation.id, response);<\/pre>\n
You can also reject the correlation, and the configurable timeout will also reject it automatically if the return message is not received within the timeout period. In the above example, the service generated the identifier. If you have GUIDs or other ways of matching messages, you can specify them when you generate the correlation and match it back. See a working example that demonstrates successful, failed, and timed out correlations here<\/a> and view the source here<\/a>.<\/p>\n
If you look back at the second figure you\u2019ll see there is another section near the bottom that indicates alerts raised by the server completely independent of the client. These are \u201cbroadcast\u201d messages. You can certainly use mechanisms built into scope, but if you want a way that doesn\u2019t rely on scope, still participates in digest loops (so no matter the mechanism for notification, you are always guaranteed to notify your subscribers in the context of a digest loop), and is testable, consider the next scenario.<\/p>\n
3. Event Aggregator or Pub\/Sub<\/h3>\n
The idea behind an event aggregator is straightforward. A central service \u201cbrokers\u201d messages. You simply post your message to the service, any component interested subscribes, then the message is broadcast to the subscribers.<\/p>\n
The subscription looks like this:<\/p>\n
\r\nvar cancel = q({subscribe:'addItem'}).always(function (item) { rs.list.push(item); });\r\n<\/pre>\n
In this case, the subscriber is responding any time the message is sent. An error\/rejection method may also be added so if there is a problem with the transport it will notify subscribers. I do realize always<\/em> is used in a different context relative to promises, but it made sense here because that\u2019s what is happening \u2013 the message is always notifying the subscriber.<\/p>\n
The call to ($Q)orlate will return a function to cancel the subscription \u2013 that\u2019s as easy as calling cancel(); and you\u2019re unsubscribed. The API to raise an event is no different:<\/p>\n
q.resolve('addItem', (new Date()).getTime());<\/pre>\n
In fact, as you can see from the test specifications<\/a>, you can overload the same identifier with promises and<\/em> subscriptions. The module is fairly lightweight. It:<\/p>\n