Channels ▼

Reusable Components Finally Arrive As Cloud-Based APIs

"Reusability" has been a mantra for the sale of as much unsatisfactory software as the claim for "improved productivity." It's a benefit buyers hope you get, while knowing in their heart it's not going to happen. To say that reusability has been a quest for four decades is to somewhat understate how long and tortured the search has been.

More Insights

White Papers

More >>


More >>


More >>

From the time that structured programming leveraged the benefits of subroutines and libraries of routines, there has been a compelling impetus to create reusable code. Initially, this desire was expressed purely in the form of libraries. The concepts now familiar to API designers were little appreciated then, and so libraries were often hideously complex, hard to use, and brittle.

Even if they were implemented with discipline, libraries presented syntactical problems. One of the biggest was name collisions, which was an enormous issue in C and early versions of C++. In the latter language, you sometimes had to check the exact form of name mangling that the cross-compiler (to C) employed so you could figure out how avoid having your function names collide with libraries or, in the other direction, to figure out how to call those library functions.

Even if you could get past the syntactic issues, you were by no means in the clear. Many libraries made it impossible to use more than one library at a time. Use more than one graphics package? No way. Once one library clamped on to the main UI thread, no other one had a shot at access. You might wonder why you'd ever want two graphics libraries in the same app. But such a question shows how far we've come with omnibus solutions like Qt and Glib. In the times I'm talking about, libraries were much smaller in scope and you often had to call on several of them to complete a single, simple task.

Even if you could lay those problems to rest, the obstacle of platforms presented itself. To solve this, there came components and competing component formats (OLE vs. COM vs. DCOM, etc.) While several technologies such as RMI and CORBA emerged to address remote component utilization, they were never popular and always cumbersome. Which brings us to where we've been for the last few years: Well-written components are reusable only on the platforms they were designed for. That state of affairs, however, was not good enough for mobile apps, which are inherently tied to a highly splintered group of platforms (Android, iOS, Windows Phone, BlackBerry QNX, etc.)

Mobile apps and Web apps have driven key changes in reusability by forgoing components in the traditional sense in favor of consuming services that were publicly exposed in the cloud as APIs. Components moved from the troublesome local machines to a remote server, where they could be invoked through Web services without concern for the execution platform. This new composability is the first truly reusable code experience we've had in decades. Suddenly, you can call functions in one API to handle one area of functionality, call others to handle a separate task, and go to a third API to deliver the data you need for another requirement. For new applications, the design issue that is slowly emerging is how to compose software from the available APIs.

On the surface, this might seem like the Web services that were briefly the rage a decade ago. While there is some conceptual affinity, the implementations are substantially different. The old Web services were cumbersome to code (with WSDL and SOAP) and slow to execute. They also tended to interact with private, local servers. While they held a lot of promise, their limitations made them generally unappealing, and so their use tended to be for very coarse-grained requests. Today, the APIs are fast, they use REST, and are fine-grained. A single application might invoke dozens of API calls — and deliver value to the user in near real-time.

The speed of adoption is great and there are now companies such as Apigee, Mashery, and Layer 7 that help other companies design and manage APIs for a wide variety of vendors. How active is this sector? Well, this week alone, Mashery was acquired by Intel and Layer 7 was snapped up by CA (the former Computer Associates).

Less attention has been paid to the developer as consumer of APIs. However, startup company Temboo has created elegant tools that make API consumption almost trivially easy. I expect they'll have competition soon.

While I expect this new model of reusability to flourish, it does have one conspicuous limitation: Most companies do not provide their API services free. The former model of buying a component and then distributing it without royalties will fade away in this new model, as each call now includes costs for the provider. I expect this will have important consequences that are still somewhat difficult to divine. I'll get to those in a future editorial.

— Andrew Binstock
Editor in Chief
Twitter: platypusguy

Related Reading

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



Distributed API's are interesting when you can count on 100% internet connectivity uptime. There are still many applications that must work without this.


Thank you very much. Good points. Ultimately, fine-grained behavior has to be locally executed, so the JS model of caching code from a remote http code repository (web server!) will be very important; these solutions are local frameworks! JS's modularity must and will improve.


Franeworks represent a big problem. While they provide reusability, they're heavy, incompatible with other frameworks, confined to one platform and, frequently, to one kind of app. As dev becomes more mobile-oriented and service-driven from clouds, I expect frameworks will need to change more than probably any other existing class of solutions. The apps that remain on local servers or on desktops will change the slowest, but those moving to the new model, I expect, will forgo frameworks as such and, as you suggest, will use JS and derive their non-UI functionality from the cloud. As pjmpl points out, this is still relatively coarse-grained functionality, but I expect as the model grows and connectivity continues to become ubiquitous, fast, and reliable, it'll become progressively finer grained--and ultimately the established way of doing things.


Not yet, no. But it's definitely heading that way.


Andrew - pjmlp's point is totally correct. And I would point out that even local code reuse is at a massive and increasing scale, if for no other reason than Java, .NET and Linux C frameworks and libraries. Except for Java, these are not massively cross-platform, but neither are many of the consumers of these frameworks. The current and next wave of local code reuse might be via JavaScript, which has namespace issues not too unlike those of C, but at least has had long names and Internet domain names all along, both of which help avoid namespace collisions.


These RPC API calls only make sense for distributed applications, mostly for coarse manipulation of data.

It is in no way a replacement for native software development or use cases where high throughput is valuable.