It might be that for the author specific case (which we dont know in details) maybe this is a good approach.
In general I disagree with almost any idea that tries to fix some problems by adding coupling between components. I think the main thesis is where there is a false assumption:
> Your frontend can finally focus on presentation and UI. Your backend can finally focus on implementing exactly what’s needed.
If you make backend create one API call for each page, you will NOT get FE focusing on UI and backend on something else. You will get FE focusing on UI and BE focusing on UI and something else.
I do get the feeling of rebellion against common wisdom that is FE and BE as separate components.
When I was junior programmer (not suggesting here that author is junior, just talking about my experience) I often found myself rebelling against common programming wisdom.
Now, after more than a decade of seeing so many changes and request I think those old programmers that gave us that old wisdom about separating concerns and losse coupling are right.
I could boil down probably all old advice into the following 3 small pieces:
1. Write code. Not too much. Mostly simple, short and loosely coupled.
2. Go against common wisdom when you understand the tradeoffs. When not sure, pick the common wisdom.
3. You can maybe fix technical issues with more people, but can never fix organizational issues with code.
Author here. Here's an additional piece of wisdom that I picked up in over 20 years of doing this. Reliable communication allows for simpler, less coupled interfaces. Unreliable communication demands increasingly elaborate and coupled interfaces. I wrote a short note explaining this principle. https://notes.max.engineer/reliable-communication-allows-for...
> If you make backend create one API call for each page, you will NOT get FE focusing on UI and backend on something else. You will get FE focusing on UI and BE focusing on UI and something else.
You need your backend to focus on something, otherwise it would be focused on nothing/everything. You need to tie yourself down to use cases, otherwise every use case is your use case.
First let me again say sorry if my reply made you think I assume you are young. That was not my intention.
Second
> You need your backend to focus on something, otherwise it would be focused on nothing/everything. You need to tie yourself down to use cases, otherwise every use case is your use case.
What I was saying is that your backend will now do what was doing before AND also will need to handle UI elements and relation between them.
So you have duplicate data architecture/knowledge in UI:
- once in FE as it needs to know the data architecture
- again in BE where it also needs to know what data structure UI needs.
Thus it couples FE and BE together around key names, JSON structure and moreso on information architecture from UI concepts.
I am not saying you should not do that. Maybe it works for you. I would not do it.
For me it will be like saying in a traditional simple HTML app that I should name tables and columns in DB as they are in the UI. Maybe some might coincide but that will not be an architectural constraint when thinking the DB.
Have you looked at this from the angle of object constructor or function parameters? Let's say you build an object called Person. They have first_name, last_name, phone_number. That's what you probably will pass into a new Person. Now let's say you build an object called BusinessCard. Most people will be tempted to pass in BusinessCard.new(first_name: person.first_name, last_name: person.last_name, phone_number: person.phone_number) or simply BusinessCard.new(person). What I suggest is that you should pass in BusinessCard.new(main_text: person.first_name + ' ' + person.last_name, secondary_text: person.phone_number). This, but for webpage. Your front-end defines the constructor parameters for the page, and back-end passes them in.
> your backend will now do what was doing before AND also will need to handle UI elements and relation between them.
So you have duplicate data architecture/knowledge in UI
I don't think it will need to handle any elements, it will only need to construct the page by passing in what the page needs, not what the backend has. Just like constructing any other object or calling any other function.
In a way yes, you can say that any caller that constructs any object couples itself to said object, because it passes the specific arguments needed for its construction. Instead, we could provide access to the entire database, and allow objects to construct themselves by fetching any data they like. I guess I can agree with your characterization, but this would be considered an unjustifiable anti-pattern in any other context, because it makes it easy to lose track of dependencies, and makes it hard to optimize things. "Let's have objects auto-construct themselves from global state."
> it will be like saying in a traditional simple HTML app that I should name tables and columns in DB as they are in the UI
This part seems incorrect. Just because you pass parameters to construct an object, doesn't make it like having said parameters live in a database in the same format as the object constructor that accepts them. The entire point is that they are not the same, and need to be adapted to construct various things (pages in the front-end among them).
In general I disagree with almost any idea that tries to fix some problems by adding coupling between components. I think the main thesis is where there is a false assumption:
> Your frontend can finally focus on presentation and UI. Your backend can finally focus on implementing exactly what’s needed.
If you make backend create one API call for each page, you will NOT get FE focusing on UI and backend on something else. You will get FE focusing on UI and BE focusing on UI and something else.
I do get the feeling of rebellion against common wisdom that is FE and BE as separate components.
When I was junior programmer (not suggesting here that author is junior, just talking about my experience) I often found myself rebelling against common programming wisdom.
Now, after more than a decade of seeing so many changes and request I think those old programmers that gave us that old wisdom about separating concerns and losse coupling are right.
I could boil down probably all old advice into the following 3 small pieces:
1. Write code. Not too much. Mostly simple, short and loosely coupled. 2. Go against common wisdom when you understand the tradeoffs. When not sure, pick the common wisdom. 3. You can maybe fix technical issues with more people, but can never fix organizational issues with code.