Comment by jmilloy | Hacker News Reader

Comment by jmilloy | Hacker News Reader

Parent Full thread

This and the article strike me initially as completely wrong, which makes it very interesting. I still want a clear separation between the "model" and the "view", and I guess I tend to assume that this corresponds to the front-end and back-end. Maybe that's a poor assumption.

What I see here is that the "view" is split across the front-end and the back-end. Or in other words, the back-end contains both the model and the JSON API as a view. I think this is what is meant by "I suggest you stop treating your frontend as some generic API client, and start treating it as a half of your app."

I still want a clean separation between the model, e.g. companyName, and the view, e.g. pageTitle. Somewhere, there needs to be the explicit logic (in the back-end part of the view) that says that the the pageTitle for page A is the companyName. It's okay for many different views to "reuse" fields from the model, but each view should have its own front-end and back-end components. That the view is split across a front-end/back-end divide through the nature of the web-stack doesn't change the fact that each view should remain distinct from the other views.

So I can agree in the sense that the alternative where you create a general-purpose JSON API as a model and view in the back-end, and then essentially code up an additional model and view for each front-end page/element with logic to convert the API data into the necessary content is a waste of time.

A backend model is usually just called the model as it’s modeling the data domain (sometimes called ‘domain model’). The thing you pass to the frontend is the ‘view model’ which is often entirely different.

In some CRUD situations though, they can be nearly the same and you can convert the domain model into a specific view model with some kind of adapter (how people do this varies a lot). This adapter will take the end user security level into account, for example. Also, to avoid sending lots of useless data for a list, you can have a list view model. But if you do that, be sure to either keep the two in sync, or you have one and keep track of whether it’s partially or fully hydrated.

I agree that mvvc sounds exactly right, but there is still the question of whether the view model is created in the back end (which is what the article is advocating) or in the front end (which is what you have to do if the back end serves the model like a general use API).

The MVC or mvvc or whatever paradigm is somewhat orthogonal to the technical back end/front end.

Arguably, the opposite is true. The view is more washed out across the stack if back-end supplies generic fields, and front-end decides how to use them. Now you no longer know who is responsible for which decisions, and have to look for them everywhere in the stack.

If back-end provides the entirety of data to build the page, then you limit front-end decisions to UX based on the specific data, and no longer allow them to pull in new functionality or foundational business logic over to their side.

> arguably... view is washed out across the stack

Perhaps to argue this requires munging "view" with "front end"?

MVC needn't mean database schema, front end, and logic. It could, but then what is a "view" in the database?

Perhaps you're reinventing MVVM?

https://en.wikipedia.org/wiki/Model–view–viewmodel

MVVM definitely came to mind as I was writing my comment. The model is clearly in the back end, the view clearly in the front, and the view model contains the explicit link between companyName and pageTitle and can live in either. Here the suggestion is to put it in the backend and serve it as JSON.

I'd say "kids these days" but all 3 of our accounts joined in 2010.

I'm suggesting to pass via JSON what we used to pass via HTML back when front-end was templates on the server. I still prefer those days, like I alluded to in the first paragraph of the article. It used to be: write your template by inserting database values into it. Now I'm saying: instead of a template, come up with a neat json structure that kinda represents that template, and insert your database values into it. Name the fields after what page needs, not what you have in the database (following standard practices of object construction). I'm not sure what I might be reinventing, or what it might've been called, because I'm just trying to explain a practice that saves time and reduces complexity in simple language. It's interesting if it already was a thing with a name, but doesn't really change the point.

I think if the back end provides generic fields and the front end acts as an independent consumer of the API, then you essentially have two apps each with their own entire MVC (or whatever paradigm you are using), one on the front end and one on the back end. So I wouldn't quite say that "the view is more washed out across the stack" but that you have two views (and two models).

Agree with this. Of course because front-end still gets to build business logic, and back-end still ultimately decides the basis on which to build it, the decision making is spread more equally between them. Perhaps calling it "a washed out view" is not strictly appropriate, but worth acknowledging that the front-end is at the mercy of what back-end decides to provide it.

it's called Controller and it's for this exact reason that it's separate from the Model and the View.

I disagree, the controller is something else. The point is that MVC is orthogonal to backend/frontend.

Reply on news.ycombinator.com