Comments on: Our Ajax Conventions–Clientside Continuations

By: Anonymous

Anonymous — Tue, 21 Feb 2012 06:22:00 +0000

Yes, precisely. We actually plugin to $.ajax as a global convention. Basically if you call: $.ajax and do not specify a success callback, then this fires:
https://github.com/DarthFubuMVC/jquery-continuations/blob/master/jquery.continuations.js#L150

If you want to participate in that pipeline, you can call $.continuations.applyPolicy. (I cover this in my latest post http://lostechies.com/josharnold/2012/02/18/jquery-continuations-in-action/)

You can also specify a continuationSuccess callback to $.ajax that lets you hook in before the pipeline. Or just provide a success callback and override altogether.

By: Ryan

Ryan — Tue, 21 Feb 2012 05:24:00 +0000

Excellent. I just realized I could mix event streaming and still use a traditional $.ajax() success callback to have it basically skip this whole pipeline when events are not needed. I was thinking you routed all responses through Amplify.

By: Anonymous

Anonymous — Tue, 21 Feb 2012 04:35:00 +0000

Let’s split those two up for clarity: the server simply tracks the correlation id so you have more control of your requests. Honestly, this is most beneficial in one place: automated testing. We keep track of pending requests so that we have a fairly reliable condition to test against while we “wait” for async stuff to process.

The topic/payload piece is just part of the pipeline and are completely optional. We’ve found that the continuations represent more of a snapshot of the system state and then we layer on metadata. That’s vague so let me expand on that with an example:

Our system is time-sensitive and we capture “timestamps” for entities in the system (e.g., “The patient was here at 12:00″). Our first pass at the endpoint for this sent back a continuation with the topic/payload of: “timestamp-updated”/{ relevant entity info }. That was then relayed through our clientside event aggregator. When websockets were introduced, the clientside didn’t have to change because it was already listening for that topic. My point being: the topic/payload thing works great for event-based systems (i.e., event sourcing).
I understand your hesitation about the mixing of UI/non-UI concerns but consider it from more of an API approach where you provide entity-related information. An example being: Create a User. The response could return the id of the User and some urls (github does this in their api when requesting resources that are paginated).

By: Ryan

Ryan — Tue, 21 Feb 2012 04:09:00 +0000

This is very cool! One question though. Whenever you request data from the server do you have to send a “topic” with the payload, or do you use the correlationId somehow? It seems that requiring a topic server-side could lead to some mixing of UI and non-UI concerns. As far as I could tell, correlationId is only available on the “AjaxCompleted” event. I suppose if you are streaming multiple results with web sockets the topic concept makes more sense.