I completely agree with you. I've also wrote this post explaining why tightly coupling the DB to the frontend is such a big problem: https://wundergraph.com/blo

I completely agree with you. I've also wrote this post explaining why tightly coupling the DB to the frontend is such a big problem: https://wundergraph.com/blog/tight_coupling_as_a_service https://wundergraph.com/blog/tight_coupling_as_a_service That said, I've added support for direct DB access to WunderGraph based on demand from the community. Although it has drawbacks, users want to expose their DB as an API. I don't want to ignore them. That said, I also want to address your second point. WunderGraph offers two abstraction points. For one, you can always swap out a backend and join multiple APIs together. This means, you could replace an API generated from a DB at any time, even partially, without breaking the client contract. Then, there's also a second abstraction point which has to do with the fact that WunderGraph persists GraphQL Operations by default. It allows you to swap out the entire schema if the Operations stay the same. Both options might not always work but offer good migration paths from a DB generated API away. If you have the resources, it always makes sense to "design" your API. Generating an API is not wrong in many ways. However, for prototyping and simple projects, it might be the right tool to get the job done in a cost sensitive way. To sum it up, generated APIs are not ideal but it really depends on the case. In the end, the customer decides.