I think there are pros and cons to this. I can definitely see how, in a company with larger teams, separating the frontend and backend can help with productivity. On the other hand, I'd wager that decoupled applications are less efficient with API calls something like 90% of the time.

When I build a fully-coupled application, loading any given page after the CSS/JS files are cached requires a single HTTP request which always includes exactly the data that's required for that page. 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 started out at my current job working on a fully coupled system that's basically as "legacy" as you can get, and eventually started modernizing it - as part of that process, we decoupled the frontend from the backend. At first it felt more productive simply because it wasn't the old system and the new frameworks actually had documentation, but once I compared it to building a coupled system with modern frameworks I realized the coupled system made me much more productive. I'm currently the only developer at my company, though, so I feel like I'm probably the perfect target audience since I don't have to worry about team coordination at all.

> 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.

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.

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:

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

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

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?

> 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.

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.

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.

So then, are you building your backend API directly to meet the needs of your front-end? Or are you trying to keep it generic for all needs, but also serve the front-end? Are you telling the front-end team to download multiple resources from multiple endpoints when they need to render one thing? Do you have real life other consumers of your API? Are you juggling their requirements vs internal requirements? Is your backend team telling the frontend "it's not a good API design if we give you exactly what you need, so instead please pull these multiple resources?"

Can you adequately measure your page load performance when front-end is making many parallel requests to the back-end and not all of them are required to consider the page "loaded"?

There are countless architectural downsides associated with not just giving the front-end exactly what they need, and there has to be a very good upside for doing this. Front-end freedom is not one of them, because the freedom is minimal and mostly accidental. A good upside can be: you're building specifically an API for building your kind of web application, and you want to dogfood your own work. Otherwise, it seems an incredible amount of unnecessary contention and complexity.

That said, I don't disagree that it _kind of works_ the way you describe, but it could've worked a lot better if your API could just give the front-end exactly what they need. You could've designed it with the exact same process, and they could've worked off of mocks the same way. They just would have all the data sent to them in a much more streamlined fashion.

Disclaimer: I'm the author of https://max.engineer/server-informed-ui

We have different schools of thought internally. Some prefer to tailor the backend API to the needs of the frontend, others prefer to have the backend API super generic so that changes in the frontend (say, a redesign) didn't require changing the backend. The latter is easier for backenders but harder for frontenders. It's vice versa for the former. So, the complexity stays the same, it influences which team (the frontend or the backend team) gets more complexity. However, when desiging the backend API, we always involve at least 1 frontender so that there were no "surprises".

This turns into "BFFE" (backend for frontend) in my experience, and that's not even the dumbest possible decision.

Really pleased that you've found a way to make it work.

But do you need it?