Saturday, February 27, 2010

Atomic API?

Seems like an oxymoron. Atomic and API. API's aren't built to be atomic. They are built to be light weight. And because of that they must be always on. This sucks when you are building a client where offline access is a feature.

Here's the example. I'm riding in a train using my smart phone. I create a todo item right as I go under the tunnel. The request went out but never came back. The todo item is sitting on my screen and it is in a transient state technically. I have no idea if my request reached the server or if the response never made it back to me. It's been created locally but hasn't been persisted on the server. How do we know the request was actually received by the server?

We need an uuid to go up with our request. When we receive our model on the next synchronize from the server, we can examine our transient states and determine if the server is out of sync or if the client never received confirmation of the server persistence by examining our uuid.

There are scenarios where this isn't always correct. Say we someone changes our model after our request went up. Then we will receive a different UUID back from the model we created but never confirmed. It's a tricky tight rope this atomicity in distributed systems.

One can dream.