API First

Why

No matter what drives the development of your product (client needs, vision, industry insights) some things need to exist:

• UI(s)
• Landing page(s)
• Backend
• Integrations with 3rd parties.

Out of those the one that is most under your control and should be the most stable is the API.

With an API first approach you are more confident that you have a strong base that you can build upon. API first doesn't mean that all the rest is not a first class citizen, it means that you should think about your API as a standalone concern and a fundamental technology that you are developing.

How

Backend for Front

UI(s) are fast changing. User feedback, trends, experiments, they all contribute to a high volatity. If the BE is not shielded by this then this high volatility will bleed into the BE also. This is turn will lead to more time spent in dev for every new feature.

Taking an API first approach will shield the API from this. This will also push more work into the FE, but usually the overall work is less than doing it in both FE and BE.

Backend for Product

Another approach is to allow the driving force of your product to directly drive the development of the BE. This means that any insigts that you have are distilled and go directly to the BE, no need to build the FE and then indirectly build the BE.

API(s)

API is the contract between the BE and the consumers. Having a good contract is paramount for maintainability and future development.

You should take into account the needs and develop the API around that. No middle man in the process. Go directly to the API that you need to fulfill the needs.

Then the BE will have to accomodate this. This is an implementation detail. It may use inhouse tool or integrate with 3rd party tools. It is of no importance as long as the API (the contract) remains the same.

The client will also have to accomodate this. If some piece of information is not readily available from one single source then it will need to pice it together. Or you may write another API that takes care of this.

Docs

For all this to work you need documentation for your API. Both the BE and the clients need a place to get this from, so they know what to expect. There is a plethora of tools for generating docs depending on the type of API you are writing. Use it.

Benefits

Easier to Pivot

There is a high chance that your product will need to pivot. With a strong and good designed API this should be easier. You'll probably need to build other API(s) and integrate with other providers, but most of your API should be reusable.

Less feature creep

Feature creep is a real problem. Most of the features are gonna be driven by the UI and without this isolation the features will creep to the deepest ends of your system. But if the API is designed first and the BE will conform to this, then the feature creep stops at the API stage.

Less brittle

Making the API a first class citizen will make you think more about how it should behave and will limit the number of changes made to it. When a system has it's own life and exists for its own sake and not for the sake of another part then it becomes less brittle, maybe even robust.