3 ms·

Your typical server rendering looks like: Controller queries DB, builds a Model then passes that Model to a View. View uses that Model to render HTML which re

Your typical server rendering looks like: Controller queries DB, builds a Model then passes that Model to a View. View uses that Model to render HTML which returned to the client. With dedicated frontend it turns into: Controller queries DB, builds an API response. Frontend receives API response and renders it into HTML. So basically Model is API. Issue with SSR is that it's not popular nowadays and most frameworks are stagnating. At this point it's better to stick to separate backend/frontend unless you don't want to touch it. You don't have to build JSON Schema, OpenAPI and whatnot. Just spew some JSON and consume it with JavaScript.

renke1 5y ago
> Issue with SSR is that it's not popular nowadays and most frameworks are stagnating. At this point it's better to stick to separate backend/frontend unless you don't want to touch it. It certainly stagnated a bit in the past, but Rails is still alive and so are newcomers like Phoenix (especially LiveView) or even some new PHP stuff. Also, a lot of talent is wasted when the old backend guys are barred from doing frontend work. They can be crazy efficient with classical server-side approaches. > You don't have to build JSON Schema, OpenAPI and whatnot. Just spew some JSON and consume it with JavaScript. This highly depends on the team structure. In projects where a team (or even single developer) works on both the frontend and backend at the same, it may be fine. However, when there is a dedicated frontend and backend team (in my current project we have a dedicated Android team), it makes sense to have some kind of schema (even when not using codegen). Otherwise you will have a lot of communication overhead.