It's just that instead of an organized backend we get single functions, unsightly stored all in one folder or entity by entity, depending on the project.

There is no caching either, but okay, this can be fixed with the unstable_cache() function, let's say.

Suppose we have done as they suggest in the video: we have made small compact functions and caching. But here again there is a question of reusability. Well, for example, I want to address as a "microservice", and I simply do not have route.js to address and I have to write it anyway.

This looks very strange. You position yourself as a fullstack framework, but at the same time your analogue backend is not friendly with the frontend part and is considered a bug.

Then the question is what is the point of this feature if I can't use it on the frontend, only if microservices.

If we had for example one handle for everything. To invoke a third-party microservice or frontend - it would be very convenient. (it would be possible on the frontend to either make a conditional '/api/...' or a parameter of some kind, which is responsible for the fact that this request lies on the same server and you don't have to go anywhere far)

you are confusing what is frontend and what is backend

client == frontend. rsc == backend. api = backend

rsc to api is nonsense

if you do not need to access the call externally, or from a client component, there is absolutely no reason to make an api route

well, I understand that how to access the server on the server is not a good idea. And also turn the response/request into json/ from json.

It just raises another question. And in what scenario is this even necessary?

For example, a person gives an example: a request from github. Why would I do that if I can do it in the server component. Where can I use this route.js, if it's on the frontend, it makes no sense for me to call it when I can make a fetch request directly. Where can I use this route.js next?

That is, we usually use server-side components and fetch + Suspense. So it makes sense to use route handles only in one case, when we use sockets? Because at first glance only in this case we use the client to get data. But it looks like we can do without route handlers here too. So it's necessary

examples are there to show what something can do.

examples are almost never there for practicality purposes.

wasting time worrying about the circumstance something would be done in in an example is a waste of everyones time and effort

Okay, another question. Why nextauth works through route handlers. It's still happening on my server and I have actions. So why does he use it like that.

For example, I've watched about 5 videos on YouTube, how people write from forms to full stack projects. And this is what I found. Of these, either people did not use route handles at all, or it was just wrong.

About the last picture, I may not be able to say so strongly, because the man was making an analogue of trello, but from what he wrote: fetcher = fetch().then(data => data.json()) and access the database. I did not see him doing validation there every minute, either using use Query, or using fetch or exported page variables, from which I can conclude: incorrect use when it was possible to make a regular request from above in the server component and pass it to the client