Hacker News Reader

Comment by jedberg | Hacker News Reader

Any time I see a "unified API" where multiple interfaces are abstracted to a single interface, my first concern is the lowest common denominator problem.

What I mean by that is your unified API can only support features that all of the APIs it is abstracting also support. Otherwise the users of that API will make calls and not know if they will work because it will depend on the backend.

The classic example of this was when people tried to create unified APIs for AWS, GCE, and Azure. They had to only support features all three had, otherwise the API would break if you used the wrong cloud provider, in which case it was easier to just interface directly with said cloud provider.

Which is a lot of words to say, how will you support multiple APIs with different feature sets without breaking your API?

View on HN

(Nango co-founder here) That's a great point. You highlight a key limitation of traditional unified APIs and one of the reasons why we started Nango.

There's a lot of subjectivity that goes into unifying functionalities across APIs. Traditional unified APIs must make these subjective decisions for all their customers in a one-size-fits-all manner.

Nango lets you customize integrations & schemas, so you can make these subjective decisions for yourself. The result is a unified API that truly fits your business use case.

Still, some radically diverging API functionalities cannot be unified, which requires some additional API-specific logic to handle. This can be abstracted in our integration scripts, supported by our tooling, instead of living in your main code-base.

I have mixed thoughts about this approach.

Unification should mean creating a single interface that seamlessly interacts with multiple underlying services without needing custom adaptations for each case.

The issue with allowing for customization is that it leads to fragmentation. This defeats the purpose of having a unified API in the first place.

I'm not sure whether the convenience of unifying leftover common functionalities like authentication outweighs the complexity and reliance introduced by adding another layer to the tech stack.

These are all fair points!

In practice, most customers we serve have use cases that could not be supported by traditional unified APIs, but are still better off not rebuilding an integration infrastructure from scratch.

We also offer professional services to outsource the customization, so you still have an off-the-shelf unified API, but specific to your company.

Reply on news.ycombinator.com