[alamortsubite]

> When I've built decoupled applications, I frequently end up doing 4+ HTTP requests to load various pieces of data that don't make sense to include in the same API request. In some cases these API requests will depend on data from a previous API request, which leads to multiple sequential round-trips before the page is fully usable.

I'm not disagreeing with your fully-coupled approach, but you can also create a new handler to process what would otherwise be separate requests. Server-side, this new handler routes the bundled requests to existing handlers as needed and returns a single response to the client. So one trip and no duplication of logic.

[hakunin]

This is not necessarily a good solution to duplication problem, because you're still forced to keep each endpoint isolated, and can't efficiently combine data acquisition from, say, a database. A much cleaner logic reuse is to do it in your programming language. Build an endpoint that returns exactly what's needed for this front-end view, and build another, generic API for others to consume, but reusing a lot of the logic under the hood on the backend.

[rokkitmensch]

Et voilà, you now have: - a public API - a purpose built API (possibly one each for iOS, Android, and your browser app!) - 1-3 UI implementations closely coupled to your per-view API

:golf-clap:

[hakunin]

I'm honestly unclear, are you trying to say it's a bad thing? Where is the issue?

[thomaslord]

If you're building one API endpoint per frontend view to avoid doing multiple API requests, your frontend and backend aren't decoupled anymore. I personally wouldn't say it's a bad thing, but if the best way to solve the issues of a decoupled frontend is to couple it to the backend again then I don't think that counts as an argument in favor of decoupled frontends.

[hakunin]

I'm arguing in favor of coupling. Don't think front-ends should be decoupled in most situations.

There's this notion I don't see discussed often. The more distant/unstable the link is between a caller and a callee, the more coupled they should be. The closer and more reliable the link is, the less coupled they should be.

That's why when we build interfaces in a single codebase, we can let them be minimal, and let callers use loops for batch operations. But when talking over network, we build elaborate protocols and languages (e.g. SQL) to allow for more complex operations in one roundtrip.

So if one is trying to treat their backend like it's part of their front-end's codebase, that can be fetched and looped over with little regard for the many failure modes, they're going to have a bad time. The front-end to back-end is one of the most distant and unstable links we have in computing, if not _the_ most unstable. This also applies to any intermediary back-end over network.

Minimize network interactions, and shift most work into the single backend codebase for maximum reuse and reliability.

[rokkitmensch]

Merely that it's an extremely expensive way to get to a tight coupling between UI and API.

[hakunin]

Where does the "expense" come from? You either put glue code on top of existing APIs, having almost no optimization advantages, but still having to combine data (the comment I'm responding to). Or you create new endpoints, with more code reuse in them, and more optimization. How is the latter more expensive than the former?

And if you just talk about having 1 api for 3 front-ends, aren't you then forcing your front-ends to contain a ton of business logic to figure out how and what to display based on your API? You could've just given them what they need, but instead they're forced to weave together some insane tapestry from all kinds of "generic" endpoints you gave them? Isn't it expensive to maintain those front-ends?

[alamortsubite]

> but still having to combine data (the comment I'm responding to).

The GP frames the problem as merely avoiding round trips. You introduced the idea of eliminating redundant database calls on the back end. In that scenario, you absolutely have the right idea.