4 ms·

I find these DB-to-REST, DB-to-GraphQL and so on variety frameworks to be terrible. That said I've come to accept some people really just need to expose their

I find these DB-to-REST, DB-to-GraphQL and so on variety frameworks to be terrible. That said I've come to accept some people really just need to expose their database out there. And so having these tools help them. It would be nice if those tools did provide for a smooth path from 1:1 mapping to full customization. Unfortunately, most don't.

jensneuse 5y ago
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.
maxcan 5y ago
I agreed with this until I found Hasura. For me its just the right level of abstraction and saves me a boat load of time writing CRUD queries. Now, 90% of my CRUD ops are autogenerated, with great, granular authorization, and for more complex logic I can easily "join" a lambda function.

jensneuse 5y ago

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.

maxcan 5y ago

I agreed with this until I found Hasura. For me its just the right level of abstraction and saves me a boat load of time writing CRUD queries. Now, 90% of my CRUD ops are autogenerated, with great, granular authorization, and for more complex logic I can easily "join" a lambda function.