SOA for client-side apps as the way of interoperation

It's idea to discuss and, maybe, implementation.

When building web-apps, we write code for the server side and for the client side. On the server side we can use any language we want - just give API (REST as standard nowadays) and be happy - any app, written in any language (with access to network), can communicate with your programm.


On the client side.. You know, only JavaScript.
TypeScript and even Dart, at the moment I write this, should be transpiled into JS to run in all major browsers. On the web page we can use different JS libraries, jQuery plugins and each one will do it's task and they will not do something in cooperation - in the best case functionality of one library (often jQuery) will be used as a tool in other JS libraries. It doesn't mean they can't coexist - they can and do, but often by the price of tight coupling and only in the scope of one language, so even if you transpile Dart to JS, you can't use all the power of Dart just because of compatibility. And it's the reason why there is not so many new languages for the client side.

Idea

I think we could use SOA inside web page, when web app is the set of services, communicating by APIs. So we need transport, like HTTP, and as this transport we can use DOM (what most JS libs use now) or Local Storage (SessionStorage). DOM (and especially Shadow DOM) looks more attractive, because here we can use object.observe and some other interesting things, but DOM requires browser's attention and I'm not sure if this approach is safe in terms of occasional re-renderings, leaked nodes and collisions/pollution with user-defined elements.
In Session Storage we can have more freedom and it's just less dangerous. If we can do dirty-checking with speed of 300 000 checks/ms in JS, then maybe we can something similar with SessionStorage (or DOM at least), and then we can build event dispatchers on top of that and use it as transport for APIs interoperation. It will not be possible to send pointers of functions (as we used to in JS), but it's how a lot of amazing apps work on the servers and on desktops.

If it's implemented already somewhere - please let me know.

Importance of idempotence - what if POST request will be cached

Couple of weeks ago tester of mobile app I'm building sent us bug report, and described bug was awful - data loss because of wrong synchronization process. Synchronization is always tricky thing to do, but I was sure all works fine because all code, especially of synchronization, is heavily covered by tests (unit and e2e). And all of them were "green".

I've tried to reproduce, as described in report - not reproducible... It's even worse than reproducible.
But what was more interesting - teammates in the USA were able to reproduce it with 100% chance. Really, we demonstrated each other how app behaves and they could reproduce it, I saw it, when I couldn't, even in most difficult cases (for synchronization algorithm)..

As I discovered by symptoms, server has been sending same responses for separate POST requests, when server should generate unique identificator. We checked code of the API - all fine. And for me API doesn't send same responses, so... Yes, responses (or requests) were cached! And cached not by server (nobody will configure server to cache POST requests, I suppose), but somewhere inside the US network between users and server - that's why it wasn't reproducible from my side - I'm testing it from Russia (where I live).

Same "unique" id for different records it's a very dangerous thing and leads to very bad bugs and data losses, so we decided to add random hash to all requests and it solved our issue.

It wasn't difficult to fix, but it was very difficult to find, because I couldn't imagine that POST request can be cached (responses have been sent without touching server, just responses for previous requests with the same signature).

What to think about it? Should we (all programmers) add cache-preventing garbage to each POST/DELETE request? Of course, network providers shouldn't cache POST requests, but we can't force them and can't wait while they'll fix it.

I'm still not sure, so please share your opinions.