Don't build an app, build an API, then build an app.
This is what we did with our product, a CMS (http://www.gethifi.com). 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.
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.
On top of all of that, there is an awesome API available for every site on the system!
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 don’t think it’s a good idea to build an API and then build an app; when you first work on an API and an app, I think it’s important to build the API with the app.
Earlier this year I wrote a blog post that mentioned this[1], but in short: great apps have great user experiences, so working on the app’s user experience should be one of the first things you do. If you’re able to figure out exactly what you’ll need in an API to build the best user experience, then building the API might work for you; however, if you’re still trying to nail down down how your app is going to work, solidifying an API before building your app will probably result in an inefficient API or an API that needs to change.
We do the exact same thing at Flickr. Anytime the front-end needs an method to do something, we'll build it in (though it may not always make its way into our public API).
The nice thing is if we change the behavior of an API method inadvertently, we catch it instantly since the site itself reveals the bugs.
We have the same experience (at a much smaller scale!). We can pull down production sites into a VM to see what happens whenever we make an API improvement. It is a great way to catch subtler things too like performance changes.
Its also an excellent way to think about your app.
What are the core things your app should be doing from a data perspective? Expose those things in an API.
Making the API available over REST or as a Web service is extremely simple, and its amazing how useful it becomes over time in your own development.
It also makes you think twice about changing how these core methods change, which is often a good thing (especially when you are working in a small team and its tempting to make "little" changes to solve your current problem without thinking about its implications).
This is also how I've been building web apps lately. I build the API, then build the app on top of the API. Eating my own dogfood ensures that it's tasty enough for my palate.
I wish the startupentrepreneurhackerpainter-scene used more precise terms. This kind of titling makes it all seem so damned naïve.
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.
An app, application, is a software program.
Here the advice is of a unified (public + private) web-based presumably RESTish API into a web application right from the start.
Contrary to the author's experience (or nomenclature), it seems to me that engineers typically do ensure their application has an API.
I can second your question. When you build an app with a dynamic frontent (i.e. javascript) and a "database" (I don't care what model) driven backend, then you need a way to pass data and commands (e.g. JSON) between the two.
Thus you end up with pages that handle requests and return data in a structured presentation-agnostic fashion. Isn't that already 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.
Isn't this largely "Program to an interface, not an implementation" wrapped up in webspeak?
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.
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.
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!
The best way to create an API that feels like their creators never used them is to build one that you would use yourself. If you want to build one that others can use and use easily then you need to put yourself in their shoes, not your own. Otherwise it's just one more library built on some one else's idea of a good time. That said if absolutely no one else is ever going to see, let alone use this API, then certainly build what works for you... just remember the maxim of writing as though the person/maintainer after you is a psychopath who knows where you live.
I'm a little more cautious about this and would suggest three caveats:
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;
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
3. What value does an API provide you as the service provider?
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.
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).
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.
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.
This is what we did with our product, a CMS (http://www.gethifi.com). 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.
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.
On top of all of that, there is an awesome API available for every site on the system!
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.