The quiet, pervasive devaluation of front end

Re:The quiet, pervasive devaluation of front end by solarkraft on Friday March 08, 2024 @10:17AM (#39641783)

If GraphQL was actually a query language (as in: allowing you to change the result set, not only the result shape), maybe 1 would be easily possible. Intuitively I would like that.

3 seems to be the most pragmatic option to me when you have good control over each side.

[ Parent | on HN ]

Re:The quiet, pervasive devaluation of front end by qazxcvbnm on Friday March 08, 2024 @12:52PM (#39643674)

Can you elaborate on what you mean by changing the result set as opposed to the shape?

[ Parent | on HN ]

Re:The quiet, pervasive devaluation of front end by klysm on Friday March 08, 2024 @10:30AM (#39641936)

Supporting the interface of graphql from the backend though is usually not very easy - you usually end up with a half baked database implementation that wraps a better database

[ Parent | on HN ]

Re:The quiet, pervasive devaluation of front end by nicwolff on Friday March 08, 2024 @02:10PM (#39644908)

Huh? GraphQL field arguments are used to filter and paginate result sets.

[ Parent | on HN ]