Measure Once, Cut Twice

Relative Cost of Distributed Architectures

Posted in architecture by steve on April 24, 2010

Applications that have both a desktop and a web version, often for online/offline use cases, force you to make a decision about whether you want to share or duplication the back-end code that isn’t dependent on the UI bits. If you have a nice, separable back-end engine component it is tempting to architect your application as two separate distributed components and treat the local configuration as a special case of that.

For example, when your core application logic is layered behind a REST API, why not just have mini-web server running on the client for the the desktop deployment scenario? The UI layer can manage this process transparently to the user.

The benefit is a single architecture to cover both the web and the desktop deployment scenarios — the trade-off is that you are building some fundamental latencies into your architecture. To put the costs in perspective, I tried to google up some rules of thumb on the typical latency of various types of calls. Here is a rough approximation of the relative costs:

method call — ~100s ns
synchronized method call — ~1000s ns
reflective method call — low ~10,000s ns
machine loopback — ~30,000-150,000 ns
local sub-network — 1-2 ms
internet — 10-100+ ms

Model Your Resources Well and Don’t Worry About the REST

Posted in REST, software development by steve on April 20, 2010

RESTfully modelling transient resources, events, collections, and other application facets can be difficult. The post “Square Peg, REST hole” nails it and has an excellent discussion in the comments section. While I am a fan of REST and have been following the “web architecture friendly web services” debate since before dissertation-REST existed, what has become clear over the past few years is that:

90% of the value of REST is idempotent GETs on well named, hackable resources

And yes, hackable URLs are not a part of REST, but they certainly are an integral part of the success of web architecture friendly web services in the real world. REST wouldn’t be winning over SOAP if it wasn’t for all the successful semi-RESTful APIs that developers found far more intuitive and usable. So if you model your Resources right and people can intuitively GET them, you probably don’t need to sweat the rest of the details.

A corollary to this is that if the majority of your application doesn’t involve getting resources that are at least in the granularity ballpark of a document, then REST may not be that important to you.