Live data from Hacker News

Distributed Systems and the End of the API

writings.quilt.org

1–10 of 102 posts

Re: Distributed Systems and the End of the API

#4
post #2

I stopped at the point where he claimed that APIs were always synchronous, this wasn't even true in the 80s. For example XLib is a rather well used API and is asynchronous (there are many others).

two paragraphs later he addresses that point, calling that support limited in current api designs

Re: Distributed Systems and the End of the API

#5
post #2

I stopped at the point where he claimed that APIs were always synchronous, this wasn't even true in the 80s. For example XLib is a rather well used API and is asynchronous (there are many others).

two paragraphs later he addresses that point, calling that support limited in current api designs

Re: Distributed Systems and the End of the API

#6
post #2

I stopped at the point where he claimed that APIs were always synchronous, this wasn't even true in the 80s. For example XLib is a rather well used API and is asynchronous (there are many others).

two paragraphs later he addresses that point, calling that support limited in current api designs

Re: Distributed Systems and the End of the API

#7
I also covered a variety of similar issues when discussing that offline rich-web applications are perfect for CRDTs, because you are effectively building a distributed system, in my EmberConf 2014 talk [1][2] called Convergent/Divergent.

[1] http://confreaks.com/videos/3311-emberconf2014-convergent-di...

[2] https://speakerdeck.com/cmeiklejohn/divergent

* edited to reformat list.

Re: Distributed Systems and the End of the API

#8
post #4
post #2

I stopped at the point where he claimed that APIs were always synchronous, this wasn't even true in the 80s. For example XLib is a rather well used API and is asynchronous (there are many others).

two paragraphs later he addresses that point, calling that support limited in current api designs

Not really, he talks about HTTP which wasn't really designed for that purpose. There are plenty of protocols that were. Does this actually have anything to add that isn't covered in http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput... , if so then I'll read further.

Re: Distributed Systems and the End of the API

#9
Of course APIs that serve as synchronous endpoints to distributed systems are a leaky abstraction. But its not the only one of its kind, there's also Guaranteed Message Delivery [1].

I find the philosophy behind Akka in this context a better fit - embrace that networks are unreliable and build your app around this limitation accordingly [2]. The cost is that it results in more work for the developer just like with the usage of CRDTs.

[1] http://www.infoq.com/articles/no-reliable-messaging

[2] http://doc.akka.io/docs/akka/2.1.0/general/message-delivery-...

Re: Distributed Systems and the End of the API

#10

TL;DR: APIs have issues with concurrency and latency, amongst others. Use Consistency As Logical Monotonicity (CALM) or Conflict-free Replicated Data Types (CRDTs) instead. Here is a little about how CRDTs work. btw: speech in NY on the 15th of May.

Thanks for the summary. Via Google, ended up at http://www.slideshare.net/jboner/the-road-to-akka-cluster-an... which I've bookmarked to watch at a future date, since I'm new to these concepts.
Post reply on HN