Don't build an app, build an API, then build an app.<p>This is what we did with our product, a CMS (<a href="http://www.gethifi.com" rel="nofollow">http://www.gethifi.com</a>). We built a very flexible API that has cool things like permissions, relationships and versioning built in. Then we built our app and interface on top of that.<p>This turned out to have tons of advantages. Our app development went very quickly. It was much easier to do testing. Improvements to the API are now universally available.<p>On top of all of that, there is an awesome API available for every site on the system!<p>By inverting the way you think about the API, (build on the API, vs. build an API for an app) you end up with an API that is much more polished as well.
I wish the startupentrepreneurhackerpainter-scene used more precise terms. This kind of titling makes it all seem so damned naïve.<p>An API, application programming interface, is an interface presented by some means into some kind of an application, possibly itself. A C library, for example, presents an API. Both external (public) and internal (private) APIs may exist, as well as intermediate forms.<p>An app, application, is a software program.<p>Here the advice is of a unified (public + private) web-based presumably RESTish API into a web application right from the start.<p>Contrary to the author's experience (or nomenclature), it seems to me that engineers typically do ensure their application has an API.
Much of what I read about this talks about, e.g., building a REST API then using that in your application rather than direct database access.<p>Isn't this largely "Program to an interface, not an implementation" wrapped up in webspeak?<p>Whenever we start a new web project, we organize our code into groups of services, and use interfaces to represent those groups rather than concrete classes. Where possible, the implementation of the interfaces are direct database calls. When we need to use it externally, we have an implementation that uses remote calls.<p>So ultimately we program to interfaces which are designed to be automatically exposed as an API call. In some ways the recommendation to rely on your own REST API to build out your application feels like a way to make up for the lack of structure interfaces can enforce. Maybe I'm wrong though.
This is essentially bottom-up programming where you build a small language first (could be just functions, not a "real" new language), then build your app out of your new language. Paul Graham advocates/advocated this.<p>Being able to figure out what primitive pieces are important now and will be important later is something that takes practice and something that I've never ever been able to convince a manager of the importance of and that it's far more important than knowing 25 design patterns or some similar buzzwordy stuff. There are many ways to decompose problems. Bottom-up is the right way, though. Contrast with top-down/stepwise refinement for the wrong way.
This was a very apropos read for me, since I'm working on my next app by starting with the API. I have been working with quite a few API's and I've found that a lot of them felt like their creators never used them. So I'm building an API that I would use myself, and I'm forcing myself to live up to that promise by building the rest of the app on top of the API. I'll let you guys know how that goes!
I'm a little more cautious about this and would suggest three caveats:<p>1. Building an API from day one can be premature. Typically when you start building something is the time when you know the least about the problem you're trying to solve and the issues you'll face solving it. That problem is subject to much more change early than late. If you build an API on day one may just be creating more work for yourself later on;<p>2. If you provide a public API, you are quite possibly exposing your data model and any assumptions that underpin it. This can make it much harder to change later as circumstances change. Think of it as making everything (including data members) public in class. It's abstraction; and<p>3. What value does an API provide <i>you</i> as the service provider?<p>Twitter is an easy example of this: it doesn't really matter where the Tweets (sorry nytimes) come from as Twitter owns the graph, the distribution and the Tweets.<p>Now consider a site like Stackoverflow. What if you could ask questions, search for answers, vote, view your summary information and so on completely via an API. What value would there be in the SO site? Not much at all and it's the ads on those pages that pay for the site (well that and $x million from USV).
The new Twitter.com is using its own API.<p><a href="http://engineering.twitter.com/2010/09/tech-behind-new-twittercom.html" rel="nofollow">http://engineering.twitter.com/2010/09/tech-behind-new-twitt...</a>
This applies to enterprise software as well. I was an architect for a large CRM project with Siebel and software from a company called Yantra (acquired by SterlingCommerce). The difference between the two? Siebel "bolted on" an API layer and Yantra consumed their own API for internal, core functions.<p>The difference was night and day. As expected, the Siebel API was practically useless. Yantra's was rock-solid. No better way to make sure your API is solid than to use it internally.
A big part of engineering is about making the right trade-offs at any given point. His straw-man engineer shows nothing but his misunderstanding of engineering.
Good thoughts. The article did not say this outright, but it is also nice to build a chunk your app (if not all of it) on top of your own API. Not only is this good housekeeping, it helps in decoupling your code and forces you to keep things in bite-sized, maintainable, testable pieces.
I call this WMC (Weapons of Mass Connection)<p>Edit: Don't know why I got downvoted but I guess the above statement needs some context:
<a href="http://000fff.org/the-power-of-digital-ecoystems/" rel="nofollow">http://000fff.org/the-power-of-digital-ecoystems/</a>