Your Web App Backend is NOT an API. Let’s Face it!
By: Ashan Fernando
Tags: Nodejs, Web Development, Backend Development, JavaScript, Backend

Your Web App Backend is NOT an API. Let’s Face it!

Over the past few years, Javascript frontends with API backends have become the most popular design pattern for web applications. But have you ever wondered whether your backend is truly an API or not? Ashan Fernando Follow Jun 27, 2019 · 4 min read

Serving JSON doesn’t mean it’s an API

First of all, it is essential to clarify a few things regarding APIs. A backend serving JSON isn’t necessarily an API. Developing an API require reasonable effort. API governance, versioning support for backward compatibility, lifecycle management, and adhering to standard architectural styles such as REST involves effort. These requirements come on top of delivering business functionality.

Tip: Use Bit (Github) to easily turn small modules into reusable components your team can share, use and sync across projects. Give it a try.

Web backend was never destined to become an API

I have been convincing myself, thinking that these backends are RESTful APIs. Perhaps at the beginning of the API development, a few advanced features like versioning is missing, but these could always come in later.

In fact, for the web app backend, having clean RESTful endpoints and methods hardly becomes a reality. These things accumulate as technical debts over time. Sounds familiar?

This line of thinking is quite misleading, especially for software architects who desings web application backends. This is because, the web backend was never destined to become an API.

Even if you do create a web backend as an API, there are several challenges in common. One of the common problems is that the web app requires to call multiple endpoints to perform an action which hurts performance. If the backend supports versioning, frontend might need to handle the complexity of calling different versions. Besides, if the backend designed as a collection of services (e.g., Microservices) frontend complexity will further go up.

I know these examples are extream cases but seriously think about it.

Why you should come out from this mentality

As we all know, different teams work together to deliver the business functionality of the web app. Although technically you can deploy the frontend and backend separately, often you will need both to be released at the same time. Although it’s possible to divide teams by frontend and backend, I would prefer sharing them by business functionality where each team is responsible on the full stack. Dividing them terms of business functionality, empower them to drive business capabilities over their technical counterparts.

Just imagine if we have put the API mindset at first, these teams need to address problems like versioning, API strategy, interoperability with frontend and backend as top priorities. Do recall the very first priority of a web app is to deliver the business value, by releasing features out, fast and efficiently as possible.

Isn’t having an API better for reuse?

The other question we need to address comes with the mentality of reuse. What if we build a single API backend and reuse it for the web app, the mobile app and also expose it for the third-party integrations?

Wrong again. Generally, mobile apps use a subset of features from a web app optimized for frequently used functions or any specialization. Same valid for the third-party integrations.

Here, there are more differences than trying to reuse the same. For instance, a third-party API might require to access all the data from an endpoint. The same API endpoint might require restrictions to the web app. Therefore it’s essential to understand that there could be different authentication and authorization requirements based on the nature of integration (e.g., B2B and B2C).

So the point I want to make here is to build specific endpoints for the cases discussed above, instead of trying to force the mindset of reuse. If you see standard business functionalities, reuse internal code in the form of libraries, instead of reusing the API.

What about mobile apps and third-party integrations?

In contrast to a web app backend, it makes sense to build a mobile backend as an API since you cannot directly update the mobile app version in a user’s phone if there are any breaking API changes. Therefore different mobile app versions will require different API versions for their operations. Same is applicable for third-party integrations. Third parties won’t do the changes immediately at the rate of you change APIs. Here you need more control and governance. Therefore developing a separate API makes sense for mobile apps and third-party integrations.

In summary

As a summary of this article, don’t consider your web app backend as an API. Even if you do, do it consciously knowing its limitations. Divide your teams with the business focus instead of dividing them as frontend and backend. Each team needs to be empowered to deliver business value with a minimal dependency with others.

If the application scope is broad, consider breaking the application to multiple web apps and backends. Still, each team should work both in the frontend and backend of a web app. You could also design microservices for the backend, but make sure you start with a small set of services at first.

And remember the same doesn’t apply for mobile and third-party integrations. Therefore make sure you build APIs for mobile app backends and third-party integration with governance, versioning, and lifecycle management.

Learn More