Comment by thomaslord | Hacker News Reader

Comment by thomaslord | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com