As wonderful as a fully automated full stack framework would be, you might be hoping for too much magic here. Building distributed systems is fundamentally different to working locally and you can’t escape some of the extra complexity that comes with it.

For example, if you don’t want to make any manual HTTP requests to fetch data then the logical alternative is to fetch it automatically. What should be the trigger for your ideal framework to do that? Without any extra information, the framework can only know you need the data when your other code asks for it. It will have to fetch everything on demand, in real time, and that could be extremely inefficient both in terms of the number of requests you’re making over your HTTP channel and the database queries that will ultimately run on your servers. Even if the framework somehow has perfect caching on the client side and it pushes notifications when cached data needs to be refreshed, there will still be questions around which notifications to push to which clients, because in general the server will have no way to know which data that was requested earlier is still relevant to each client at some later time.

You’d also like updates sent to the back end automatically when you change your front end data structures, and not only that, you’d like them propagated out to other clients automatically as well. How would your ideal framework manage what is now shared mutable state? For example, maybe there are constraints in your data model and you need transactional behaviour that updates multiple data points at once to avoid violating those constraints. In general, the framework can’t know when you’ve finished making a set of related changes that should be batched up and sent back to the server, unless you tell it explicitly. And when you do, how would your ideal framework resolve conflicting updates if multiple clients are sending incompatible changes around the same time? What happens if communication links break down and you have to deal with the CAP Theorem? There are no universal “right answers” to any of these questions, and the behaviour you want will often be highly specific to an individual application and its particular data model.

I fear the reason you haven’t found what you’re hoping for is that no framework exists that can magic away all these practical questions about building a distributed system. Even specifying the required behaviour in a realistic application is a non-trivial problem, never mind implementing that specification once you’ve decided what it should be.

So for whatever it’s worth, my advice would be to lower your expectations a little. It’s very reasonable to want a single source of truth for your data models and to generate the types and the simple cases for REST/GraphQL endpoints, DB queries, HTTP request wrappers on the client, API documentation, etc. It’s also very reasonable to want some standard mechanism for authentication and authorisation checks, possibly using middleware in your own code or other facilities provided by any cloud hosting service you’re using, that can be applied on top of the above. But maybe look for a starting point that can handle a lot of the boilerplate for you and leave you free to concentrate on the more difficult questions, rather than hoping to achieve everything you described out of the box.