Doesn't that lead to an explosion of the number of sql views and backend controllers/endpoints?
Re:How GraphQL Replaces Redux
by matte_black on Tuesday March 13, 2018 @03:24PM
(#16578962)
Not at all. Not sure what other people are trying to do though.
Re:How GraphQL Replaces Redux
by joshribakoff on Wednesday March 14, 2018 @02:48AM
(#16582828)
Being able to stay agile & change the app, without breaking old versions of the app, and without having to have an explosion of ad-hoc end-points for every change you've ever made. With graphQL its perfectly reasonable to never rename or delete fields, and never break backwards compatibility. With REST that would not work & would result in over-fetching, or tons of ad-hoc end points for every query you've ever written.
We control what is returned in data from our REST API by merely specifying the fields you want as a parameter. If there are use cases that would require multiple tables to be joined, those are created ahead of time as views with appropriate triggers for updates and then endpoints are created for accessing that view through RESTful methods. This has always worked just fine.