API First Development

There are different approaches to digital product development. The web development community seems to be in a constant fight over which approach makes the most sense, while in reality most of them have their place.
It all depends on context.

Before diving into the 'API first' development approach, i want to state the obvious: Building is better than thinking and when you build something of value the tech and architecture behind it don't matter. Take remote.ok for example - a simple job board thats turning in over 50k USD / month and is just one PHP file sitting on a shared Linode instance built without version control, libraries or frameworks. That approach falls apart when working in teams but in Pieter Levels context, it was all he needed to launch multiple successful online businesses.

Now to talk about API first development: What exactly do I mean by it?

Quite simply: You have an HTTP-API that controls all business logic of your application via machine readable JSON data. You completely separate your view layer from that API. This doesn't mean you build your backend as a collection of microservices - on the contrary i do suggest the API to be A Majestic Monolith. But contrary to the mainstream 'monolith' approach, you don't render any views on the backend.

Key advantages

I believe there are a few key advantages to this approach when starting and scaling a digital product:

  • Exist on multiple platforms: You can launch on multiple platforms at once. Or you can add mobile apps later, without having to rewrite any of your backend.
  • Enable snappier user experiences: When building APIs that don't render views, you will build your applications as snappy frontend applications, that have seamless user interactions and dynamically load data from the API as needed.
  • API integration with other tools: You already have API based authentication from the get-go. This makes it a lot easier to integrate with other API based tools or let your users and third party developers access the API directly.

This also directly maps to what users expect from software as a service tools today:

  • Snappy user experience
  • Seamless usage across platforms

One big counter argument i see often is that building this way slows you down compared to traditional monolith approaches. I don't think so. On the contrary, in my experience it makes you more efficient - especially when working in a team. And with todays landscape of open source tools and frameworks it makes the initial extra overhead a matter of a few hours.

Further reading:

Missives dirty little secret of building a performant email client that works across 6 platforms, wins prises all while being a team of 3.