spine.js: why does it serialize POSTs blindly? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

This came up during a discussion on another spine.js question: Since, this is significantly distinct from that question, I am upholding the "one question per post" policy of SO, by branching this off as a new question.

@numbers1311407 mentioned that

spinejs will queue the requests and submit them serially, each consecutive request being made only after its predecessor completes.

But that seems so wrong ! Why should Spine assume so much control and sequentialize all POSTS (for example) from a client ? What if the POSTS are on related URIs ? Even if Spine tries achieve some sanity by sequentializing all POSTs for each client, it still has no way of preventing concurrent and conflicting POSTS happening from different clients. So, why bother ?

Answer 1

But that seems so wrong !

It makes sense when you consider the design goal of spine, the realization of what MacCaw calls an "Asynchronous UI" (the title of the blog post you linked to in your related question). This paradigm attempts to eliminate all traces of the traditional request/response pattern from the user experience. No more "loading" graphics; instantly responsive user interaction.

This paradigm expects a different approach to development. Persisting to the server becomes more of a background thread that, under normal circumstances, should never fail.

This means that under normal circumstances your app logic should not be dependent on, or care about, the order or scheduling of requests by spine.

If your app is highly dependent on server responses, then spine might be the wrong library.

Why should Spine assume so much control and sequentialize all POSTS (for example) from a client ?

Because of spine's non-blocking design philosophy, your app relinquishes the flow control that you might have in another lib like Backbone, wherein you might do something like disable a "submit" button while a request is being made, or otherwise prevent users from spamming the server with non-idempotent requests.

Spine's Model#save, for example, returns immediately and as far as the client is concerned, has already happened before the server even gets the request. This means that spinejs needs to collect and handle requests in the order that they come to ensure that they are handled properly. Consider a user jamming on a "Save" button for a new record. The first click will send a POST, the second, a PUT. But the button spamming user does not know or care about this. Spine needs to ensure that the POST completes successfully before the PUT is sent, or there will be problems in the client.

Combine the order sensitivity of non-blocking UI input with the first point, that your app shouldn't concern itself overmuch with the persistence layer, and you can begin to see why spinejs serializes requests.

Even if Spine tries achieve some sanity by sequentializing all POSTs for each client, it still has no way of preventing concurrent and conflicting POSTS happening from different clients. So, why bother ?

Because the point of the solution is to give a consistent, somewhat user-error-proof UI experience to a single client. E.g. if a client creates, then updates, then deletes a record, spine should ensure that all these requests make it to the server successfully and in the proper order. Handling conflicting posts between clients is a separate issue, and not the point of the request queue.