Kubernetes is a red flag signalling premature optimisation

Re:Kubernetes is a red flag signalling premature optimisation by AgentME on Monday July 04, 2022 @07:14AM (#31975804)

Even when using Nextjs, it's still pretty common to have a separate API backend that doesn't also have to be in Javascript/Node. There are parts of backend code (HTML generation) that very strongly benefit from being unified with the frontend code, and there are parts of backend code (like database persistence code) that much less strongly if at all in some cases benefit from unification with the frontend code. Many people split these parts of backend code up between a separate Nextjs backend service and API backend service, and Nextjs lends itself well to this.

I'm a big Nextjs fan; I just think it's useful to emphasize that using it doesn't necessarily have to mean "only javascript/typescript on the backend".

[ Parent | on HN ]

Re:Kubernetes is a red flag signalling premature optimisation by chrisweekly on Monday July 04, 2022 @08:08AM (#31976162)

This. I like how the Remix.run devs frame the "BFF" (Backend-For-Frontend) pattern: https://remix.run/docs/en/v1/guides/bff

[ Parent | on HN ]

Re:Kubernetes is a red flag signalling premature optimisation by mwcampbell on Monday July 04, 2022 @09:32AM (#31976833)

That document starts with this:

> While Remix can serve as your fullstack application,

Isn't that where most teams should start, and where they should stay unless they have a really good reason to get more complicated? This is what I was thinking of while reading the GP comment about Next.js.

[ Parent | on HN ]

Re:Kubernetes is a red flag signalling premature optimisation by chrisweekly on Sunday July 10, 2022 @08:37AM (#32044153)

For greenfield projects, yes. But for projects where there's already a decent backend API, it's a reasonable approach to use Remix "only" as a BFF.

[ Parent | on HN ]