Nobody said doing an API-based design requires you to (purely) client-side render. Lots of people are consuming APIs and rendering (initially) on the server, then consuming the same or similar APIs to do updates on the client. Best of both worlds -- this approach has neither downside you mention (even though the downsides are not as bad as you suggest even if you do pure client-side rendering).
>Nobody said doing an API-based design requires you to (purely) client-side render.
And if you go down that route, you pay for the increased deployment and maintenance complexity as well as the RTT to call the API service and consume the response as well as the CPU cost to render the page. There's no free lunch here. You can have both the API and rendering service on the same box, but now it's looking less and less clean and tidy, and more and more like a traditional web-app.
It's a tradeoff (isn't everything) but I don't think the cost is cleanliness/tidiness.
Your client (could be a web app consuming the api from the server) accesses the api like anyone else. You've created an api that others can build on - and you know that, because you're doing it yourself.
More to maintain. More cpu processing. Still a cleaner architecture though (compared to, say, having to maintain an external api for others to use while having a web app that talks directly to the db).
If this is a strain on deployment and maintenance I would take a close look at those two processes in your organization. We maintain 18+ services (5 people) and having our front-end web apps call APIs only (never direct db calls) has not hit performance, deployment or maintenance issues. In fact, it's helped in all those cases, especially the last two (for us, YMMV yadda yadda).
