[bwilliams]

> A bug in one "page" of the app can cause the whole application server to go down.

That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end.

> If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps

Your PWA point is valid but I don't think the microservices point is. Microservices add a ton of complexity and can easily become overwhelming. If you get to the point where your application can benefit heavily from microservices then congrats, you've made it.

> I think that server-side rendering is on it's way out.

If anything I think its on its way back in. So many companies bought into the benefits of client side apps and are now seeing the trade-offs that aren't very favorable.

[jamespollack]

> That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end.

What? The previous poster said coupling frontend / server tightly will result in crash of both if there is a server bug. Your response is that a bug in an unattached API could happen? Of course a bug in your API could crash your API. But at least then it's just your API that's crashed, not the (thousand) servers you're using to serve the front end and every device using them.

[bwilliams]

If your API is down who cares if your app is being served or not? In the majority of cases it won’t work because the API is down.

[skinnyarms]

If my app runs off multiple API, then the bug in my (for example) commenting API shouldn't prevent users from using the shopping cart API to check out.